2026 Common Criteria Cryptography Updates: Entropy, Protection Profiles, and FIPS 140-3 Impact

The 2026 Common Criteria landscape is changing the way vendors, laboratories, and government buyers must think about cryptographic assurance. The changes are not limited to adding newer algorithms to a checklist. They affect how a product defines its cryptographic boundary, identifies its entropy sources, claims conformance to Protection Profiles, maps algorithm certificates to evaluated configurations, and demonstrates that random-number generation remains secure during startup, normal operation, reseeding, and failure.

For organizations building products for the U.S. federal market, the most consequential theme is convergence. Common Criteria 2022 is becoming the practical foundation for current NIAP Protection Profiles and PP-Modules. NIST is simultaneously advancing the FIPS 140-3 ecosystem, entropy source validation, FIPS 186-5 digital signatures, and post-quantum standards. NIAP Technical Decisions are then applying those developments to specific product categories—sometimes as permanent modernization and sometimes as temporary transition relief.

This report reviews the major developments visible through July 2026, with special attention to:

  • Common Criteria general rules that influence cryptographic claims;
  • entropy and deterministic random bit generator requirements;
  • 2026 Protection Profile and PP-Module changes;
  • migration from FIPS 186-4 to FIPS 186-5;
  • the interaction between Common Criteria evidence and CAVP or CMVP validation;
  • the FIPS 140-2-to-FIPS 140-3 transition;
  • early integration of FIPS 203 and FIPS 204 post-quantum algorithms; and
  • practical preparation steps for vendors and evaluation laboratories.

Scope note: This is an analytical industry report, not an official interpretation by NIAP, NIST, the CCRA, or an evaluation scheme. The governing source is always the applicable Protection Profile, PP-Module, Functional Package, Technical Decision, scheme policy, and current laboratory direction.

Executive summary

The headline for 2026 is that cryptographic assurance is becoming more architecture-specific and more evidence-driven.

Five developments matter most.

1. Common Criteria 2022 is now shaping real evaluation structure

Current NIAP documents increasingly use the Common Criteria 2022 model of Base Protection Profiles, PP-Modules, PP-Configurations, Functional Packages, direct rationale, and exact conformance. This means a vendor cannot treat cryptographic requirements as an isolated list copied into a Security Target. The claim must fit the permitted configuration, package versions, TOE boundary, and operational environment.

2. Entropy claims are becoming more precise

Newer requirements distinguish among:

  • a platform-provided random bit generator;
  • a TOE-implemented DRBG;
  • internally generated entropy;
  • external seeding;
  • one entropy source;
  • multiple entropy sources;
  • conditioning or source-combination logic;
  • health testing;
  • reseeding; and
  • secure failure behavior.

The practical implication is that “uses an SP 800-90A DRBG” is no longer an adequate architecture description by itself.

3. CTR_DRBG without a derivation function has a 384-bit entropy consequence

NIAP Technical Decisions issued in 2026 clarify that an AES-256 CTR_DRBG used without a derivation function needs at least 384 bits of entropy for the relevant full-entropy seed construction. This is a major documentation and implementation issue because some designs historically treated “AES-256” as implying a 256-bit entropy target.

4. FIPS 186-5 is the destination, but transition handling is profile-specific

Several 2026 Technical Decisions replace outdated FIPS 186-4 references with FIPS 186-5 or correct FIPS 186-5 section references. At the same time, NIAP has provided targeted transition relief in at least one major profile context to avoid disrupting evaluations that still depend on FIPS 186-4 evidence.

The correct question is therefore not simply, “Is FIPS 186-4 still accepted?” It is, “What does the exact Protection Profile and currently applicable Technical Decision permit for this evaluation?”

5. A FIPS certificate can reduce duplicate work, but it does not replace Common Criteria evidence

NIAP Policy #5 allows suitable CAVP or CMVP evidence to satisfy certain cryptographic evaluation activities when the implementation, algorithm, mode, key size, operational environment, and evaluated configuration match. It does not eliminate the need for a correct Security Target, TOE boundary, entropy documentation, interface mapping, guidance, or other Protection Profile evidence.

The strongest 2026 evaluation strategy is therefore to design the Common Criteria and FIPS evidence sets together rather than treating them as independent certification projects.

What changed in 2026?

The phrase “2026 Common Criteria updates” can be misleading if interpreted as one global revision issued on January 1. The actual change is distributed across several layers:

  1. Common Criteria 2022 rules are being operationalized through current profiles and modules.
  2. NIAP Protection Profiles and PP-Modules are being converted or revised for CC:2022.
  3. NIAP Technical Decisions are correcting or tightening requirements between profile releases.
  4. NIST cryptographic standards and validation guidance are changing the evidence available to Common Criteria evaluations.
  5. FIPS transition deadlines are affecting product roadmaps and procurement decisions.

The result is a moving compliance baseline. A product that began planning against a 2024 or early-2025 profile may encounter different algorithm references, entropy selections, package versions, or assurance expectations by the time its Security Target is submitted.

High-impact 2026 update map

Date Update Main cryptographic or entropy impact FIPS impact
January 7, 2026 NIAP TD0943 Clarifies the entropy requirement for CTR_DRBG without a derivation function Aligns CC entropy claims with the full seed requirements of approved DRBG constructions
January 13, 2026 Host Agent PP-Module v2.0 CC:2022 conversion; signature protection for trusted policy or management content Uses current FIPS 186-5-oriented signature requirements
January 13, 2026 Endpoint Detection and Response PP-Module v2.0 Modular composition with Host Agent and Application Software requirements Inherits current algorithm and random-bit-generation expectations
January 21, 2026 VPN Gateway PP-Module v2.0 Updates IKE/IPsec evaluation structure and entropy documentation Moves key generation and signature evidence toward FIPS 186-5
January 21, 2026 WIDS/WIPS PP-Module v3.0 CC:2022 conversion and updated base-profile composition Inherits updated network-device cryptography and entropy requirements
February 24, 2026 NIAP TD0990 Adds a 384-bit selection to the affected random-bit-generation requirement Makes the CTR_DRBG no-derivation-function consequence explicit in the SFR
February 24, 2026 NIAP TD0999 Updates signature-generation references for hardcopy devices Replaces superseded FIPS 186-4 direction with FIPS 186-5
March 10, 2026 Authentication Servers PP-Module v2.0 Updates protocol and credential cryptography under CC:2022 Composes with current network-device and FIPS algorithm requirements
March 17, 2026 Session Border Controllers PP-Module v2.0 Updates secure signaling/media and trusted-channel context Relies on current approved algorithm and certificate evidence
March 30, 2026 Stateful Traffic Filter Firewall PP-Module/Configuration v2.0 Formalizes a CC:2022 modular configuration Makes base-profile crypto and entropy claims part of exact configuration
April 1, 2026 NIAP TD1020 Provides controlled transition handling for digital-signature requirements in Network Device cPP v4.0 Temporarily preserves a FIPS 186-4 path while migration to FIPS 186-5 proceeds
April 9, 2026 FIPS 140-3 Implementation Guidance update Updates entropy, multiple-source combination, DRBG, public-key, self-test, and related guidance Directly affects CMVP evidence that may be reused in CC evaluations
April 16, 2026 General-Purpose Computing Platforms PP v2.0 Introduces a detailed random-bit-generation architecture and failure model References FIPS 186-5 and includes selectable FIPS 203/FIPS 204 capabilities
June 22, 2026 SP 800-140D supplemental update Adds SP 800-90C random bit generator constructions to approved methods references Expands the current FIPS 140-3 RBG standards framework
June 23, 2026 NIAP TD1042 Updates full-drive-encryption signature requirements Replaces FIPS 186-4 with FIPS 186-5
July 22, 2026 NIAP TD1054 Corrects FIPS 186-5 references in the VPN Client profile context Reduces ambiguity in the required FIPS 186-5 clauses
July 27, 2026 NIAP TD1051 Corrects FIPS 186-5 references in the Application Software profile context Clarifies the exact signature-generation standard sections

