CNSA 2.0 compliance for government and defense contractors runs on four dates, not one: January 1, 2027 for new National Security System acquisitions, 2030 for software, firmware, and networking equipment, 2031 for Department of War systems in active use, and 2033 for the remaining categories. Most coverage of this topic leads with 2033. This guide leads with 2027, because that is the date that decides whether a contractor is even eligible to bid on the systems this mandate governs. Below is the complete breakdown: what CNSA 2.0 requires, when each deadline lands, what compliance work actually involves, and where the mandate’s coverage stops.
What CNSA 2.0 Is
CNSA 2.0 is the National Security Agency’s suite of quantum-resistant cryptographic algorithms, combined with the migration schedule for adopting them, for National Security Systems specifically. First issued in September 2022, it replaces CNSA 1.0, the RSA and elliptic-curve suite that had been standard policy. The approved algorithm list is narrow by design:
- ML-KEM-1024 for key establishment
- ML-DSA-87 for digital signatures
- AES-256 for symmetric encryption
- SHA-384 or SHA-512 for hashing
- LMS or XMSS for firmware signing
CNSA 2.0 applies to National Security Systems — classified and defense-related systems — rather than the broader federal or commercial estate. Civilian agencies and general enterprises instead follow Executive Order 14412, signed in June 2026, which sets post-quantum deadlines for federal high-value assets outside National Security Systems and is expected to reach contractors more broadly through a Federal Acquisition Regulation rule. The two frameworks are frequently conflated in casual discussion. They shouldn’t be: a defense contractor building for a classified system needs to track CNSA 2.0, not the executive order’s separate timeline.
The Deadline Structure
January 1, 2027 is the date that forces action first. Starting on this date, new National Security System acquisitions are expected to already be CNSA 2.0 compliant. Because defense acquisition cycles typically run 18 to 36 months from design to delivery, systems being architected now will reach delivery after this gate has already closed. This is a procurement eligibility date, not a soft target.
After that gate, the schedule runs by product category:
- 2030 — software and firmware signing, plus traditional networking equipment such as VPNs and routers, must use CNSA 2.0 exclusively.
- 2031 — under the Department of War’s Post-Quantum Cryptography Strategy, released June 2026, every DoW system must be using post-quantum cryptography, having supported it since the end of 2030.
- 2033 — web and cloud services, operating systems, large public-key infrastructure, and constrained devices reach full CNSA 2.0 exclusivity, which the NSA has also set as its internal target for substantial completion across the board.
For a first-hand account of why the difference between what’s protected and what’s actually covered trips teams up in practice, this piece is worth reading before you finalize a compliance timeline.
What Compliance Work Actually Involves
Three workstreams, roughly in order of urgency:
- Cryptographic inventory: Before anything can be scheduled, an organization needs to know which systems, libraries, and protocols still rely on RSA or elliptic-curve algorithms, and where. A Department of War memorandum on preparing for the migration already directs contractors toward this exercise for systems holding department data.
- FIPS 140-3 validation: National Security System products require FIPS 140-3 validated cryptographic modules — a distinct requirement from simply supporting the right algorithms — and validation queues run long enough that starting late is a common, expensive mistake.
- Crypto-agility: The approved algorithm list has already narrowed once: NSA excluded SLH-DSA even after NIST standardized it for civilian use. Systems built on standard interfaces for key management, rather than one algorithm hard-coded into the application layer, treat a future list change as a configuration update rather than a redesign.
What CNSA 2.0 Does Not Cover
CNSA 2.0 raises the strength of the algorithms protecting a connection. It does not address whether that connection can be recorded in the first place. A fiber tap captures whatever signal is on the line regardless of which key-exchange algorithm is running above it.
This is the basis of the harvest-now-decrypt-later problem, and the CNSA 2.0 timeline itself extends the exposure window: with category deadlines running to 2033, years of traffic will continue crossing the network under today’s key exchange before CNSA 2.0-approved algorithms are the only ones in use. Traffic recorded during that window carries whatever encryption was active at the moment of capture. AES-256, the symmetric cipher that protects the payload itself, already meets the post-quantum bar; the exposure is specifically in the key exchange that establishes the session.
Cryptanalytic capability is also not advancing on the quantum front alone. Anthropic’s Frontier Red Team reported in July 2026 that an AI model accelerated a classical attack on a reduced-round research variant of AES-128 by 200 to 800 times over the prior best result. The result did not break full AES-128 or AES-256 and had no production impact, but it is a documented case of AI functioning as an active tool in cryptanalytic research.
Do you know Your Keys Are Safe. Your Traffic Might Not Be.? It unpacks this same key-exchange-versus-payload distinction in podcast form, with specific attention to where compliance checklists tend to stop.
One Vendor Addressing the Recording Gap
CyberRidge works at the optical transmission layer rather than the algorithm layer. The table below summarizes how its Carmel platform is positioned relative to a CNSA 2.0 compliance program.
| Attribute | Detail | Relevance to a CNSA 2.0 program |
|---|---|---|
| Layer of operation | Layer 1, the optical transmission itself | Protects data crossing the network during the multi-year migration to CNSA 2.0-approved algorithms |
| Protection method | Signal spread across the optical spectrum, buried below the noise floor, with optical keys embedded in the light | Removes the clean, recordable signal a harvest-now-decrypt-later attacker depends on |
| Relationship to CNSA 2.0 | Complementary, not a substitute | Does not replace NSA-approved algorithms or FIPS 140-3 validation; operates beneath where those run |
| Interoperability | Company-reported to run over existing fiber and DWDM, standard 100GbE interfaces | Avoids dedicated key-distribution fiber |
| Deployment | Four-week phased sequence (company-reported) | Fits inside procurement cycles already compressed by the 2027 deadline |
Read as a whole, the table points to a narrow but specific role: CyberRidge does not touch algorithm compliance, and a contractor still needs CNSA 2.0-approved cryptography in FIPS 140-3 validated modules regardless of what runs at the physical layer. What it addresses is the separate, unmandated question of whether sensitive traffic can be recorded at all while that multi-year migration is still in progress.
Bottom Line
Treat January 1, 2027 as the operative deadline for any CNSA 2.0 compliance program, not 2030 or 2033 — procurement eligibility is decided at the point of acquisition. Build the cryptographic inventory now, confirm FIPS 140-3 validation paths early, and architect for algorithm replacement rather than a single migration event. Separately from the compliance timeline, assess which links carry data with a long confidentiality lifetime, and evaluate whether a 2033 migration schedule would have protected that data had it been recorded today. Where the answer is no, the exposure sits at the physical layer, and that’s a gap algorithm compliance alone does not close.
FAQ
Q: What is CNSA 2.0?
A: CNSA 2.0 is the National Security Agency’s approved suite of quantum-resistant cryptographic algorithms, along with the schedule for adopting them, for National Security Systems — classified and defense-related systems. It replaced CNSA 1.0, the RSA and elliptic-curve suite previously in policy, and its deadlines run from a January 1, 2027 procurement gate through full category migration by 2033.
Q: What is the first CNSA 2.0 deadline contractors need to plan around?
A: January 1, 2027, when new National Security System acquisitions are expected to already be CNSA 2.0 compliant. Because acquisition cycles run 18 to 36 months, systems being designed now need to already account for this date rather than the later 2030 and 2033 deadlines most discussions emphasize.
Q: Does CNSA 2.0 compliance protect against data being recorded off a fiber link?
A: No. CNSA 2.0 governs the strength of the algorithms securing a connection, not whether the connection can be physically recorded. A fiber tap captures whatever signal crosses the line independent of the key-exchange algorithm running above it, which is why harvest-now-decrypt-later is treated as a separate risk from algorithm compliance.
Q: Does deploying CyberRidge’s Carmel platform satisfy CNSA 2.0 requirements?
A: No. Compliance still requires NSA-approved algorithms such as ML-KEM-1024 and ML-DSA-87 running in FIPS 140-3 validated modules. Carmel operates at the optical transmission layer beneath that cryptography, and CyberRidge positions it as a complementary layer that addresses recordability rather than a substitute for algorithm compliance.
Q: How does CyberRidge’s approach relate to post-quantum cryptography generally?
A: CyberRidge describes Carmel as working alongside post-quantum cryptography rather than replacing it. Post-quantum algorithms protect the key exchange at the digital layer; Carmel’s Photonic Layer Security operates at the optical layer beneath it, addressing whether the transmitted signal itself can be recorded while a post-quantum migration is still underway.