On September 22, 2026, an important label changed across a large population of cryptographic modules. The National Institute of Standards and Technology’s Cryptographic Module Validation Program explains that FIPS 140-2 validations moved from the Active list to the Historical list. Those modules may continue to be used for existing systems under the program’s stated conditions, but new systems should use appropriately validated FIPS 140-3 modules.
This is not an announcement that every FIPS 140-2 implementation suddenly became insecure. It is a governance transition. The operational challenge is knowing which deployed products depend on which validated module, what status applies now, and whether the system is existing, modified, or new.
A validation certificate is time-sensitive evidence
Many inventories record “FIPS validated” as a permanent Boolean field. That loses the facts decision-makers need. Validation attaches to a specific module version and operational environment, has a certificate identifier and status, and may have constraints that do not cover every way a product uses it. Program status can change even if the installed binary does not.
A useful record should capture the standard, certificate number, module name and version, vendor, validated operational environments, status, status-observation date, sunset information, and the product or service that embeds the module. It should also record whether the deployed configuration matches the scope described by the certificate.
Without those relationships, a team may know that a vendor has a FIPS 140-3 certificate but not whether its installed product uses that module. Conversely, a product page may continue to say “FIPS 140-2 validated” without explaining that the certificate is now historical.
Historical does not mean universally forbidden
CMVP states that FIPS 140-2 modules can remain in existing systems after their move to the Historical list, while new systems should not select them. That creates a classification problem. Procurement, architecture, and compliance teams need a shared definition of new and existing in their governing context. A major upgrade, re-platforming, expansion, cloud migration, or contract renewal may trigger review even when the service name remains unchanged.
The inventory should not guess. It should connect each affected system to the applicable policy interpretation, decision owner, decision date, exception or transition plan, and supporting evidence. Organizations operating under different regulatory or contractual regimes must confirm their own requirements rather than applying a federal program statement mechanically.
Procurement needs certificate-level acceptance criteria
A vendor questionnaire that asks whether a product is “FIPS compliant” is too vague. Procurement should request:
- the exact CMVP certificate and current status;
- the module and version included in the proposed product release;
- the supported operational environment and configuration;
- which cryptographic operations use the validated boundary;
- the plan for maintaining validation through product updates;
- dependencies that sit outside the validated boundary; and
- evidence that delivery matches the evaluated configuration.
Those facts should become acceptance evidence, not remain in an email attachment. They also need re-evaluation when software, firmware, hardware, or deployment architecture changes.
The transition intersects with PQC
FIPS 140-3 status and post-quantum capability answer different questions. Validation provides assurance about a cryptographic module and its implementation requirements. PQC readiness concerns whether systems can use approved quantum-resistant algorithms in the protocols and trust relationships that matter.
A FIPS 140-3-validated module is not automatically proof that a product supports ML-KEM or ML-DSA, that the algorithms are enabled, or that peers negotiate them. Likewise, a product may advertise PQC support in an experimental or non-validated configuration. Inventory records should keep these dimensions separate: module validation, algorithm implementation, configuration, protocol use, observed negotiation, and system coverage.
This separation prevents a procurement team from treating a newer certificate as a complete PQC migration result. It also helps migration teams identify products whose assurance path and quantum-resistant capability mature on different schedules.
What organizations should do next
First, identify every system whose assurance claim relies on a FIPS 140-2 certificate. Use procurement records, configuration, software inventories, architecture documentation, supplier attestations, and authorized discovery. Record where coverage remains unknown.
Second, enrich those records with certificate status and scope. Do not overwrite the historical fact that a system was deployed under an active validation; preserve observations over time so reviewers can reconstruct decisions.
Third, create procurement controls for new systems and material changes. Require a current FIPS 140-3 certificate where applicable and verify that the delivered configuration is actually within its boundary.
Fourth, assign transition decisions for existing systems. Some may remain acceptable until replacement. Others may warrant accelerated upgrade because of sensitivity, exposure, lifecycle, supplier support, or an upcoming architecture change.
Finally, monitor status as external data. Validation is not a one-time document collection exercise. Periodic reconciliation can flag certificates or modules whose status changes after deployment.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps teams connect deployed cryptography to modules, products, systems, owners, policies, exceptions, and evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and a discovery gap is not proof that an affected module is absent.
Learn more about Vista’s cryptographic inventory and CBOM and compliance evidence.
Where uncertainty remains
The correct treatment of a historical validation depends on the system, agency, contract, and controlling policy. Product branding may not reveal the embedded module or validated configuration. Teams should confirm decisions with the applicable authority and current CMVP records. The durable lesson is that validation status is changing external evidence, and it belongs in the same governed inventory as the deployment that relies on it.
Source
- Cryptographic Module Validation Program, National Institute of Standards and Technology, FIPS 140-2 active-list transition effective September 22, 2026.