General Common Criteria rules now shaping 2026 evaluations

Common Criteria 2022 is more than a document-version update

CC:2022 formalizes a modular way to construct security requirements. Instead of expecting one monolithic profile to contain every product and protocol requirement, the framework supports:

  • Base Protection Profiles, which define a foundational product type;
  • PP-Modules, which add a complementary technology or function;
  • PP-Configurations, which identify a permitted combination of a Base PP and one or more PP-Modules; and
  • Functional Packages, which collect requirements for reusable protocols or functions such as TLS, SSH, or X.509.

This structure matters to cryptography because algorithm and protocol requirements may be distributed among several documents. A network appliance might receive foundational entropy and key-management requirements from a Network Device cPP, feature requirements from a VPN Gateway or Firewall PP-Module, and detailed TLS behavior from a TLS Functional Package.

A cryptographic claim can therefore be technically correct in isolation and still be nonconformant because it appears in an impermissible profile combination or uses the wrong package version.

Exact conformance narrows design freedom

Many current NIAP profiles require a Security Target to claim exact conformance. Exact conformance is intended to make evaluated products comparable and to prevent a Security Target from silently weakening, restructuring, or selectively omitting profile requirements.

For a cryptographic design, this means the Security Target author must accurately complete the profile’s permitted:

  • selections;
  • assignments;
  • refinements;
  • optional requirements;
  • selection-based requirements;
  • implementation-dependent requirements; and
  • package claims.

The author should not assume that an equivalent cryptographic mechanism can be substituted merely because it appears to provide comparable security. The profile’s defined operations and applicable Technical Decisions control.

“Allowed-with” rules matter for PP-Modules

Under the CC:2022 modular model, a PP-Module identifies the Base PPs or other modules with which it may be used. A module is not meaningful as a stand-alone evaluation target; it must participate in an allowed PP-Configuration.

This creates a compliance dependency chain. For example:

  • a 2026 module may require Network Device cPP v4.0;
  • the base profile may define the random-bit-generation architecture;
  • the module may add IKE, RADIUS, SRTP, firewall, or endpoint functions;
  • a Functional Package may define TLS or X.509 behavior; and
  • Technical Decisions may modify any of those requirements after publication.

A vendor needs a configuration matrix, not just a list of PDFs.

Functional Packages make protocol version control more important

Current profiles increasingly claim conformance to Functional Packages such as:

  • Functional Package for Transport Layer Security, Version 2.1;
  • Functional Package for Secure Shell, Version 2.0;
  • Functional Package for X.509, Version 1.0; and
  • Functional Package for Flaw Remediation, where applicable.

These packages can impose or constrain:

  • protocol roles;
  • cipher suites;
  • key-establishment methods;
  • certificate validation;
  • signature algorithms;
  • revocation behavior;
  • nonce and IV generation;
  • failure processing; and
  • evaluation activities.

For evaluation planning, “supports TLS 1.3” is not enough. The product claim must map the implemented protocol, algorithms, certificates, key derivation, random values, and error behavior to the exact Functional Package requirements selected by the permitted PP-Configuration.

Direct rationale changes where the argument is made

CC:2022 supports direct-rationale profiles in which the security problem definition maps more directly to SFRs without a separate layer of TOE security objectives. The practical impact is that the SFR, application note, evaluation activity, and TSS explanation carry more of the assurance argument.

For cryptographic functions, vague language in the TSS is increasingly risky. The documentation should state:

  • which component performs the operation;
  • where the component executes;
  • whether it is inside or outside the TOE;
  • what API or interface invokes it;
  • which algorithm, mode, and parameter set are used;
  • where keys and entropy originate;
  • which validation certificate applies;
  • how failures are detected; and
  • what the TOE does after a failure.

Entropy is the biggest technical tightening in 2026

Entropy has always been foundational to cryptography, but recent profiles and decisions expose details that older Security Targets sometimes compressed into one sentence.

A DRBG is not an entropy source

A deterministic random bit generator expands seed material into pseudorandom output. It does not create entropy from nothing. A complete assurance claim needs to explain both:

  1. the DRBG construction, such as HashDRBG, HMACDRBG, or CTR_DRBG under SP 800-90A; and
  2. the entropy-source architecture that supplies seed or reseed material.

The evaluation must be able to follow the path from a noise source or external entropy provider through any conditioning and combination logic into the DRBG state.

Platform-provided versus TOE-implemented random generation

The distinction between using a platform service and implementing a DRBG inside the TOE changes the evidence burden.

When a TOE uses a platform-provided DRBG, evidence commonly needs to identify:

  • the platform cryptographic service;
  • the API called;
  • the operating system, firmware, processor, or module version;
  • the evaluated operational environment;
  • whether the service is the same implementation covered by a CAVP or CMVP certificate; and
  • whether the returned random bits are used directly or processed further.

When a TOE implements its own DRBG, the vendor may need to provide:

  • algorithm-validation evidence;
  • instantiation and reseeding behavior;
  • personalization-string or nonce handling;
  • prediction-resistance behavior, if claimed;
  • entropy-source documentation;
  • health tests;
  • known-answer or self-test behavior;
  • error propagation; and
  • secure-state behavior following failure.

A product that embeds a library in one build but calls an operating-system service in another build may have two different Common Criteria architectures, even if the high-level product feature is identical.

