Compliance
CNSA 2.0 Timeline Explained: The NSA's Post-Quantum Deadlines (2025–2033)
CNSA 2.0 deadlines by category (2025–2033), the Jan 1 2027 NSS acquisition gate, ML-KEM/ML-DSA mapping, and the first step for gov and defense vendors.
CNSA 2.0 Timeline Explained: The NSA's Post-Quantum Deadlines (2025–2033)
If you sell software, hardware, or services into National Security Systems (NSS), the NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is no longer a future concern — its earliest milestones already landed in 2025. CNSA 2.0 sets staggered deadlines, by system category, for adopting post-quantum cryptography, and from January 1, 2027, new NSS acquisitions must support it. This is a clear, skimmable reference for those dates, what they mean, and the one thing every government contractor and defense supplier should do first.
What CNSA 2.0 Is — and Who It Binds
CNSA 2.0 is the NSA's mandate for the cryptography that protects National Security Systems against the threat of a future cryptographically relevant quantum computer (CRQC). It replaces today's RSA- and elliptic-curve-based suites with post-quantum algorithms on a fixed timeline.
The distinction that matters for your business: CNSA 2.0 is mandatory for National Security Systems. If you build or supply products that handle NSS data, compliance is not optional — it is a procurement gate. For everyone else (commercial enterprises, non-NSS government work, the broader supply chain), CNSA 2.0 is one of the strongest best-practice signals available about where federal cryptography is heading and on what schedule. Defense primes increasingly flow these expectations down to subcontractors, so even if you don't touch NSS data directly, your customers may.
The Algorithms: CNSA 2.0 Maps to the NIST Standards
CNSA 2.0 does not invent new cryptography. It points to the algorithms NIST finalized on August 13, 2024:
- ML-KEM (FIPS 203) — the key-encapsulation mechanism formerly known as Kyber, used for key exchange and encryption.
- ML-DSA (FIPS 204) — the digital-signature algorithm formerly known as Dilithium, used for signing.
In other words, when you read "support CNSA 2.0," that means migrating your key exchange to ML-KEM/FIPS 203 and your signatures to ML-DSA/FIPS 204. These are finalized, published federal standards — not drafts — which is why the NSA can attach hard dates to them. (NIST also finalized FIPS 205 / SLH-DSA for hash-based signatures, with additional algorithms such as FN-DSA/Falcon and the backup KEM HQC still in progress as of 2026.) If you want the deeper background on each standard, see our explainer on the NIST PQC standards — FIPS 203, 204, and 205.
The CNSA 2.0 Timeline, by System Category
The NSA does not flip a single switch. Each category of system has two key dates: when products must support and prefer the new algorithms, and when those algorithms become exclusive (the only ones permitted). Here is the schedule.
| System category | Support & prefer by | Exclusive by | |---|---|---| | Software & firmware signing | 2025 | 2030 | | Web browsers, servers & cloud services | 2025 | 2033 | | Networking equipment (VPNs, routers) | 2026 | 2030 | | Operating systems | 2027 | 2033 | | Niche & constrained environments | 2030 | 2033 |
A few things stand out when you read this as a vendor:
- Software and firmware signing is first. The "support and prefer" milestone was 2025, and exclusivity arrives in 2030 — the tightest window on the chart. If you ship signed code or firmware updates into NSS, this is your leading edge.
- Networking equipment is on a fast exclusivity track. VPNs and routers only need to prefer PQC by 2026, but they must be PQC-exclusive by 2030 — the same end date as code signing, despite a later start.
- Browsers, servers, cloud, and operating systems run to 2033. These categories get the longest runway to exclusivity, reflecting how much of the ecosystem has to move in lockstep.
- Niche and constrained devices (think low-power or specialized hardware that can't easily carry larger PQC keys) are last, on a 2030/2033 cadence.
The January 1, 2027 Acquisition Gate
There is one date on this timeline that functions differently from the rest, and it deserves its own heading: from January 1, 2027, new NSS acquisitions must support CNSA 2.0.
This is a procurement gate, not a per-category technical deadline. It means that when a National Security System buys new equipment or software from that date forward, CNSA 2.0 support is expected to be part of what's being purchased. For a vendor, the practical implication is blunt: a product that cannot demonstrate CNSA 2.0 support risks being non-competitive — or simply ineligible — for new NSS business after the start of 2027.
That makes 2027 the date to plan backward from. Migration, testing, and validation take time, and the categories that reach exclusivity in 2030 (signing and networking) leave the least slack. If your roadmap doesn't already have CNSA 2.0 on it, the acquisition gate is the reason it should.
See where your organization stands — run a free CipherReady readiness scan and get a cryptographic inventory of your public TLS, certificates, and algorithms in about 3 minutes.
What To Do First: Inventory Before You Migrate
It's tempting to jump straight to "swap RSA for ML-KEM." But you cannot migrate what you cannot see, and you cannot show a contracting officer progress against the CNSA 2.0 timeline without a baseline. The first move is an inventory.
Start with what's externally visible and easiest to enumerate: your public TLS endpoints, the certificates behind them, and the public-key algorithms (RSA and elliptic-curve) they rely on. This gives you three things at once:
- A starting point. A concrete picture of which systems use classical cryptography today — the systems CNSA 2.0 will eventually require you to change.
- A way to show progress. Once you have a baseline, "we are X% migrated" becomes a defensible, measurable claim rather than an assertion.
- A prioritization map. Knowing which endpoints fall into the signing, networking, server/cloud, and OS categories lets you sequence work against the right deadlines instead of treating everything as equally urgent.
Building this picture is exactly what a TLS certificate inventory is for, and it feeds directly into the broader discipline of crypto-agility — the practice of structuring systems so you can change cryptographic algorithms without re-architecting. CNSA 2.0's two-date-per-category structure is essentially a crypto-agility schedule: support first, go exclusive later. The vendors who'll handle it most smoothly are the ones who can change algorithms on demand.
CipherReady runs a safe, external, metadata-only scan of domains you own or are authorized to test. It inventories your public TLS certificates, TLS versions, DNS exposure, and public-key algorithms, then produces a CipherReady Readiness Score and an executive PDF report you can put in front of leadership or attach to a compliance narrative. It is not a vulnerability scanner or a pentest — no exploitation, no credentials, no intrusive testing. It's the visibility layer that makes a CNSA 2.0 plan real. For a fuller walkthrough of the obligations specific to your sector, our government contractor PQC compliance guide goes deeper.
How CNSA 2.0 Fits the Bigger Picture
CNSA 2.0 doesn't exist in a vacuum. PQC is already shipping in the commercial world: Chrome 131 (November 2024), Firefox 135 (February 2025), OpenSSL 3.5.0 (April 2025), and Apple's OS v26 all support the hybrid X25519MLKEM768 key exchange, and Cloudflare measured roughly 38% of human HTTPS traffic using hybrid post-quantum TLS by March 2025. The infrastructure the NSA is mandating is the same infrastructure browsers and servers are adopting on their own.
The urgency behind all of it is "harvest now, decrypt later" (HNDL): adversaries can collect encrypted long-lived data today and decrypt it once a CRQC exists. The Global Risk Institute's 2025 quantum threat timeline puts the median expert estimate for a CRQC at roughly 2029–2032, with about a 34% probability by 2030 — which is precisely the window in which CNSA 2.0's exclusivity dates land. The deadlines aren't arbitrary; they're calibrated to the threat.
Frequently Asked Questions
Is CNSA 2.0 mandatory for my company?
It is mandatory for systems that qualify as National Security Systems. If your products or services handle NSS data, CNSA 2.0 compliance is required on the published timeline. If you operate outside NSS, it is not legally binding on you — but it is a strong best-practice signal, and defense primes increasingly pass these expectations down to subcontractors, so it may reach you contractually.
What does the January 1, 2027 deadline actually require?
From that date, new acquisitions for National Security Systems must support CNSA 2.0. It's a procurement gate: products bought into NSS from the start of 2027 are expected to support the post-quantum algorithms. It does not mean every existing system must already be exclusive — the per-category exclusivity dates (2030 and 2033) govern that.
Which algorithms does CNSA 2.0 require?
CNSA 2.0 maps to the NIST standards finalized on August 13, 2024: ML-KEM (FIPS 203) for key establishment and encryption, and ML-DSA (FIPS 204) for digital signatures. Migrating to "support CNSA 2.0" means adopting these published federal standards.
Where should we start if we haven't begun?
Inventory first. Enumerate your externally visible TLS endpoints, certificates, and public-key algorithms so you know your starting point, can prioritize by the right category deadline, and can demonstrate measurable progress. A free CipherReady scan produces that baseline in about three minutes.
Get Your CNSA 2.0 Starting Point Today
The CNSA 2.0 clock is already running — software and firmware signing began in 2025, and the January 1, 2027 acquisition gate is close. The first deliverable on any credible plan is visibility into the cryptography you run today.
Run a free CipherReady readiness scan to inventory your public TLS, certificates, and algorithms and get a CipherReady Readiness Score plus an executive PDF report in about three minutes. When you're ready to monitor continuously, manage multiple domains, or handle client portfolios as an MSP, our pricing scales from Basic to Pro/MSP. Know your starting point — then show your progress.