Marin Ivezic
Most post-quantum guidance tells organizations to prepare. The NSA’s Commercial National Security Algorithm Suite 2.0, published in September 2022 and revised twice since, tells them what to install, at which parameter level, and by when. From January 1, 2027, a new acquisition for a US National Security System has to support CNSA 2.0 algorithms, and a product that doesn’t cannot be fielded.
A National Security System (NSS) is a US government system that handles classified information, or that performs an intelligence, cryptologic, command-and-control, or weapons function. The category is narrower than “federal”, and that narrowness is exactly why CNSA 2.0 can be prescriptive where broader federal guidance stays advisory. NSA acts here as National Manager for NSS, and it sets requirements rather than recommendations.
This article reads CNSA 2.0 the way a compliance function has to read it: as a set of obligations with owners, evidence and dates, rather than as a cryptography paper.
Where CNSA 2.0 sits in the policy stack
Several US directives govern federal cryptography, and they operate at different altitudes. Confusing them is the most common reason a compliance register ends up with the wrong deadline in it.
- National Security Memorandum 10 (May 2022). Sets the whole-of-government destination: migrate to quantum-resistant cryptography by 2035. No algorithms, no product categories.
- OMB Memorandum M-23-02 (November 2022). Inventory and reporting duties for Federal Civilian Executive Branch agencies. It does not govern NSS.
- The Quantum Computing Cybersecurity Preparedness Act (December 2022). Puts the migration requirement into federal law.
- CNSA 2.0 (September 2022, FAQ revised through version 2.1). The algorithm list, the parameter levels and the category timeline, for NSS.
- CNSSP 15. The standing Committee on National Security Systems policy stating which algorithms NSS must use. The updated version incorporates CNSA 2.0 and deprecates CNSA 1.0, which is what moves the requirement into assessment and authorization.
- Executive Order 14144 (January 2025). Reinforces the timeline and directs publication of quantum-safe product categories.
The practical difference is specificity. NSM-10 says migrate by 2035. CNSA 2.0 says use ML-KEM-1024 (Kyber) for key establishment, use ML-DSA-87 (Dilithium) for signatures, support both in networking equipment by 2026, and stop accepting anything else by 2030.
One detail from FAQ version 2.1 has caught out organizations that started early. Implementations built against the pre-standard ML-KEM and ML-DSA specifications, including draft versions of the FIPS documents, are not CNSA 2.0 compliant even though the underlying mathematics is the same. Only conformance to final FIPS 203 and FIPS 204 counts. If your suppliers demonstrated a prototype before August 2024, that prototype needs rebuilding, and the certificate you accept as evidence needs to name the final standard.
The mandated suite
CNSA 2.0 approves one option per cryptographic function, and it takes the top parameter set in every case.
| Function | Algorithm | Standard |
|---|---|---|
| Symmetric encryption | AES-256 | FIPS 197 |
| Key establishment | ML-KEM-1024 | FIPS 203 |
| Digital signatures | ML-DSA-87 | FIPS 204 |
| Hashing | SHA-384 or SHA-512 | FIPS 180-4 |
| Firmware and software signing | LMS or XMSS, single-tree only | NIST SP 800-208 |
AES-256 is unchanged from CNSA 1.0. A 256-bit symmetric key retains roughly 128 bits of security against Grover’s algorithm, which is enough for the foreseeable quantum future. Nothing to migrate here.
ML-KEM-1024 replaces RSA key transport, Diffie-Hellman and ECDH. A key encapsulation mechanism, or KEM, is the post-quantum shape of a key exchange: one party encapsulates a fresh shared secret against the other’s public key and sends the resulting ciphertext, and the recipient decapsulates it. NIST standardized three parameter sets. CNSA 2.0 approves only the largest, ML-KEM-1024, at NIST security level 5. ML-KEM-512 and ML-KEM-768 are FIPS-approved and are not permitted in NSS.
ML-DSA-87 replaces RSA signatures and ECDSA. Again, only the level 5 parameter set qualifies. ML-DSA-44 and ML-DSA-65 do not.
The size consequences are worth putting in front of an architecture review early, because they drive protocol and hardware decisions rather than policy ones. An ML-KEM-1024 public key and ciphertext are 1,568 bytes each. An ML-DSA-87 public key is 2,592 bytes and its signature is 4,595 bytes, against 96 bytes for an ECDSA P-384 signature. Constrained links, embedded devices and large certificate hierarchies feel that difference directly.
Signing firmware
LMS and XMSS are hash-based signature schemes approved only for firmware and software signing. NSA names LMS with SHA-256/192 as its preferred parameter set. Both schemes are stateful, meaning each private key can produce a finite number of signatures and the signing state must advance exactly once per signature. Reusing a state, which is what happens when a signing key is restored from backup or failed over to a second appliance, destroys the security of the scheme. NIST SP 800-208 therefore requires strict state management and secure storage of the signing key to prevent state reuse. It does not mandate a hardware security module (HSM), a tamper-resistant appliance that holds keys and performs cryptographic operations without exporting them, but an HSM is the recommended way to meet the requirement, and it is the route most programmes take.
For GRC purposes, that requirement converts into a procedural control rather than a product control. You need documented state management, documented backup and disaster-recovery behaviour for the signing HSM, and a key ceremony record. A product certificate alone does not evidence it.
NSA prioritized LMS and XMSS for firmware because validated implementations reached the market before ML-DSA did, and because a firmware root of trust is close to unpatchable after deployment. ML-DSA-87 is also approved for signing and is the right answer where signing volume exceeds what a single key tree supports, or where signing is distributed across sites.
SHA3-384 and SHA3-512 may be used inside hardware for self-contained integrity functions such as boot checks, at the vendor’s discretion. SHA-3 is not approved as a general-purpose hash.
What CNSA 2.0 leaves out
The exclusions carry as much compliance weight as the inclusions, because a supplier can offer a FIPS-validated algorithm that still fails the mandate.
SLH-DSA (SPHINCS+, FIPS 205) is excluded from all NSS use. NIST standardized it precisely as a conservative hedge: its security rests on hash function properties rather than lattice hardness, so a future break in lattice cryptography would leave it standing. NSA’s reasoning points at operational cost. At the security level CNSA 2.0 uses elsewhere, SLH-DSA signatures run from roughly 30 kilobytes to about 50 kilobytes depending on variant, against 4,595 bytes for ML-DSA-87, and every additional approved algorithm multiplies interoperability testing. Not every national authority agrees with the trade. Germany’s BSI takes the more cautious line and recommends keeping a non-lattice signature option in reserve.
FN-DSA (Falcon) will not be added even after NIST finalizes it. NSA cites its susceptibility to implementation errors that affect security, and states that it does not currently plan to add future NIST post-quantum standards to the suite at all. Read that as a stability commitment: the menu you are budgeting against is intended to stay the menu.
HashML-DSA, the pre-hash mode defined in FIPS 204, is prohibited. Standard SHA-384 or SHA-512 with ML-DSA-87 delivers the same outcome without fragmenting implementations.
HSS and XMSS^MT, the multi-tree variants, are not approved. Single-tree only, because multi-tree state management is harder to get right.
SHA-3 and SHAKE as general-purpose hashes are not approved.
The timeline, by system category
Each category has two dates: a support-and-prefer date, when systems must be capable of CNSA 2.0 and should default to it, and an exclusive-use date, after which classical-only operation is no longer permitted.
| Category | Support and prefer | Exclusive use |
|---|---|---|
| Software and firmware signing | 2025 | 2030 |
| Web browsers, servers, cloud services | 2025 | 2033 |
| Traditional networking equipment | 2026 | 2030 |
| Operating systems | 2027 | 2033 |
| Niche equipment | 2030 | 2033 |
| Custom applications, legacy equipment | Update or replace by 2033 |
Signing sits earliest because a firmware verification routine shipped today may still be in service in 2040. If a cryptanalytically relevant quantum computer (CRQC), meaning a machine capable of breaking RSA and elliptic-curve cryptography at deployed key sizes, exists by then, that device’s firmware integrity cannot be trusted and cannot be retrofitted.
Networking equipment has the most compressed span: prefer by 2026, exclusive by 2030. Network traffic is the classic target for harvest now, decrypt later (HNDL) collection, where an adversary records encrypted traffic today and decrypts it once a CRQC exists. The protocol surface is also narrow, mostly IKEv2 and IPsec, which makes the transition tractable.
That last point comes with a caveat your auditors will meet. IKEv2 cannot yet operate entirely without CNSA 1.0 algorithms in every configuration, and hybrid key establishment combining a classical algorithm with ML-KEM-1024 remains acceptable during the transition. A supplier claiming CNSA 2.0 support in a VPN product may therefore be shipping a hybrid mode, which is legitimate. What is not legitimate is a configuration where the CNSA 2.0 algorithm is present but not preferred.
There is no grandfather clause anywhere in the schedule. Systems that cannot be updated must be replaced by 2033.
How the mandate is enforced
Four mechanisms turn the schedule into something a compliance function can test.
The acquisition gate. From January 1, 2027, new acquisitions for NSS must support CNSA 2.0 unless an exception is explicitly recorded in the acquisition documentation. Acquisition cycles for defense systems routinely span the gate, so a programme in requirements definition now has to specify CNSA 2.0 in the requirement, not in a later engineering change. For suppliers, engineering decisions taken today determine eligibility in 2027.
Product validation. Products deployed in NSS require validation by the National Information Assurance Partnership (NIAP), which certifies products against Protection Profiles, the standardized security requirement documents for a product class. Updated Protection Profiles incorporating CNSA 2.0 algorithms are being released, and products not validated against them will not be eligible for new NSS deployment. Beneath that sits algorithm and module testing: the Cryptographic Algorithm Validation Program (CAVP) tests algorithm implementations, and the Cryptographic Module Validation Program (CMVP) validates the module as a whole. Verification-only implementations can be satisfied with CAVP testing. Anything that generates signatures or performs key encapsulation needs CMVP, and the CMVP queue is long enough that it belongs on the critical path rather than in a compliance backlog.
A separate deadline compounds this. CMVP moves FIPS 140-2 certificates to historical status in September 2026. A module that needs both FIPS 140-3 validation and CNSA 2.0 algorithm support faces two sequential processes.
Risk Management Framework integration. Approving Officials assess CNSA 2.0 compliance through the Risk Management Framework (RMF) when evaluating security control SC-12, cryptographic key establishment and management. The bar for NSS is not “FIPS-validated” but “NSA-approved”, which additionally requires NIAP validation and configuration in line with CNSSP 15. If your control narrative for SC-12 cites a FIPS certificate and stops there, it will not survive the assessment.
The absence of a catch-up path. An NSS that never reached CNSA 1.0 compliance is not permitted to remediate toward CNSA 1.0. Under the updated CNSSP 15 it goes directly to CNSA 2.0 on a compressed clock, with a waiver request required if it misses. Waivers are algorithm-specific, implementation-specific and use-case-specific, so each one carries its own justification, its own audit exposure and its own remediation plan. A waiver register that grows is a programme that is failing.
Where CNSA 2.0 narrows NIST
NIST standardized the algorithms and offered choice. NSA removed the choice. That is the whole relationship, and it explains most of the confusion we see in supplier conversations.
A supplier can be entirely accurate in saying “our product implements FIPS 203” and still be non-compliant, because FIPS 203 includes ML-KEM-512 and ML-KEM-768. The compliance question is which parameter set CNSA 2.0 names, not whether the product is FIPS-approved. Write the parameter level into procurement language, not just the algorithm name.
The narrowing also removes the diversity NIST built deliberately. NIST published SLH-DSA so that organizations could hold a non-lattice fallback. Inside CNSA 2.0 that option doesn’t exist, which places more weight on crypto-agility: the ability to change cryptographic algorithms without re-architecting the systems that use them. CNSA 2.0 reflects NSA’s current assessment, and assessments get revised. Building agility into the migration now is what makes a future revision a project rather than an emergency.
Why this reaches past National Security Systems
CNSA 2.0 formally binds NSS. In practice its reach is wider, for three reasons a GRC function can act on.
Supply chain flow-down is the direct route. If your networking equipment, operating system, HSM or application ends up inside an NSS, or inside a system that interoperates with one, the requirement arrives through your prime contractor’s contract terms. From 2027 onward, products that cannot demonstrate CNSA 2.0 support lose eligibility for that work, and the demonstration is a certificate, not a datasheet claim.
CNSA 2.0 is also becoming a convenient reference point for high-assurance procurement outside government, because it’s the only widely published document that names an algorithm and a parameter level in the same sentence. Buyers who don’t want to run their own cryptographic selection process cite it.
And allied convergence is under way. Australia’s Signals Directorate has converged on the same parameter levels in its own guidance, and interoperability with US NSS pushes allied programmes toward the same choices, even where European authorities diverge on questions like SLH-DSA.
Making it a governed control
The plan for any CNSA 2.0 programme needs a named owner and a review date, and most registers we see have neither. A schedule with no owner produces a scramble in late 2026.
Ownership splits cleanly. A single accountable owner holds the technical position, usually the security architecture lead or the cryptographic key custodian, because the decisions are about parameter sets, module validation and signing infrastructure. GRC holds the review, the evidence set and the waiver register. Naming a committee as owner is the failure mode: committees don’t renew CMVP certificates.
A workable control-register entry looks like this.
Control CRY-PQ-01. All cryptographic modules in scope for NSS delivery implement ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, per CNSA 2.0 and the current CNSSP 15, with firmware signing performed under SP 800-208 LMS or XMSS in an HSM.
Accountable owner. Named individual, security architecture. Review owner. Named individual, GRC.
Evidence. A cryptographic bill of materials (CBOM), meaning a machine-readable inventory of every algorithm, key and certificate a product or system depends on, covering all current RSA, ECDSA, ECDH and Diffie-Hellman use with a system owner against each entry. CMVP or CAVP certificate numbers naming the exact parameter sets. NIAP Protection Profile validation status per product. Contract flow-down language issued to sub-tier suppliers. Signing key ceremony records and the documented HSM state-management procedure. The waiver register, with an expiry date and a remediation plan on every entry.
Review cadence. Quarterly through the January 1, 2027 acquisition gate, then twice yearly to the 2030 exclusive-use dates for signing and networking. Trigger an out-of-cycle review on any CNSSP 15 revision, any new NIAP Protection Profile release affecting a product in scope, and the September 2026 FIPS 140-2 historical transition.
First review date. Set it before the next procurement decision, not at the next annual cycle.
If you are starting from nothing, the order that works is inventory first, then exposure, then signing. Find every classical key establishment and signature dependency. Determine whether any product, system or customer touches NSS. Then move firmware and software signing ahead of everything else, because validated LMS and XMSS implementations are available now and firmware is the component you cannot fix later. The PQC Migration Framework sets out a structured method for the inventory stage, and Marin Ivezic’s complete CNSA 2.0 guide on PostQuantum.com goes deeper into the cryptographic detail behind each choice.
Building the capability in-house
Reading the mandate is the easy part. Translating it into procurement language, supplier questionnaires, control narratives that survive an RMF assessment, and a migration plan sequenced against the category dates takes people who understand both the cryptography and the compliance machinery, and most organizations currently have one or the other.
Quantum Academy’s post-quantum governance and migration programs are built for exactly that gap: how to read algorithm mandates precisely, how to inventory cryptographic dependencies at enterprise scale, how to specify parameter levels in contracts, and how to evidence compliance to an assessor. You can review the current programs and access options at quantumacademy.com/. If you’re mapping the career path behind the role rather than the training itself, QuantumCareers.com covers where PQC governance work sits in the wider security profession.