Single-source, multiple-source, and external-seed models

The General-Purpose Computing Platforms PP v2.0 illustrates the direction of travel. Its random-bit-generation requirements distinguish among:

  • a single TSF entropy source;
  • multiple TSF entropy sources;
  • an external interface that obtains entropy;
  • a source-combination mechanism; and
  • minimum entropy selections tied to the DRBG construction.

This matters because each model creates different questions.

Single internal source

The evaluator needs to understand the physical or logical noise source, raw sampling, conditioning, min-entropy assessment, operating conditions, health tests, and failure response.

Multiple internal sources

The analysis must explain whether the sources are independent, how their outputs are combined, what entropy credit is taken from each source, and what happens when one source degrades or fails.

External seeding

The TOE must define the external interface and the assumptions placed on the provider. “The platform supplies randomness” is incomplete unless the platform service, expected entropy quantity, interface behavior, and supported operational environments are identified.

The 384-bit CTR_DRBG issue

One of the most actionable 2026 clarifications concerns CTR_DRBG without a derivation function.

For the relevant AES-256 CTR_DRBG construction, the internal seed material includes both the AES key and the counter value. The full seed length is therefore 384 bits. NIAP TD0943 and TD0990 make the resulting requirement explicit: when the no-derivation-function option is used, the minimum entropy selection must support 384 bits.

This affects more than a number in the Security Target.

A vendor may need to revisit:

  • the quantity of raw samples collected;
  • the assessed min-entropy per sample;
  • the output length of a conditioning component;
  • the entropy delivered by an external interface;
  • the instantiation API;
  • the entropy report;
  • the DRBG’s CAVP evidence;
  • the mapping between the tested DRBG mode and the claimed mode; and
  • tests that demonstrate failure when sufficient entropy is unavailable.

For example, assume a noise source is conservatively assessed at 0.5 bits of min-entropy per raw sample. Ignoring additional margins and conditioning constraints, obtaining 384 bits of min-entropy would require at least 768 samples, while a 256-bit target would require 512. The precise calculation must follow the applicable entropy assessment method, but the example shows why the change can affect latency, boot sequencing, power-on behavior, and hardware capacity.

Health testing is now inseparable from the entropy claim

Modern entropy assurance is not limited to a laboratory estimate under ideal conditions. Documentation must address how the source behaves over its intended operating range and how failures are detected.

Relevant evidence may include:

  • startup health tests;
  • continuous or on-demand health tests;
  • repetition-count and adaptive-proportion tests where applicable;
  • vendor-defined tests;
  • test thresholds;
  • false-positive and false-negative considerations;
  • responses to degraded environmental conditions;
  • raw-data access used for assessment;
  • whether test logic runs before or after conditioning; and
  • how failures are reported to dependent cryptographic services.

Failure must be secure, not merely logged

The General-Purpose Computing Platforms PP v2.0 links DRBG self-test failure to a secure state. Cryptographic services that require random bits cannot simply continue with stale, repeated, zeroed, or unverified output.

This design principle should be applied broadly:

  • key generation must not proceed;
  • ephemeral key establishment must not proceed;
  • signature operations requiring fresh randomness must not proceed;
  • random IV or nonce generation must not proceed;
  • insecure fallback must not activate;
  • the failure should be auditable where required; and
  • recovery should require a defined, evaluated action.

The evaluator will care about the actual control path, not only the developer’s statement that “errors are handled.”

The 2026 General-Purpose Computing Platforms PP v2.0

Published by NIAP on April 16, 2026, the Protection Profile for General-Purpose Computing Platforms, Version 2.0 is one of the most important 2026 publications for cryptography and entropy.

The profile covers the hardware and firmware platform that hosts tenant software such as operating systems, virtualization systems, and bare-metal applications. Its scope can include processors, management controllers, TPMs, device firmware, boot firmware, storage controllers, and related platform components.

Why this profile is strategically important

Application and operating-system evaluations often depend on lower-layer platform services. GPCP v2.0 pushes cryptographic assurance into the hardware and firmware foundation by asking where entropy originates, how the platform’s DRBG is seeded, how firmware and keys are protected, and how cryptographic failures affect platform behavior.

This can reduce ambiguity for higher-layer evaluations, but only if the platform documentation is sufficiently precise to support reuse.

Detailed RBG architecture

The profile supports approved DRBG constructions such as:

  • Hash_DRBG;
  • HMAC_DRBG; and
  • CTR_DRBG.

It then distinguishes the entropy path rather than assuming all implementations are equivalent. The architecture can include internal single or multiple sources or an external entropy interface. Minimum-entropy selections include 256-bit and, where required, 384-bit cases.

Entropy appendix

The profile includes a dedicated entropy documentation and assessment appendix that addresses areas such as:

  • design description;
  • entropy justification;
  • operating conditions; and
  • health testing.

This structure sends a clear signal: entropy is a first-class assurance artifact, not a supplemental implementation note.

DRBG self-tests and secure failure

The profile requires appropriate self-testing and secure behavior following DRBG failure. Cryptographic services dependent on random bits must not continue in a way that creates predictable keys, nonces, or protocol values.

Platform vendors should expect evaluators to trace:

  1. the health-test or self-test failure;
  2. the error signal;
  3. the state transition;
  4. the services that become unavailable;
  5. the audit or administrative indication; and
  6. the recovery process.

FIPS 186-5 digital signatures

GPCP v2.0 uses current FIPS 186-5-oriented requirements for classical digital-signature algorithms. This affects firmware update verification, secure boot, device identity, management authentication, and other platform trust functions.

Vendors should confirm that their algorithm-validation evidence covers:

  • the exact RSA or ECDSA operation;
  • claimed key sizes or curves;
  • signature generation or verification, as applicable;
  • hash-function combinations;
  • the implementation used in the evaluated firmware or hardware; and
  • the evaluated operational environment.

FIPS 203 and FIPS 204 appear in the profile

GPCP v2.0 also contains selectable post-quantum capabilities, including references to:

  • FIPS 203, which standardizes ML-KEM; and
  • FIPS 204, which standardizes ML-DSA.

Their appearance does not mean every platform evaluated under the profile must implement post-quantum cryptography. It does mean that the profile framework is beginning to accommodate current NIST PQC algorithms and CNSA 2.0-oriented use cases.

For vendors, this creates both an opportunity and a warning. A selectable PQC claim should be supported by a complete implementation and evidence chain, including algorithm validation when available and required, key and seed generation, failure handling, update verification, protocol integration, and secure storage. Merely exposing an experimental algorithm name is not enough.

Functional Package integration

