CNSA 2.0 vs CNSA 1.0: What Changed and What Defence Suppliers Must Do Differently

The 2027 acquisition deadline in NSA's Commercial National Security Algorithm Suite 2.0 is not a migration target. It is a procurement gate. From 2027, contracting officers on National Security System programmes will write CNSA 2.0 algorithm support into new acquisition requirements. A supplier who cannot demonstrate that capability will not compete for those contracts. Development timelines and FIPS 140-3 validation cycles mean the work must start now if a 2027-ready product is the goal.

Most defence suppliers understand that CNSA 2.0 replaces CNSA 1.0. Fewer understand what that replacement actually involves at the implementation level, and fewer still have mapped the compliance hierarchy that connects NSA's algorithm mandate to their specific DFARS clause obligations and CMMC assessment. This article works through both.

What CNSA 1.0 Was and Why It Cannot Continue

NSA published the original Commercial National Security Algorithm Suite in January 2016. The suite defined the approved cryptographic algorithms for protecting National Security Systems (NSS): those systems handling classified national security information, supporting intelligence and military missions, or whose compromise would cause serious damage to US national security, as defined in 44 USC §3552(b)(6). The 1.0 suite was built around elliptic-curve and classical public-key algorithms: RSA (minimum 3072-bit), ECDH and ECDSA on the P-384 curve, Diffie-Hellman (minimum 3072-bit), AES-256, and SHA-384.

The public-key component of that suite is fully quantum-vulnerable. RSA's security rests on the computational difficulty of factoring large integers. ECDSA and ECDH rest on the discrete logarithm problem over elliptic curves. Peter Shor's algorithm, running on a cryptographically relevant quantum computer (CRQC), solves both problems in polynomial time. NSA confirmed its own position in the August 2021 Quantum Computing FAQ: RSA and ECC provide no security against a CRQC.

CNSA 1.0 was not designed for that threat model. CNSA 2.0 is.

What CNSA 2.0 Actually Changed

NSA published CNSA 2.0 in September 2022. The central change is not a parameter upgrade. It is a wholesale replacement of the public-key component. RSA, ECDH, ECDSA, and Diffie-Hellman are removed from the approved list for NSS use entirely. They are not deprecated on a slow schedule. They are replaced.

The approved algorithms in CNSA 2.0 are:

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardised as FIPS 203 by NIST in August 2024, is the key establishment replacement. The three FIPS standards and their enterprise sequencing logic are covered in depth in the FIPS 203/204/205 implementation decision map. It is based on the Module Learning With Errors problem, a structured lattice hardness assumption with no known efficient quantum or classical attack. ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardised as FIPS 204, is the primary signature replacement. SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), standardised as FIPS 205, handles software and firmware signing where stateless operation is operationally required.

Note what CNSA 2.0 does not include: hybrid classical-plus-post-quantum schemes. NSA's position is direct migration to quantum-only algorithms by the deadline dates. This differs from NCSC guidance, which recommends hybrid schemes during the transition period. For UK-registered defence suppliers operating under US NSS contracts, the applicable standard is CNSA 2.0, not UK NCSC guidance. The two frameworks are not interchangeable.

A common misconception worth correcting directly: CNSA 2.0 is not CNSA 1.0 with new algorithms added. The key establishment mechanism changes from discrete-log and integer-factoring hardness to module lattice hardness. These are architecturally incompatible. A system supporting CNSA 1.0 key exchange requires a new KEM implementation for CNSA 2.0, not a parameter adjustment to an existing one.

The Migration Timelines: What They Mean in Practice

NSA's CNSA 2.0 advisory specifies transition deadlines by system category:

The 2027 date in the general NSS row is not an operational migration deadline. It is the point at which NSS programme managers are required to write CNSA 2.0 capability into acquisition requirements. Existing fielded systems have until 2030–2033 to retire CNSA 1.0. But the suppliers competing for the contracts that deliver those 2030–2033 migrations need validated, production-ready products by 2027 to win those competitions.

FIPS 140-3 validation of a cryptographic module (the independent testing required for use in federal and national security environments) typically takes 12 to 24 months from submission (based on historical CMVP queue patterns; check the current CMVP status page for the most recent published estimates). Integration testing, Common Criteria evaluation where applicable, and programme-specific qualification add further lead time. A supplier who begins development in late 2026 will not have a validated product ready for the 2027 acquisition cycle. The risk is not being shut out on 17 January 2027. The risk is being absent from the procurement pipeline that builds the next decade of NSS capability.

What Suppliers Actually Need to Change

Working through this practically, the changes fall across five areas.

