Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to resist attacks from both classical and quantum computers. Most security teams treat it as a future planning problem. They note the 2030 deprecation and 2035 disallowance deadlines from NIST IR 8547, add them to a roadmap, and move on. The clock has already moved past planning.
The most immediate compliance event is September 21, 2026, when every active FIPS 140-2 certificate moves to Historical status, and therefore, federal agencies should not include those modules in new procurements. The FIPS 140-3 validation process now runs two to three years end-to-end. Any vendor not already in the pipeline will not be federally accepted in time. That window has closed for anyone starting today.
These are not distant milestones. Several deadlines are weeks away, and the work required to meet them takes longer than most planning documents acknowledge.
Three Laws That No Executive Order Can Touch
The foundation of U.S. PQC obligations is federal law passed by Congress. Executive orders can be rewritten or canceled. These laws cannot. Changing them requires an act of Congress, and none of them have been touched since they passed.
The National Quantum Initiative Act (Public Law 115-368, December 2018) created the National Quantum Coordination Office and directed roughly $1.275 billion toward quantum research across the Department of Energy, NSF, and NIST for fiscal years 2019 to 2023. It laid the federal groundwork that every subsequent PQC policy has built on.
The Quantum Computing Cybersecurity Preparedness Act (Public Law 117-260, December 2022) is where things shifted from research to action. It passed the House 420 to 3 and cleared the Senate without opposition. The law required the Office of Management and Budget (OMB) to direct every federal agency to build and maintain an inventory of IT systems at risk from quantum decryption, and to issue migration guidance within one year of NIST finalizing its PQC standards. NIST published those standards on August 13, 2024, making the guidance deadline August 2025. As of mid-2026, no OMB-issued PQC migration guidance has been publicly released in response to that statutory requirement. Annual reporting to Congress on migration progress is required through at least 2029.
On June 22, 2026, President Trump signed an executive order titled “Securing the Nation Against Advanced Cryptographic Attacks,” adding a new layer of urgency to the compliance picture described above. The order directs OMB and the National Cyber Director to lead a nationwide PQC migration and sets two hard deadlines for agencies transitioning high-value assets and high-impact systems: December 31, 2030, for key establishment, and December 31, 2031, for digital signatures. Agencies must designate a PQC migration lead within 30 days.
The Federal Acquisition Regulatory Council is directed to publish a proposed rule amending the Federal Acquisition Regulation to require covered contractors to comply with FIPS-compliant PQC standards by the end of 2030, within 180 days of the order. That proposed rule must go through notice-and-comment rulemaking before it becomes binding. The requirement, once finalized, will cascade directly into the vendor and contractor ecosystem.
The significance of this order is not just the deadlines themselves, but what they signal about the direction and urgency of federal enforcement. The Biden-era framework set 2035 as the general planning horizon. This order pulls that forward by four to five years for the federal government’s most critical systems. For organizations navigating the CNSA 2.0 acquisition gate and the FIPS 140-3 sunset simultaneously, the new executive order removes any remaining ambiguity about where this is heading.
This is not a forward-looking compliance window. It has already compressed to the point where late movers are running out of options, and the standards underpinning every one of these deadlines were finalized less than two years ago.
These laws create obligations that no administration can remove through executive action. A change in administration can affect how aggressively they are enforced. It cannot erase the inventory requirements, the reporting obligations, or the migration mandates written into the law.
NIST Standards, the Validation Gap, and What CSWP 39 Changes
NIST finalized its first three PQC standards on August 13, 2024, after an eight-year international evaluation process.
| Standard | Algorithm | Function |
|---|---|---|
| FIPS 203 | ML-KEM | Key encapsulation, replacing RSA and ECDH |
| FIPS 204 | ML-DSA | Digital signatures, replacing ECDSA and RSA-PSS |
| FIPS 205 | SLH-DSA | Hash-based backup digital signature scheme |
One detail worth repeating: SLH-DSA is a finalized NIST standard available for broad use. But it is not part of Commercial National Security Algorithm (CNSA) 2.0. Per the NSA CNSA 2.0 FAQ v2.1 (December 2024): “While SLH-DSA is hash-based, it is not part of CNSA and is not approved for any use in NSS.” If your organization operates National Security Systems (NSS), SLH-DSA is not a substitute for ML-DSA.
NIST IR 8547, published as an Initial Public Draft in November 2024 and still in that status as of mid-2026, sets the deprecation schedule: RSA-2048 and ECC P-256 are targeted for deprecation by 2030, with full removal of quantum-vulnerable public-key algorithms from NIST standards by 2035.
FIPS 206 will be the fourth PQC standard from NIST, specifying FN-DSA, the FFT over NTRU-Lattice-Based Digital Signature Algorithm. It was submitted under the name FALCON and selected in July 2022. As of mid-2026, FIPS 206 remains at the initial public draft stage, with finalization expected in late 2026 or early 2027.
Existing FALCON implementations are not compatible with FN-DSA as specified in FIPS 206: NIST introduced substantive changes during standardization, including moving salt sampling inside the repeat loop rather than outside as in the original FALCON specification, and hashing the public key, both of which alter signature output and break interoperability between FALCON and FN-DSA verifiers. Organizations with FALCON code in production will need to update those implementations to conform with FIPS 206 before relying on them for compliance purposes.
Its primary advantage is signature and key size, making it attractive for bandwidth-constrained protocols, but signing requires floating-point arithmetic over NTRU lattices that is difficult to implement in constant time. As of mid-2026, FIPS 206 is in its Initial Public Draft stage. The final standard is expected in late 2026 or early 2027. FN-DSA is not part of CNSA 2.0 and is not approved for use in NSS. NSA has stated it does not currently plan to add future NIST PQC standards to CNSA.
Knowing which algorithms are finalized matters, but the harder constraint for most organizations is getting those algorithms into a federally validated module before the procurement clock runs out.
The FIPS 140-3 Validation Crunch
FIPS 140-2 validated modules can continue to be accepted by federal agencies through September 21, 2026. After that, the Cryptographic Module Validation Program (CMVP) will place them on the Historical list, allowing agencies to continue using them for existing systems only. For new procurement, agencies should use FIPS 140-3 validated modules.
The overall FIPS 140 validation process has stretched from approximately two years to three years for FIPS 140-3, with the CMVP-controlled portion alone averaging between 542 and 590 days depending on the period measured, compared to 367 days under FIPS 140-2, based on independent analysis of NIST’s public Modules in Process list data. A vendor starting today has no realistic path to certification before the September 2026 deadline. The FIPS 140-3 procurement preference taking effect in September 2026 and the CNSA 2.0 compliance requirement for new NSS acquisitions in January 2027 fall within four months of each other.
That convergence points to a deeper issue: organizations managing a single cryptographic transition will face the same crunch again unless they build in the capacity to adapt continuously.
What NIST CSWP 39 Means
In December 2025, NIST finalized Cybersecurity White Paper CSWP 39, Considerations for Achieving Crypto Agility: Strategies and Practices. This document makes something explicit that had previously been implicit in federal guidance: crypto agility is not optional. NIST defines it as “the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations.”
The central message of CSWP 39 is stated in its Executive Summary: “crypto agility is a key practice that should be adopted at all levels, from algorithms to enterprise architectures.” The document also makes clear that the PQC migration “will certainly not be the last transition required.” Agility needs to be designed in from the start, not added later.
For organizations operating or selling into National Security Systems, that principle is already operational as CNSA 2.0 has translated it into specific algorithm mandates and a staggered deadline schedule.
CNSA 2.0 and the Full Deadline Stack
For organizations operating NSS, or selling into that supply chain, CNSA 2.0 v2.1, updated by NSA in December 2024, is the binding standard. Its algorithm requirements, as specified in the CNSA 2.0 FAQ v2.1, are ML-KEM-1024 (FIPS 203) for key establishment and ML-DSA-87 (FIPS 204) for digital signatures in any use case.
The CNSA 2.0 deadline stack is not a single date. It is a staggered set of requirements by system type:
- January 1, 2027: All new NSS acquisitions must support CNSA 2.0 algorithms. Software and firmware signing should already support and prefer CNSA 2.0 signing algorithms by this date, with the preferred milestone having been set at 2025 in the original NSA advisory.
- December 31, 2030: All deployed software and firmware on NSS must be using CNSA 2.0 signatures exclusively. Legacy networking equipment, including VPN concentrators and routers, must also complete the transition to exclusive use of CNSA 2.0 algorithms. Per the NSA CNSA 2.0 FAQ v2.1: “NSA expects these equipment transitions to be completed by December 31, 2030.”
- December 31, 2031: Per the NSA CNSA 2.0 FAQ v2.1, NSA expects that by this date “the vast majority of cryptography in an NSS should be quantum resistant.”
- By 2033: Operating systems must reach exclusive use of CNSA 2.0. Custom applications, legacy equipment, and niche systems follow the same endpoint.
- 2035: Full quantum resistance required across all NSS, aligning with the 2035 national objective set by National Security Memorandum 10 (NSM-10).
The January 2027 date is the one that arrives first. Defense acquisition cycles run 18 to 36 months. A program being scoped today for delivery in 2027 or 2028 must already account for ML-KEM-1024 and ML-DSA-87 support. If the product does not support these at the point of procurement, it will not get procured.
The Department of War (DoW) Chief Information Officer memorandum titled “Preparing for Migration to Post-Quantum Cryptography,” dated November 20, 2025, and signed by Acting CIO Katie Arrington, explicitly bans procurement of quantum key distribution systems for confidentiality purposes in DoW environments and requires all PQC-related technologies to be approved by the DoW CIO PQC Directorate before testing, evaluation, or deployment.
Navigating this layered stack of validation timelines, acquisition gates, and approval requirements simultaneously is more than most security teams are staffed to absorb alone.
How Encryption Consulting Can Help
If you are wondering where and how to begin your PQC journey, Encryption Consulting is here to support you through our PQC Advisory Services. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise.
We begin with a Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure. This builds the baseline you need before any migration can begin.
From there, we conduct a PQC Assessment to evaluate your exposure to quantum threats, identify RSA- and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.
With that clarity, we develop a PQC Strategy and Roadmap, a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve.
We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout.
Finally, we manage Full Implementation, deploying hybrid classical and quantum-safe models, rolling out PQC across your PKI and infrastructure, and setting up monitoring for long-term cryptographic health.
CBOM Secure
Encryption Consulting’s CBOM Secure gives security and governance teams a continuously updated view of every cryptographic algorithm, library version, and certificate across the organization. For teams navigating the FIPS 140-3 sunset, CNSA 2.0 acquisition gates, and NIST IR 8547 deprecation timelines at the same time, CBOM Secure provides the factual baseline that makes compliance assessments credible, vendor conversations specific, and board reporting defensible. It surfaces cryptographic drift and flags FIPS 140-2 dependencies before they become September 2026 procurement problems.
Organizations that engage now arrive at each compliance gate with documented progress, a defensible inventory, and a migration plan that auditors and contracting officers can verify. Organizations that wait arrive with exposure they cannot quickly explain. If you are ready to move from awareness to action, we are ready to help you start.
Conclusion
The U.S. PQC compliance picture in 2026 is active obligations, not future milestones. The three federal laws at the foundation of this framework hold regardless of which administration is in office. The FIPS 140-3 validation crunch, the CNSA 2.0 January 2027 acquisition gate, and the September 2026 FIPS 140-2 sunset are not warnings. There are deadlines that are already here.
These three near-term realities are working together. The validation backlog means vendor readiness needs to be checked today. Programs currently in procurement are already inside the CNSA 2.0 compliance window. And organizations that have migrated key exchange but not authentication are only partially protected.
NIST CSWP 39 makes clear that this will not be the last cryptographic transition your organization faces. The goal is to build the capability to handle the next one with less disruption. Start with the inventory. Audit your vendors. Run both workstreams in parallel.