GPCP v2.0 claims conformance to current reusable packages for SSH, TLS, and X.509. That makes platform management interfaces, certificate validation, and secure communications part of a more standardized package ecosystem.

The practical benefit is consistency. The practical risk is version mismatch. A Security Target and test plan should identify the exact package version used and any profile-specific restrictions imposed on its selections.

Network Device cPP v4.0 as the 2026 network baseline

The collaborative Protection Profile for Network Devices, Version 4.0, was approved near the end of 2025 and is the foundation for multiple NIAP modules used during 2026.

Although its publication date precedes 2026, it belongs in a 2026 impact report because new VPN Gateway, WIDS/WIPS, Authentication Server, Session Border Controller, and Firewall modules compose with it.

Cryptographic significance

A network-device base profile typically supplies foundational requirements for:

  • random-bit generation;
  • key generation;
  • key establishment;
  • digital signatures;
  • symmetric encryption;
  • hashing and message authentication;
  • trusted channels;
  • certificate validation;
  • key destruction;
  • self-tests; and
  • secure updates.

A module layered onto the base profile may add a specific protocol or security function, but it does not eliminate the foundational crypto requirements.

Transitional handling of FIPS 186-4

NIAP TD1020 is especially important. It reflects a practical truth about standards migration: profile text, algorithm-testing availability, vendor implementations, laboratory processes, and evaluation schedules do not all change on the same day.

The Technical Decision provides a controlled FIPS 186-4 transition path in the Network Device cPP v4.0 context while the ecosystem moves to FIPS 186-5. This should not be read as a general statement that FIPS 186-4 remains freely interchangeable with FIPS 186-5.

A project relying on the transition should document:

  • the exact TD revision;
  • why the transitional option applies;
  • which operations use FIPS 186-4 evidence;
  • the planned FIPS 186-5 migration;
  • whether the option remains valid at submission and validation; and
  • whether downstream procurement policy imposes a stricter requirement.

VPN Gateway PP-Module v2.0

The PP-Module for VPN Gateways, Version 2.0, published January 21, 2026, updates the VPN gateway evaluation framework for CC:2022 and the current Network Device cPP baseline.

Cryptographic impact

VPN gateways are highly dependent on:

  • IKE authentication;
  • Diffie-Hellman or elliptic-curve key establishment;
  • pseudorandom functions;
  • IPsec encryption and integrity;
  • certificate validation;
  • RSA or ECDSA signatures;
  • random nonces and ephemeral keys; and
  • secure key destruction.

The module’s 2026 update means the VPN-specific claims must be composed with the base profile’s current random-bit-generation and algorithm requirements.

FIPS 186-5 and IKE authentication

Current digital-signature requirements move toward FIPS 186-5 for RSA and ECDSA operations. A vendor should verify that the algorithm evidence supports the exact operation performed during IKE authentication and not merely a related library capability.

A CAVP certificate for ECDSA signature verification, for example, does not automatically establish support for ECDSA signature generation if the TOE performs both.

Entropy implications

VPN protocols consume randomness in multiple places:

  • IKE nonces;
  • ephemeral private values;
  • key-generation operations;
  • salts;
  • IVs; and
  • anti-replay or session values.

The entropy architecture must explain whether these values come from one DRBG, multiple cryptographic modules, hardware services, an operating-system service, or a management-controller service. The answer must be consistent with the TOE boundary and the operational environments listed in the Security Target.

WIDS/WIPS PP-Module v3.0

The PP-Module for Wireless Intrusion Detection and Prevention Systems, Version 3.0, was also published January 21, 2026. Its update incorporates Technical Decisions and converts the module to the CC:2022 structure.

The direct algorithm requirements may be less extensive than those of a VPN gateway, but the module still depends on the Network Device cPP for foundational cryptography and trusted communications.

Why it matters for FIPS and entropy

A WIDS/WIPS product may use cryptography for:

  • administrator sessions;
  • communication with management servers;
  • secure audit transfer;
  • update verification;
  • certificate-based authentication; and
  • protection of detection or response commands.

The 2026 modular structure requires those functions to be traced to the base profile and applicable Functional Packages. A vendor should not assume that a subsystem covered by a FIPS certificate is automatically inside the claimed TOE boundary or equivalent to the evaluated configuration.

Host Agent PP-Module v2.0 and EDR PP-Module v2.0

NIAP published updated Host Agent and Endpoint Detection and Response PP-Modules on January 13, 2026.

These modules are important examples of how CC:2022 composition moves cryptographic assurance into endpoint-management workflows.

Trusted policy and remediation content

Host agents and EDR components receive high-impact commands, policies, and remediation instructions. Digital signatures can protect the authenticity and integrity of that content. Current requirements reference modern FIPS 186-5-oriented RSA or ECDSA signatures.

The security argument should address:

  • who signs the policy or command;
  • where the trust anchor is stored;
  • how the signature is validated;
  • how rollback or replay is prevented;
  • what happens when validation fails;
  • whether the channel and object signature are separate controls; and
  • which cryptographic implementation performs verification.

Inherited application requirements

These modules commonly build on the Application Software Protection Profile. As a result, application-level random-bit-generation, secure storage, TLS, X.509, update, and failure requirements can become part of the combined PP-Configuration.

This is a frequent source of under-scoping. A vendor may focus on the EDR feature requirements while overlooking inherited entropy evidence required by the application base profile.

Authentication Servers PP-Module v2.0

The PP-Module for Authentication Servers, Version 2.0, published March 10, 2026, updates the authentication-server evaluation model to CC:2022 and the current Network Device cPP foundation.

Authentication servers can combine several cryptographic roles:

  • RADIUS or RadSec transport;
  • EAP-TLS;
  • certificate validation;
  • pre-shared keys;
  • HOTP or TOTP;
  • credential storage;
  • secure audit transfer;
  • management channels; and
  • generation of protocol nonces or secrets.

Entropy and key lifecycle are central

The evaluation should distinguish between random values used for:

  • long-term key generation;
  • ephemeral key establishment;
  • one-time-password seed generation;
  • protocol challenges;
  • salts;
  • session identifiers; and
  • IVs or nonces.

Different values may have different unpredictability, uniqueness, persistence, and destruction requirements. A single blanket statement that “all values are generated by the platform RNG” may not be enough to establish each SFR.

FIPS evidence must match the protocol role

For example, a FIPS-validated module may support HMAC, AES, ECDSA, or TLS-related primitives, but the Common Criteria evaluation still needs to show that the authentication server invokes the validated service in the claimed mode and environment.

Session Border Controllers PP-Module v2.0

The PP-Module for Session Border Controllers, Version 2.0, published March 17, 2026, updates the SBC framework for CC:2022 and the current network-device baseline.

