CNSA 2.0 Transition: NSA Quantum-Resistant Algorithm Deadlines

CNSA 2.0 sets the quantum-resistant algorithms that US National Security Systems must use and the dates by which vendors and system owners must switch, with the first procurement gate on 1 January 2027. The Commercial National Security Algorithm Suite 2.0 was announced by the US National Security Agency (NSA) on 7 September 2022 and is enforced through CNSSP 15, the Committee on National Security Systems policy on commercial cryptography. This guide explains which algorithms and parameter sets are approved, how the deadlines work by equipment category, what the 2024 CNSSP 15 update changed, and how to plan the work, with particular attention to signing keys, certificates and other machine identities. It is for product security teams at vendors selling into National Security Systems, defence contractors, and security architects who use CNSA 2.0 as a benchmark outside government. For dates across all jurisdictions, see the Post-Quantum Cryptography Deadlines Tracker.

Key takeaways

• The suite is small and fixed. AES-256, ML-KEM-1024, ML-DSA-87, SHA-384 or SHA-512, and LMS or XMSS for firmware and software signing; no other parameter sets are approved for general use.
• 1 January 2027 is a procurement gate. NSA's FAQ (version 2.1, December 2024) states that CNSSP 15 requires new NSS acquisitions to be CNSA 2.0 compliant from that date unless otherwise noted.
• Signing comes first. Software and firmware signing was to support and prefer CNSA 2.0 from 2025 and use it exclusively by 2030, because a root of trust must be quantum-resistant before the rest of the system.
• Equipment that cannot transition must go by the end of 2030. The FAQ says equipment and services that cannot support CNSA 2.0 must be phased out by 31 December 2030, with CNSA 2.0 mandated by 31 December 2031 and all NSS quantum-resistant by 2035.
• Hybrid is optional, QKD is not a substitute. NSA will not require hybrid schemes for security, will keep a CNSA 1.0 layer in IKEv2, and does not generally consider quantum key distribution practical for NSS.

What it is and who it applies to

CNSA 2.0 replaces CNSA 1.0, which itself replaced Suite B, as the list of commercial algorithms approved to protect US National Security Systems (NSS) at all classification levels. NSS are defined in US law and include systems that handle classified information and some unclassified systems tied to intelligence, military command and control and weapons. The suite is published by NSA in a Cybersecurity Advisory and a companion FAQ; the binding policy is CNSSP 15, which applies to NSS owners and operators, and through procurement to the vendors that supply them.

• NSS owners and operators: must plan, fund and report the transition. The FAQ notes that NSM-10 reporting continues for many customers through 31 December 2031.
• Vendors: products sold for NSS use are evaluated against NIAP Protection Profiles (CNSSP 11 requires NIAP compliance for commercial IA products acquired for NSS). NSA says NIAP profiles will add quantum-resistant signatures in line with its timelines.
• Everyone else: CNSA 2.0 is not binding outside NSS, but it is the most specific published government timeline, so many regulated firms and critical infrastructure operators use it as a reference alongside NIST IR 8547.

Structure and key requirements

The algorithms

The FAQ adds several rules that trip up product teams: only single-tree LMS and XMSS are approved (HSS and XMSS^MT are not); SLH-DSA is not approved for any NSS use; SHA-3 and SHAKE are not approved as general-purpose hashes; and smaller ML-KEM and ML-DSA parameter sets, while standardised by NIST, do not meet CNSA 2.0. See the ML-KEM Guide and the ML-DSA and SLH-DSA Post-Quantum Signatures Guide.

The timeline

NSA's timeline uses two milestones per category: "support and prefer" (products offer CNSA 2.0 and choose it by default when the peer supports it) and "exclusively use" (products accept only CNSA 2.0). The category dates below are from NSA's CNSA 2.0 FAQ version 2.0 (April 2024); version 2.1 (December 2024) summarises equipment transition as falling between 2025 and 2030 and adds the CNSSP 15 dates in the second table.

Dates were checked against NSA's FAQ on 8 November 2026. NSA may issue profile-specific exceptions ("unless otherwise noted"), so confirm against the current FAQ and NIAP profiles before committing a roadmap.

Protocols, hybrids and QKD

• Hybrid: NSA has confidence in CNSA 2.0 alone and will not require hybrids for security, but accepts them for availability or interoperability. Non-standardised hybrid or quantum-resistant schemes should not be used on NSS mission systems except where NSA recommends them.
• IKEv2: because ML-KEM-1024 keys are too large to drop into the initial IKEv2 exchange, NSA expects an IETF approach with a smaller initial exchange followed by a larger encrypted one, and its profile keeps CNSA 1.0 key establishment fortified with ML-KEM-1024. See the Post-Quantum Readiness for VPNs and IKEv2 Guide.
• TLS, SSH, S/MIME: NSA says it is working with the IETF on protocol specifications; follow NIAP and NSA profiles as they publish. See the Hybrid Post-Quantum TLS Key Exchange Guide.
• QKD: NSA does not generally consider quantum key distribution a practical security solution for NSS, and owners should consult NSA before using or researching it. See QKD vs Post-Quantum Cryptography.

Identity and NHI requirements

