On September 21, 2026, every remaining FIPS 140-2 certificate moved to the Historical List maintained by the Cryptographic Module Validation Program (CMVP). No system shut down. No encryption stopped working. But for federal agencies, the contractors that serve them, and the many state and regulated organizations that follow federal requirements, the date changed what counts as a validated cryptographic module going forward.
According to NIST, which runs the program with Canada's Cyber Centre, FIPS 140-3 took effect in 2019, and the CMVP stopped accepting FIPS 140-2 submissions for new certificates in April 2022. The final step of the transition is now complete: all FIPS 140-2 certificates are historical.
Most of the coverage has focused on vendors racing to complete FIPS 140-3 validation. That matters. But the more useful lesson for security and data teams is not about any single product's certificate. It is about how hard it is to answer a simple question: where is our encryption, and who controls it?
What the Historical List Actually Means
The change is easy to overstate, so precision helps. Moving to the Historical List does not mean a certificate has been revoked or that a module is suddenly insecure. Based on NIST's definition of the Historical list and its transition guidance:
- New systems: Federal agencies "should not include" modules on the Historical List in new systems.
- Existing systems: CMVP "supports the purchase and use of these modules for existing systems," and modules can still be procured for legacy systems.
- Risk decisions: Agencies "may make a risk determination" on whether to continue using historical modules, based on where and how each module is used.
- Timing: NIST notes that federal agencies decide when they move to FIPS 140-3-only modules.
In practice, that means FIPS 140-2 modules can keep running where they already are, but new projects, new procurements, and new authorizations increasingly expect FIPS 140-3. Every organization that sells to or operates under federal requirements now needs to know which of its systems fall into which category.
Why FIPS 140-3 Raised the Bar
FIPS 140-3 is not simply a renumbered standard. As Keyfactor summarizes, it adds requirements for mitigating non-invasive attacks, such as side-channel analysis, at higher security levels, and it requires vendors to formally document the entropy sources used for key generation. Those are meaningful improvements to how cryptographic modules are designed and tested.
They also take time to validate. Keyfactor estimates that a traditional FIPS 140-3 validation takes roughly 18 to 30 months from initiation to certificate, and the CMVP queue is also handling a growing volume of post-quantum algorithm work. For organizations that depend on vendors still in that queue, the transition will play out over years, not days.
The Real Challenge Is Finding the Cryptography
Ask most organizations which cryptographic modules protect their sensitive data, and the answer is rarely a single list. Encryption is often embedded separately in every layer: the database engine, the storage array, the backup platform, the file-sharing service, the analytics tool, the application library, and the cloud service. Each one has its own module, its own key store, its own configuration, and its own vendor roadmap.
That fragmentation is manageable until something changes. Then every system becomes its own project. A transition like FIPS 140-2 to 140-3 requires teams to inventory each product, check each certificate, contact each vendor, and plan each upgrade. The same exercise will repeat as organizations move toward post-quantum cryptography.
We have written before about the foundations of crypto agility: the ability to change algorithms, keys, and cryptographic providers without rebuilding the systems that depend on them. The FIPS 140-2 sunset is a practical test of that ability, and a preview of the larger transitions ahead.
Validated Encryption Is Necessary, but It Is Not the Whole Answer
Validation tells you that a cryptographic module implements approved algorithms correctly and meets defined security requirements. It does not tell you what the module protects, or who can get the data out of it.
As we covered in Is Your Data Secure With Encryption at Rest and in Transit?, a fully validated disk or database encryption module still decrypts data for any user or process the system considers authorized. If an attacker compromises the application, or an insider has broader access than they need, validated encryption at the storage layer does not stand in the way.
That is why the compliance question, "Is our encryption validated?", should be paired with a security question: "Is our sensitive data still protected when it is in use, copied, or exported, and is access governed by policy?"
Five Questions to Ask Now
Security, compliance, and data teams can use the transition as a prompt to review their environments:
- Where is cryptography protecting sensitive data today? Build an inventory that covers databases, file stores, backups, applications, endpoints, and cloud services, not just network devices.
- Which modules are FIPS 140-3 validated, and which are historical? Record certificate numbers and status for each, and flag systems that are planned for new procurement or reauthorization.
- Who controls the keys? Keys scattered across many products are hard to rotate, audit, or migrate. Centralized, policy-driven key management makes future changes far easier.
- Does protection follow the data? Check whether sensitive values stay encrypted, masked, or tokenized when data is exported, shared, or used in analytics and AI workflows.
- How quickly could you change algorithms? If moving one system to a new module would take months, the post-quantum transition will take much longer. Plan for agility now.
OnData's Take
The FIPS 140-2 sunset is a compliance milestone, but it exposes a structural problem. When encryption is scattered across dozens of systems, each with its own keys and vendor timelines, every change to cryptographic standards becomes an expensive inventory and migration project. And even perfectly validated storage encryption cannot protect data from users and applications that are allowed to read it.
A data-centric approach treats protection as a property of the data, applied consistently and governed by policy. OnData SecureDB protects sensitive database fields with runtime encryption and identity-based access control, and OnData SecureFile keeps encryption and access controls attached to sensitive files wherever they travel. Managing protection at the data layer gives organizations one place to see what is protected, who can access it, and how it will adapt when standards change again.
Standards will keep evolving. The organizations best prepared for the next transition will be the ones that know exactly where their sensitive data is and how it is protected.