SBCs sit at the intersection of signaling, media, identity, and network security. Depending on selected functionality, cryptography can include:

  • TLS-protected signaling;
  • certificate validation;
  • SRTP media protection;
  • key negotiation;
  • secure management;
  • update verification; and
  • audit protection.

The 2026 impact is less about one new cipher and more about disciplined composition. The Security Target must show which requirements come from the base profile, the SBC module, and any Functional Packages, and how the same cryptographic implementation supports those claims.

Stateful Traffic Filter Firewall PP-Module and PP-Configuration v2.0

The 2026 Stateful Traffic Filter Firewall module and configuration demonstrate the growing importance of the PP-Configuration as the evaluated unit.

A firewall’s packet-filtering logic may not itself depend heavily on cryptography, but the evaluated product still uses cryptography for:

  • administrative access;
  • audit transfer;
  • secure updates;
  • certificate validation;
  • authentication;
  • key storage; and
  • possibly VPN or other composed functions.

For vendors, the lesson is that feature modularity does not imply evidence independence. Base-profile cryptography, entropy, self-tests, and key-management requirements remain part of the configuration.

Application Software PP v2.0 as a 2026 inherited baseline

The Application Software Protection Profile, Version 2.0, was published in 2025, but it is central to 2026 because new Host Agent and EDR modules build upon it.

Architecture-specific random-bit generation

The Application Software PP distinguishes among applications that:

  • do not implement a DRBG and rely on a platform service;
  • use a platform-provided DRBG; or
  • implement their own approved DRBG.

When an application implements its own generator, additional requirements can cover entropy sources, external seeding, source combination, health testing, state updates, and failure behavior.

Nonces, IVs, and salts

Application evaluations increasingly require precise treatment of values that are sometimes casually grouped as “random.”

A value may need to be:

  • unpredictable;
  • unique under a key;
  • non-repeating;
  • generated by an approved RBG;
  • derived according to a protocol;
  • stored with protected state; or
  • bounded by a per-key invocation limit.

AES-GCM is a classic example. The security argument must address IV construction and the risk of repeating an IV under the same key. A validated AES-GCM implementation does not, by itself, prove that the calling application manages IVs correctly.

FIPS 186-5 and PQC readiness

The profile supports current classical signature requirements and includes an ML-DSA option in appropriate contexts. As with the GPCP profile, this should be interpreted as an available conformant capability, not an automatic mandate for every application.

FIPS impact deep dive

FIPS 186-5 replaces FIPS 186-4 as the modern signature baseline

FIPS 186-5 is the current NIST Digital Signature Standard. It covers approved use of RSA, ECDSA, and EdDSA. DSA is no longer approved for generating new signatures, although legacy verification treatment remains addressed by the standard and transition guidance.

The 2026 NIAP Technical Decisions show three kinds of migration work:

  1. Substantive replacement, where profile text changes from FIPS 186-4 to FIPS 186-5.
  2. Reference correction, where a profile already intends to use FIPS 186-5 but cites the wrong section or appendix.
  3. Transition relief, where a limited FIPS 186-4 option remains temporarily available for a specific profile context.

Product impact

Vendors should review:

  • cryptographic library versions;
  • CAVP algorithm certificates;
  • key-generation functions;
  • signature generation and verification;
  • RSA modulus sizes;
  • approved elliptic curves;
  • hash combinations;
  • deterministic versus randomized signature behavior;
  • operational environments; and
  • Security Target citations.

A product may be algorithmically compatible with FIPS 186-5 while its existing certificate or documentation still references FIPS 186-4. That gap should be identified before evaluation kickoff.

FIPS 140-3 evidence and NIAP Policy #5

NIAP Policy #5 is designed to avoid redundant cryptographic testing by allowing applicable CAVP or CMVP validation evidence to satisfy certain Common Criteria evaluation activities.

This can be highly valuable, but only when the evidence matches.

Evidence-matching questions

For each claimed cryptographic operation, ask:

  • Is the algorithm certificate for the same implementation?
  • Does it cover the same algorithm mode?
  • Does it cover the same key size or curve?
  • Does it cover the required direction, such as encrypt/decrypt or sign/verify?
  • Does it include the same DRBG options?
  • Is the implementation used in an approved mode?
  • Is the processor, operating system, firmware, or execution environment covered?
  • Is the library version identical?
  • Does the certificate apply to the TOE or only to an external platform service?
  • Does the Common Criteria SFR include requirements beyond algorithm correctness?

A “yes” to only the first question is not enough.

What Policy #5 does not replace

Even where certificate evidence is accepted, the evaluation still needs an adequate:

  • Security Target;
  • TOE summary specification;
  • cryptographic boundary description;
  • entropy description when required;
  • key lifecycle description;
  • interface mapping;
  • guidance documentation;
  • operational-environment statement;
  • self-test and failure explanation; and
  • response to every applicable evaluation activity.

Policy #5 is best treated as an evidence-reuse policy, not as a blanket exemption.

April 2026 FIPS 140-3 Implementation Guidance

NIST identifies the April 9, 2026 release as the latest FIPS 140-3 Implementation Guidance as of this report’s review date.

The update includes changes touching areas important to Common Criteria projects, including:

  • entropy estimation and SP 800-90B;
  • combining entropy from multiple sources;
  • CTR_DRBG without a derivation function;
  • public-key validity assurance;
  • self-test rules;
  • key/IV pair uniqueness;
  • key agreement and transport; and
  • management-manual references.

Why Common Criteria teams should care

A Common Criteria project may plan to reuse CMVP evidence. If CMVP guidance changes the conditions under which an entropy source, DRBG, key-establishment method, or self-test is approved, the reusability of that evidence can change as well.

The Common Criteria team should therefore track:

  • the FIPS 140-3 IG version used by the module validation;
  • caveats on the module certificate;
  • entropy-source validation status;
  • approved modes and services;
  • module boundaries;
  • operational environments;
  • revalidation status; and
  • any algorithm-transition dates.

SP 800-90B and entropy source validation

NIST requires applicable FIPS 140-2 and FIPS 140-3 validation submissions to justify conformance to SP 800-90B. FIPS 140-3 IG sections including D.J, D.K, and D.O address entropy-source inclusion, validation, and combination.

For Common Criteria evaluations, SP 800-90B evidence can be powerful, but the TOE architecture still matters. Questions remain such as:

  • Is the entropy source inside the TOE?
  • Is it inside the validated cryptographic module?
  • Does the TOE receive raw noise, conditioned entropy, or DRBG output?
  • Is the Common Criteria operational environment covered by the entropy validation?
  • Does the TOE add another conditioning or combination step?
  • Is the entropy quantity required by the selected CC SFR the same as the FIPS claim?
  • What happens if the external provider fails?