Most of the CNSA 2.0 work lands on machine identities: the keys and certificates that devices, services and build systems use to prove who they are.

• Code and firmware signing keys: the FAQ requires NSS code signers to sign with CMVP-validated hardware, with no waivers for unvalidated signing hardware. LMS and XMSS are stateful, so signing and state management should be done in hardware such as an HSM, and backups must never allow a one-time key to be reused. Verification needs only CAVP-validated implementations. See the Code Signing Security Guide.
• Roots of trust: NSA notes firmware roots of trust may need a quantum-resistant algorithm years before the rest of the system, because a device's boot verification key is often burned in at manufacture. Devices shipped after 2027 with only classical boot keys will need replacing to meet the 2030 phase-out.
• Device and service certificates: ML-DSA-87 certificates and signatures are much larger than ECDSA P-384, which affects certificate chains, constrained devices and protocols with size limits. Large PKI systems are a "niche equipment" category with a 2033 exclusive date.
• Service account and workload credentials: mutual TLS, SSH host and user keys and signed tokens used by non-human identities all inherit the protocol timelines above. Inventory them with owners so they can be reissued. See the Post-Quantum Migration for NHIs Guide.

Implementation steps

1. Confirm scope: list which systems are NSS or are sold for NSS use, and which customers will apply CNSSP 15 through contracts.
2. Build a cryptographic inventory: algorithms, key sizes, protocols, certificates, signing keys and the libraries and HSMs behind them, with an owner per item. See the Cryptographic Inventory and CBOM Guide.
3. Move signing first: stand up an LMS or XMSS signing service on CMVP-validated hardware, decide tree heights from expected signing volume, and design state backup that cannot reuse a leaf. Add quantum-resistant boot verification to hardware designs now.
4. Pick libraries and modules with validation plans: require FIPS 203 and FIPS 204 implementations with CAVP certificates, and CMVP modules where NSA requires them.
5. Enable "support and prefer": ship CNSA 2.0 suites alongside CNSA 1.0, configured to prefer CNSA 2.0, and test interoperability with customers in a pilot ring. Keep the classical suite enabled as the rollback path during this phase.
6. Plan "exclusively use": set the dates per category, remove CNSA 1.0 suites in test first, monitor handshake failures, then roll out.
7. Replace what cannot move: flag hardware without CNSA 2.0 capability for replacement before 31 December 2030.

Choosing a signing approach

Our recommendation: use LMS for anything verified by immutable boot code, and ML-DSA-87 for high-volume or online signing where state management would be a risk.

Small vendors versus large: a small vendor with one product line can often move straight to a single CNSA 2.0 profile and rely on a validated third-party library; a large vendor with long-lived hardware should prioritise boot keys and signing infrastructure, because those decide whether fielded products can be updated at all. Build crypto-agility into new designs so future changes are configuration rather than redesign.

Evidence and assessment

Metrics: percentage of inventoried cryptographic assets with a CNSA 2.0 target date; percentage of signed releases signed with LMS, XMSS or ML-DSA-87; number of products with CNSA 2.0 suites shipped and preferred; hardware models without a quantum-resistant boot path; count of active waivers.

Mapping to other frameworks

Common pitfalls

• Choosing smaller parameter sets: ML-KEM-768 and ML-DSA-65 are NIST-standardised parameter sets but do not meet CNSA 2.0.
• Using SLH-DSA or HSS for firmware: NSA approves only single-tree LMS and XMSS for NSS.
• Software-only stateful signing: state loss or a restored backup can reuse a one-time key; NSA expects hardware signing with CMVP validation.
• Treating 2033 as the deadline: the 2027 acquisition gate and the 2030 phase-out arrive first for most products.
• Waiting for every protocol RFC: signing, inventory and hardware boot paths do not depend on TLS or SSH specifications and can start now.
• No owner for machine keys: certificates and signing keys without owners cannot be reissued on schedule.

Practitioner checklist

• Scope which products and systems fall under CNSSP 15 directly or by contract.
• Build and maintain a cryptographic inventory with owners, including signing keys and certificates.
• Stand up LMS or XMSS signing on CMVP-validated hardware with leaf-reuse-proof state handling.
• Require ML-KEM-1024, ML-DSA-87, AES-256 and SHA-384 or SHA-512 in new designs.
• Ship CNSA 2.0 suites as preferred before 1 January 2027 for products sold into NSS.
• Set exclusive-use dates per category and test classical suite removal in a pilot ring.
• List hardware that cannot transition and fund replacement before 31 December 2030.
• Track NIAP Protection Profile updates and NSA FAQ revisions every quarter.

Standards and references

• NSA: The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ
• NSA: NSA Releases Future Quantum-Resistant Algorithm Requirements for National Security Systems
• NIST: FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST: FIPS 204 Module-Lattice-Based Digital Signature Standard
• NIST: SP 800-208 Recommendation for Stateful Hash-Based Signature Schemes
• NIST: IR 8547 Transition to Post-Quantum Cryptography Standards

Related NHI Mgmt Group resources: Post-Quantum Cryptography Deadlines Tracker · Post-Quantum Cryptography Migration Guide · Code Signing Security Guide · Post-Quantum Migration for NHIs Guide