TLS termination and key exchange. Every TLS handshake that establishes session keys using ECDH must be replaced with ML-KEM-1024 for NSS-adjacent applications. As of mid-2026, production-capable ML-KEM implementations are available in OpenSSL 3.x (via Open Quantum Safe's liboqs integration), wolfSSL, and BoringSSL. FIPS 140-3 validation of those implementations is the constraint. Library support and validated module support are not the same thing.

Code signing and software distribution. Firmware and software distributed to NSS programmes must be signed with SLH-DSA for stateless signing scenarios, or ML-DSA-87 where stateless operation is not required. This affects build pipelines, CI/CD signing infrastructure, and the PKI hierarchies that issue signing certificates. The PKI itself must use ML-DSA.

Certificate authorities and the full PKI chain. An intermediate CA signed with ECDSA P-384 cannot issue a trust chain that ends in a CNSA 2.0-compliant leaf. The migration requires replacing the full hierarchy (root CA, intermediate CAs, and end-entity certificates) with ML-DSA-signed counterparts. This is not a leaf-certificate rotation problem. It is a root-level replacement programme that must be co-ordinated across every system trusting that hierarchy.

HSM and key management infrastructure. Hardware Security Modules holding CNSA 1.0 keys may not support ML-KEM or ML-DSA. As of mid-2026, FIPS 140-3 validated modules with ML-KEM and ML-DSA support are in early-stage availability. The PKCS#11 v3.1 standard (OASIS, 2023) defines the mechanism identifiers for PQC operations; suppliers should confirm their HSM platform's PKCS#11 v3.1 support before committing to a specific vendor.

Cryptographic inventory. Before any algorithm can be replaced, a supplier must know what they have. This is not optional under the compliance hierarchy described below. NIST SP 800-171 Rev 3 practice 3.13.10 requires employment of FIPS-validated cryptographic mechanisms; knowing which mechanisms are in use is the prerequisite to demonstrating that requirement is met. In every PQC migration project I have worked on, the cryptographic inventory phase alone takes six to twelve months. That is the time required to map where RSA, ECC, and Diffie-Hellman are deployed across an organisation's infrastructure. That clock starts when the inventory starts, not when the acquisition deadline arrives.

For a structured approach to identifying which systems are in scope, the QSECDEF Cryptographic Asset Prioritisation Matrix provides a risk-tiered framework for sequencing migration work.

The Compliance Hierarchy: Why "It Doesn't Apply to Us" Is Wrong

Defence suppliers working on NSS-adjacent programmes operate under a compliance stack. CNSA 2.0 sits at the top, but it does not float free of other obligations.

Directly below CNSA 2.0 is NIST SP 800-171 Rev 3 (December 2023), which governs protection of Controlled Unclassified Information (CUI) in non-federal systems. Practice 3.13.10 requires FIPS-validated cryptographic mechanisms. With FIPS 203, 204, and 205 now published standards, new implementations in regulated environments are expected to use those algorithms. The connection between SP 800-171 Rev 3's "FIPS-approved algorithms" language and the August 2024 FIPS publications is logical rather than explicitly stated in a DoD mapping document, but it is the direction of travel.

DFARS 252.204-7012 operationalises SP 800-171 as a contract clause. It requires DoD contractors to implement adequate security on covered defence information (CDI) systems and to report cyber incidents within 72 hours. Crucially, paragraph (m) of that clause mandates flow-down: prime contractors must include the clause in subcontracts involving CDI. A second-tier software vendor whose product processes covered defence information is in scope regardless of whether it has a direct DoD contract.

CMMC v2.02 is the enforcement mechanism. The DoD published the final CMMC rule under 32 CFR Part 170 in October 2024, and CMMC Level 2 requirements began appearing in contract solicitations from 2025. CMMC Level 2 maps directly to SP 800-171 Rev 3's 110 practices; Level 3 maps to SP 800-172's enhanced requirements. The compliance hierarchy is self-reinforcing: CMMC Level 2 certification requires SP 800-171 Rev 3 compliance, which requires FIPS-approved cryptographic controls, which for new NSS-adjacent systems means CNSA 2.0 algorithms.

The sub-tier flow-down issue matters more than most suppliers appreciate. The argument that CNSA 2.0 only applies to prime contractors with direct NSS contracts is false. DFARS 252.204-7012's paragraph (m) is a mandatory flow-down provision. If you handle covered defence information, you are in scope.

Three Questions We Hear from Suppliers

"CNSA 2.0 is just CNSA 1.0 with new algorithms added." It is not. CNSA 2.0 removes the classical public-key algorithms from the approved list for NSS use. The structural change is from discrete-log and integer-factoring hardness to lattice hardness and hash-based construction. The two suites are not additive. CNSA 2.0 replaces CNSA 1.0's public-key component wholesale, while leaving the symmetric and hashing layers untouched.

"We can wait until 2027." This conflates the procurement gate with a production deadline. Products must be developed, validated under FIPS 140-3, and production-ready before 2027 to enter the acquisition cycle. With a 12–24 month CMVP validation queue, development that does not start until 2026 will not produce a 2027-ready product. The practical deadline for beginning development of any product that competes for NSS contracts from 2027 is now.

"CNSA only applies to prime contractors." The DFARS 252.204-7012 flow-down clause (paragraph (m)) makes this wrong. Prime contractors must include the clause in any subcontract involving CDI. Any sub-tier supplier whose systems process, store, or transmit covered defence information is in scope.

What to Do Now

The practical sequencing follows from the compliance hierarchy and the technical dependencies. Start with the cryptographic inventory: you cannot migrate what you have not mapped. Assess which systems are in scope under DFARS 252.204-7012 and CMMC Level 2. Prioritise ML-KEM-1024 for key establishment in any system handling CDI or NSS-adjacent data, because harvest-now-decrypt-later (HNDL) attacks make that exposure present-tense, not theoretical: adversaries collecting encrypted traffic today are storing it for decryption when the hardware arrives. The HNDL threat mechanism is covered in detail separately. ML-DSA-87 for signing infrastructure follows. SLH-DSA for software and firmware signing, particularly where stateless operation is operationally required, comes next.

We work with defence suppliers at exactly this stage of the migration: from cryptographic inventory through to procurement readiness. QSECDEF membership gives access to the practitioner-level methodology documentation and the community of security architects navigating the same compliance hierarchy. The path is not simple, but it is defined.