Entropy caveats can restrict key generation

CMVP certificate caveats can indicate that a DRBG entropy source does not satisfy the required entropy guidance for generating cryptographic keys or other sensitive security parameters. A Common Criteria project should review the certificate’s caveats rather than relying on the words “FIPS validated.”

SP 800-90C enters the active FIPS ecosystem

NIST published SP 800-90C in 2025, and 2026 updates to the FIPS 140-3 supplemental information added it to the approved random-bit-generator references. CMVP also indicates that it is accepting Random Bit Generator submissions in light of SP 800-90C.

This is strategically important because SP 800-90C addresses complete RBG constructions that combine entropy sources and DRBG mechanisms. Over time, it can improve the alignment between:

  • entropy-source assurance;
  • DRBG assurance;
  • complete random-bit-generator constructions; and
  • Common Criteria architecture claims.

Projects should expect terminology and evidence practices to continue evolving as SP 800-90C adoption matures.

FIPS 140-2 historical transition on September 21, 2026

NIST’s transition plan states that FIPS 140-2 validations are scheduled to move to the historical list on September 21, 2026. Historical status does not necessarily prohibit all use in existing systems, but it is a major procurement and product-planning milestone.

Common Criteria implications

A Common Criteria certificate and a FIPS certificate have different scopes and lifecycles. A product could retain a valid Common Criteria status while depending on a cryptographic module whose FIPS 140-2 certificate becomes historical.

Vendors and buyers should review:

  • whether the procurement requires an active FIPS certificate;
  • whether historical modules are permitted for an existing deployment;
  • whether a product update changes the cryptographic module;
  • whether a FIPS 140-3 successor is available;
  • whether the Common Criteria evaluated configuration includes the successor;
  • whether an assurance-maintenance action is needed; and
  • whether certificate claims in marketing materials remain accurate.

The safest roadmap is to treat the September 2026 transition as a dependency requiring explicit management, not as an administrative detail.

Post-quantum cryptography enters Common Criteria profiles

The inclusion of FIPS 203 ML-KEM and FIPS 204 ML-DSA options in current profile content marks an important transition. Common Criteria is beginning to evaluate products that may combine classical and post-quantum functions rather than treating PQC as a purely experimental feature.

What a credible PQC claim requires

A defensible Common Criteria PQC claim may need to address:

  • exact standardized parameter sets;
  • key and seed generation;
  • approved random-bit generation;
  • algorithm-validation status;
  • hybrid versus standalone operation;
  • protocol negotiation;
  • downgrade resistance;
  • certificate or trust-anchor handling;
  • key storage;
  • error handling;
  • secure update;
  • performance limits; and
  • the operational environment.

Hybrid cryptography complicates the boundary

A product may implement a hybrid key establishment using one classical and one post-quantum mechanism. The security argument should explain:

  • which component implements each mechanism;
  • how shared secrets are combined;
  • which KDF is used;
  • how failures in either mechanism are handled;
  • whether fallback is permitted;
  • how negotiation is authenticated; and
  • what validation evidence covers each component.

The appearance of a FIPS-standardized PQC algorithm does not eliminate the need to evaluate the surrounding protocol construction.

How the 2026 changes affect vendors

Security architects

Architects should freeze the cryptographic and entropy architecture early. Late discoveries about TOE boundaries, external entropy, DRBG modes, or operational-environment mismatches can force implementation changes rather than documentation edits.

Product developers

Developers need explicit failure handling. Code should prevent random-dependent operations after entropy or DRBG failure and should not silently fall back to an unapproved random source.

FIPS teams

The FIPS team should share certificate details, security policies, entropy reports, validation caveats, module boundaries, approved-service tables, and operational-environment data with the Common Criteria team.

Common Criteria authors

Security Target authors should avoid generic statements such as:

  • “The TOE uses FIPS-approved cryptography.”
  • “Random numbers are provided by the operating system.”
  • “The product uses a validated module.”

Instead, state the implementation, service, mode, parameters, boundary, interface, and evidence.

Test laboratories

Laboratories must evaluate certificate applicability, not merely certificate existence. They also need to track Technical Decisions issued after profile publication and ensure every modified evaluation activity is addressed.

Product managers

Product managers should include certification dependencies in release planning. A library upgrade, processor change, operating-system change, firmware rebuild, or PQC feature flag can alter the validated configuration.

How the 2026 changes affect federal buyers

Federal buyers should distinguish among several claims that are often conflated:

  • the product has a Common Criteria certificate;
  • the product is listed by NIAP;
  • the product uses a FIPS-validated module;
  • the cryptographic algorithm has CAVP validation;
  • the entropy source has suitable validation evidence;
  • the deployed configuration matches the evaluated configuration; and
  • the module remains active rather than historical.

A procurement requirement that says only “must be FIPS compliant” may be too vague to ensure the desired assurance.

A stronger requirement identifies:

  • FIPS 140-3 validation expectations;
  • acceptable certificate status;
  • required algorithms and parameter sets;
  • Common Criteria profile and version;
  • applicable PP-Modules and Functional Packages;
  • evaluated configuration;
  • required entropy evidence;
  • transition deadlines; and
  • update or maintenance obligations.

2026 readiness checklist for Common Criteria and FIPS teams

Conformance and document baseline

  • [ ] Identify the exact Base PP, PP-Modules, PP-Configuration, and Functional Packages.
  • [ ] Confirm each version and publication date.
  • [ ] Confirm that every PP-Module is allowed with the selected Base PP.
  • [ ] Determine whether exact conformance is required.
  • [ ] Capture every currently applicable NIAP Technical Decision.
  • [ ] Recheck Technical Decisions immediately before submission and validation.

Cryptographic inventory

  • [ ] List every cryptographic operation performed by the TOE.
  • [ ] Record algorithm, mode, key size, curve, hash, and protocol use.
  • [ ] Identify whether each operation is implemented by the TOE or a platform service.
  • [ ] Record the implementation and library version.
  • [ ] Record the processor, firmware, OS, and operational environment.
  • [ ] Map each operation to its SFR and evaluation activity.
  • [ ] Map each operation to CAVP or CMVP evidence.
  • [ ] Review all certificate caveats and approved-service restrictions.

Entropy and DRBG architecture

  • [ ] Identify each DRBG construction and option.
  • [ ] State whether a derivation function is used.
  • [ ] For CTR_DRBG without a derivation function, confirm the 384-bit entropy requirement where applicable.
  • [ ] Identify every entropy source.
  • [ ] Distinguish single-source, multiple-source, and external-seed designs.
  • [ ] Document conditioning and source combination.
  • [ ] Calculate required sample quantities from conservative min-entropy estimates.
  • [ ] Define startup and continuous health tests.
  • [ ] Define reseeding behavior.
  • [ ] Define behavior when entropy is unavailable or health tests fail.
  • [ ] Prevent all dependent cryptographic services from continuing insecurely.

