CNSA 2.0 Deadlines Explained: What 2025–2033 Means for You
A plain-language breakdown of the NSA's CNSA 2.0 timeline — which algorithms it mandates, the category-by-category deadlines, and who actually has to comply.
CNSA 2.0 is the most concrete post-quantum mandate any government has published, and its deadlines are frequently misread. This article lays out what the NSA's Commercial National Security Algorithm Suite 2.0 actually requires, the staggered timeline by system category, and who is — and isn't — obligated to follow it.
For the broader migration context, see our Post-Quantum Cryptography Migration Guide.
What CNSA 2.0 mandates
CNSA 2.0 is the NSA's algorithm suite for National Security Systems (NSS) — the systems handling classified and national-security information in the US. It specifies a small, deliberately conservative set of algorithms:
- ML-KEM-1024 for key establishment (the largest, most conservative ML-KEM parameter set).
- ML-DSA-87 for digital signatures (likewise the highest-strength ML-DSA parameter set).
- AES-256 for symmetric encryption.
- SHA-384 or SHA-512 for hashing.
- LMS and XMSS (stateful hash-based signatures, per NIST SP 800-208) for software and firmware signing.
Notably, SLH-DSA is excluded for general NSS use. And where the commercial world is adopting ML-KEM-768, CNSA 2.0 deliberately requires the larger -1024 parameter set — a higher security margin appropriate for national-security data.
The timeline, by category
The single biggest source of confusion is treating CNSA 2.0 as one deadline. It isn't — it's a staggered set of milestones that differ by the type of system. Here's the breakdown.
Software and firmware signing. Support and prefer CNSA 2.0 from 2025; make it the exclusive option by 2030. This category moves first because code-signing roots are long-lived and especially exposed.
Web browsers, servers, and cloud services. Support and prefer CNSA 2.0 by 2025; exclusive by 2033. This is the category most commercial TLS operators map onto.
Traditional networking equipment (VPNs, routers). Support and prefer by 2026; exclusive by 2030.
Operating systems. Support and prefer by 2027; later exclusive dates apply.
New NSS acquisitions. Any newly acquired national-security system must support CNSA 2.0 by January 1, 2027. This is the date that matters most for vendors selling into the federal/defense space — if your product can't speak CNSA 2.0 by then, it can't be acquired for NSS use.
The NSA's stated expectation is that the vast majority of cryptography in an NSS should be quantum-resistant by December 31, 2031, with the category-specific exclusive dates extending to 2033.
Who actually has to comply
This is where teams either over- or under-react. CNSA 2.0 is mandatory for US National Security Systems and the vendors who sell products into them. If you're a defense contractor, a federal supplier touching NSS, or you build products that need to be acquirable by those buyers, CNSA 2.0 is a hard requirement with the dates above.
If you're a commercial company with no NSS exposure, CNSA 2.0 does not legally bind you. But it still matters for two reasons. First, it's the clearest signal of where the whole industry is heading — the algorithm choices and the rough timeline are a sensible template even for private-sector planning. Second, if you sell anything to the US government or to companies that do, CNSA 2.0 compliance increasingly shows up as a procurement requirement that flows down the supply chain.
How CNSA 2.0 compares to other frameworks
CNSA 2.0 is stricter than the civilian baselines. Where NIST IR 8547 proposes deprecating classical algorithms after 2030 and disallowing them after 2035, and the EU roadmap targets 2030 for high-risk infrastructure and 2035 for full migration, CNSA 2.0's exclusive dates (2030–2033) and its insistence on the largest parameter sets put it at the demanding end of the spectrum. If you build to CNSA 2.0, you're comfortably ahead of the civilian frameworks. For the European side of the picture, see NIS2 and DORA cryptography requirements.
A caveat on policy drift
Government procurement policy around PQC has not been perfectly stable, and some prescriptive mandates have been adjusted over time. The algorithm choices in CNSA 2.0 (ML-KEM-1024, ML-DSA-87) are settled; the exact procurement enforcement around them can shift. Treat the algorithm targets as firm and keep an eye on the enforcement details if you sell into the federal space.
Where to start
Whether CNSA 2.0 binds you legally or just sets your north star, the first step is the same: know what your systems currently negotiate. PQScore shows you, per domain, whether your TLS is offering post-quantum key exchange and what your certificate signatures use — the two things CNSA 2.0 cares about most.