FIPS 186-5 migration

  • [ ] Inventory all FIPS 186-4 references in code, documents, and certificates.
  • [ ] Identify the relevant 2026 Technical Decision for each profile.
  • [ ] Confirm RSA, ECDSA, EdDSA, curve, key-size, and hash support under FIPS 186-5.
  • [ ] Verify whether the certificate covers signature generation, verification, or both.
  • [ ] Document any authorized transitional use of FIPS 186-4.
  • [ ] Establish a removal date for transitional dependencies.

FIPS 140-3 transition

  • [ ] Identify every FIPS 140-2 module used by the product.
  • [ ] Review the September 21, 2026 historical transition impact.
  • [ ] Identify FIPS 140-3 successor modules.
  • [ ] Determine whether successor integration changes the Common Criteria evaluated configuration.
  • [ ] Review current FIPS 140-3 Implementation Guidance and Management Manual revisions.
  • [ ] Check entropy-source validation and certificate caveats.
  • [ ] Coordinate product, FIPS, CC, and procurement communications.

PQC preparation

  • [ ] Determine whether the selected profile permits or requires an ML-KEM or ML-DSA option.
  • [ ] Use exact FIPS-standardized parameter sets.
  • [ ] Document random generation for PQC seeds and keys.
  • [ ] Define hybrid-combination logic where applicable.
  • [ ] Prevent unauthenticated downgrade.
  • [ ] Map available algorithm-validation evidence.
  • [ ] Include performance and failure behavior in test planning.

Common implementation pitfalls

Pitfall 1: Equating AES-256 with 256 bits of required seed entropy

CTR_DRBG without a derivation function is the counterexample. The seed construction can require 384 bits of entropy.

Pitfall 2: Claiming a FIPS certificate without checking the environment

A certificate may cover one processor, operating system, firmware version, or build configuration but not the environment in the Security Target.

Pitfall 3: Reusing a module certificate as an entropy report

A CMVP certificate can support the assurance case, but the Common Criteria profile may still require architecture-specific entropy documentation.

Pitfall 4: Treating signature verification and generation as interchangeable

Algorithm-validation evidence often distinguishes operations. The TOE claim must match the certificate.

Pitfall 5: Ignoring Technical Decisions after profile selection

Technical Decisions can alter selections, references, evaluation activities, and transition options without waiting for a new profile version.

Pitfall 6: Continuing after a random-generation failure

Logging the failure while allowing key generation or nonce creation to continue defeats the security objective.

Pitfall 7: Adding PQC as an unscoped marketing feature

A PQC algorithm affects key generation, entropy, protocol logic, validation evidence, failure behavior, and the evaluated configuration.

Pitfall 8: Assuming a historical FIPS module is equivalent to an active one

Historical modules may remain usable in some existing-system contexts, but procurement and deployment policy may require active FIPS 140-3 validation.

Frequently asked questions

What is the most important Common Criteria cryptography update in 2026?

The most important overall change is the combination of CC:2022 modular conformance, more detailed entropy architecture, FIPS 186-5 migration, and current FIPS 140-3 evidence requirements. The 384-bit CTR_DRBG clarification is one of the most concrete technical changes.

Does every product now need 384 bits of entropy?

No. The 384-bit issue applies to specific constructions and selections, notably the relevant AES-256 CTR_DRBG case without a derivation function. Other approved DRBG configurations may use a 256-bit minimum-entropy selection. The applicable profile and Technical Decision control.

Does a FIPS 140-3 certificate satisfy Common Criteria cryptographic testing?

It may satisfy certain evaluation activities under NIAP Policy #5 when the implementation and environment match, but it does not automatically satisfy every Common Criteria requirement.

Is FIPS 186-4 prohibited in all 2026 NIAP evaluations?

No universal answer applies. FIPS 186-5 is the modern destination, and several 2026 decisions update profiles accordingly. However, NIAP has also issued targeted transition handling that temporarily permits FIPS 186-4 in a specific profile context. Check the exact profile and applicable Technical Decisions.

Do 2026 Protection Profiles require post-quantum cryptography?

Not across the board. Some current profiles include selectable FIPS 203 or FIPS 204 capabilities. Whether they are claimed depends on the product, profile operations, use case, and Security Target.

What happens to FIPS 140-2 certificates in September 2026?

NIST’s transition plan states that FIPS 140-2 validations move to the historical list on September 21, 2026. Existing-system use may still be permitted in some circumstances, but buyers and vendors should assess procurement rules and migration plans.

Can an application rely entirely on the operating system RNG?

A profile may permit use of a platform-provided DRBG, but the Security Target and evidence must identify the service, interface, operational environment, and assurance basis. Reliance on the platform is an architecture claim that must be documented.

Why are health tests important if an entropy source was already assessed?

Entropy behavior can change because of component failure, aging, environment, startup state, or manufacturing variation. Health tests help detect conditions under which the original entropy assessment no longer applies.

Does CAVP validation prove correct protocol use?

No. CAVP validation establishes algorithm implementation behavior for tested configurations. It does not prove correct certificate validation, IV uniqueness, nonce management, protocol negotiation, error handling, or key lifecycle in the complete product.

Strategic outlook

The 2026 updates point toward a Common Criteria ecosystem in which cryptographic assurance is increasingly compositional.

A credible product claim will combine:

  • an approved and correctly configured algorithm;
  • an adequate entropy source;
  • an approved DRBG or RBG construction;
  • correct protocol integration;
  • secure key storage and destruction;
  • self-tests and health tests;
  • secure failure behavior;
  • precise TOE and module boundaries;
  • valid operational-environment evidence; and
  • a permitted PP-Configuration.

FIPS 140-3, SP 800-90B, SP 800-90C, FIPS 186-5, FIPS 203, and FIPS 204 are becoming parts of this combined evidence system. None should be treated as a stand-alone badge that proves the whole product is secure.

The strongest organizations will respond by building a shared cryptographic assurance inventory used by engineering, Common Criteria, FIPS, product security, and federal sales teams. That inventory should be maintained as code, modules, certificates, profiles, and Technical Decisions change.

Conclusion

The 2026 Common Criteria updates affecting entropy and cryptography are best understood as an architectural modernization rather than a simple algorithm refresh.

Common Criteria 2022 is making exact conformance, PP-Configurations, PP-Modules, and Functional Packages operational realities. New and revised NIAP profiles are demanding a clearer account of where randomness originates and how DRBG failures are contained. Technical Decisions are making the 384-bit consequence of CTR_DRBG without a derivation function explicit. FIPS 186-5 is replacing FIPS 186-4, while carefully scoped transition provisions prevent unnecessary disruption. FIPS 140-3 guidance, SP 800-90B entropy evidence, SP 800-90C RBG constructions, and the September 2026 FIPS 140-2 historical transition are all affecting evaluation strategy.

For vendors, the primary lesson is straightforward: do not wait until Security Target drafting to discover the cryptographic architecture. Define the boundary, entropy path, DRBG configuration, algorithm evidence, failure behavior, and profile configuration while the product can still be changed.

For laboratories and buyers, the key lesson is equally important: certificates must be interpreted in context. Assurance comes from matching the evaluated implementation, environment, requirements, and evidence—not from the presence of a familiar acronym.

SEO publishing package

Recommended SEO title

2026 Common Criteria Crypto Updates: Entropy, FIPS 140-3 and Protection Profiles

Recommended meta description

Review the 2026 Common Criteria and NIAP updates affecting entropy, CTR_DRBG, FIPS 186-5, FIPS 140-3, Protection Profiles, and post-quantum cryptography.

Suggested article excerpt

The 2026 Common Criteria landscape tightens entropy evidence, modernizes Protection Profiles for CC:2022, advances FIPS 186-5 adoption, and changes how FIPS 140-3 validation can support NIAP evaluations. This report explains the most important updates and provides a practical readiness checklist.

Suggested internal-link anchors

  • Common Criteria evaluation planning
  • FIPS 140-3 validation strategy
  • SP 800-90B entropy assessment
  • cryptographic algorithm validation
  • post-quantum cryptography compliance
  • NIAP Protection Profile consulting
  • federal product certification roadmap

Suggested structured-data type

Use Article or TechArticle schema with:

  • headline
  • description
  • datePublished
  • dateModified
  • author
  • publisher
  • mainEntityOfPage
  • keywords
  • about
  • citation

Official sources and further reading

Common Criteria

  1. Common Criteria for Information Technology Security Evaluation, CC:2022, Part 1

https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART1R1.pdf

  1. Common Criteria for Information Technology Security Evaluation, CC:2022, Part 3

https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART3R1.pdf

  1. Common Criteria for Information Technology Security Evaluation, CC:2022, Part 5

https://www.commoncriteriaportal.org/files/ccfiles/CC2022PART5R1.pdf

NIAP policy and profiles

  1. NIAP Policy #5 Frequently Asked Questions / Addendum

https://www.niap-ccevs.org/Policy/PolicyLTR5Addendum1.pdf

  1. NIAP Policy #5 Mapping Addendum

https://www.niap-ccevs.org/Policy/policy-ltr-5-add2.pdf

  1. NIAP Protection Profile for General-Purpose Computing Platforms, Version 2.0

https://www.niap-ccevs.org/statichtml/protection-profile/539/PPGPCP_v2.0.html

  1. NIAP Application Software Protection Profile, Version 2.0

https://www.niap-ccevs.org/statichtml/protection-profile/516/PPAPP_V2.0.html

  1. NIAP PP-Module for VPN Gateways, Version 2.0

https://www.niap-ccevs.org/statichtml/protection-profile/527/MODVPNGW_v2.0.html

  1. NIAP PP-Module for Wireless Intrusion Detection and Prevention Systems, Version 3.0

https://www.niap-ccevs.org/statichtml/protection-profile/528/MODWIDS_V3.0.html

  1. NIAP PP-Module for Host Agent, Version 2.0

https://www.niap-ccevs.org/statichtml/protection-profile/525/MODHA_v2.0.html

  1. NIAP PP-Module for Endpoint Detection and Response, Version 2.0

https://www.niap-ccevs.org/statichtml/protection-profile/526/MODEDR_v2.0.html

  1. NIAP PP-Module for Authentication Servers, Version 2.0

https://www.niap-ccevs.org/statichtml/protection-profile/534/MODAUTHSVR_v2.0.html

  1. NIAP PP-Module for Session Border Controllers, Version 2.0

https://www.niap-ccevs.org/statichtml/protection-profile/532/MODSBC_v2.0.html

  1. Network Device international Technical Community

https://nd-itc.github.io/

  1. Common Criteria PP-Configuration for Network Devices and Stateful Traffic Filter Firewalls, Version 2.0

https://www.commoncriteriaportal.org/files/ppfiles/CFGNDcPP-FWv2.0.pdf

NIAP Technical Decisions

  1. TD0943 — CTR_DRBG entropy clarification

https://www.niap-ccevs.org/technical-decisions/TD0943

  1. TD0990 — 384-bit random-bit-generation selection

https://www.niap-ccevs.org/technical-decisions/TD0990

  1. TD0999 — FIPS 186-5 update for Hardcopy Devices

https://www.niap-ccevs.org/technical-decisions/TD0999

  1. TD1020 — Network Device cPP FIPS 186 transition handling

https://www.niap-ccevs.org/technical-decisions/TD1020

  1. TD1042 — FIPS 186-5 update for Full Drive Encryption

https://www.niap-ccevs.org/technical-decisions/TD1042

  1. TD1051 — Application Software FIPS 186-5 reference correction

https://www.niap-ccevs.org/technical-decisions/TD1051

  1. TD1054 — VPN Client FIPS 186-5 reference correction

https://www.niap-ccevs.org/technical-decisions/TD1054

NIST and FIPS

  1. FIPS 186-5, Digital Signature Standard

https://csrc.nist.gov/pubs/fips/186-5/final

  1. FIPS 140-3 Implementation Guidance announcements

https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements

  1. Current FIPS 140-3 Implementation Guidance PDF

https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

  1. FIPS 140-3 Management Manual

https://csrc.nist.gov/projects/cryptographic-module-validation-program/cmvp-fips-140-3-management-manual

  1. CMVP Entropy Validations

https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations

  1. CMVP Entropy Validation Documents

https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-validations/documents

  1. CMVP certificate caveats

https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules/caveats

  1. SP 800-140D supplemental information

https://csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-information/sp800-140d

  1. FIPS 140-3 transition information

https://csrc.nist.gov/projects/fips-140-3-transition-effort

  1. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard

https://csrc.nist.gov/pubs/fips/203/final

  1. FIPS 204, Module-Lattice-Based Digital Signature Standard

https://csrc.nist.gov/pubs/fips/204/final

Reviewed against publicly available source material through July 28, 2026. Protection Profiles, Technical Decisions, implementation guidance, and validation policies can change after publication. Verify the current versions before making certification or procurement decisions.