CNSA 2.0 — the Commercial National Security Algorithm Suite 2.0 — is the NSA's mandated set of post-quantum algorithms for US national-security systems (NSS) and the vendors that build for them. Announced in September 2022 with the FAQ updated in 2024, it names the specific parameter sets NSS must adopt: ML-KEM-1024 for key establishment, ML-DSA-87 for general-purpose signatures, the SP 800-208 stateful hash-based schemes LMS and XMSS for software and firmware signing only, AES-256 for symmetric encryption, and SHA-384 or SHA-512 for hashing.
Why it matters
CNSA 2.0 is a mandate, not a menu. If you sell into the national-security space — defense, intelligence, or the systems that support them — it defines the exact algorithms and sizes your products must ship, and a fixed schedule for when classical cryptography stops being acceptable. It is also the most concrete signal of where the wider market is heading: the NSA's parameter choices are the high end of the FIPS families, so building to CNSA 2.0 is a defensible way to future-proof commercial products even where it is not strictly required.
Algorithm selections and the transition timeline
Two selections deserve emphasis. For general-purpose signatures CNSA 2.0 chooses ML-DSA-87 — the lattice scheme — not SLH-DSA; the stateful hash-based signatures are restricted to signing software and firmware, where a small, controlled number of signatures fits their state-management constraints. The transition runs in staggered waves toward a single deadline of exclusive CNSA 2.0 use by 2033:
- Software and firmware signing: support beginning 2025, exclusive CNSA 2.0 by 2030 — the earliest wave.
- Web browsers, servers, and cloud services: exclusive CNSA 2.0 by 2033.
- Operating systems: adoption from around 2027, exclusive by 2033.
- Niche and general-purpose networking equipment: exclusive CNSA 2.0 by 2033.
CNSA 2.0 does not require hybrid key establishment
Unlike common commercial and IETF practice — where hybrid TLS pairs a post-quantum KEM with a classical curve — the NSA prefers validated, standalone post-quantum algorithms for NSS and does not mandate hybrids. That guidance is specific to national-security systems. Commercial deployments generally still choose hybrids to hedge against an unforeseen weakness in a young algorithm while defending against harvest-now-decrypt-later. Know which regime you are building for before you fix the design.
How quantakrypto helps
The 2033 deadline is deceptive: multi-year hardware refresh cycles, firmware-signing pipelines, and dependency chains mean the planning has to start now, and the earliest signing waves are effectively here. We inventory where non-CNSA cryptography lives across your products and rank the exposure (audit), sequence the move to ML-KEM-1024 and ML-DSA-87 against the wave that governs each system type (migration), and conformance-test the implementations you ship so the algorithm and parameter set you claim is the one you actually run (certification). Where teams need to get fluent in the suite and its deadlines fast, we train them directly (training), and we map each system to the federal timeline.
Frequently asked questions
Does CNSA 2.0 apply to my commercial product?
Directly, only if you build national-security systems or sell components into them — CNSA 2.0 binds NSS and their vendors, not general commercial IT. That said, its parameter choices (ML-KEM-1024, ML-DSA-87, AES-256) represent the strong end of the NIST families, so many commercial teams adopt it as a future-proof baseline even where no mandate applies.
Why does CNSA 2.0 not require hybrid key exchange?
The NSA prefers validated, standalone post-quantum algorithms for national-security systems and does not mandate pairing them with a classical algorithm. This is the opposite of common commercial and IETF practice, where hybrids hedge against a weakness in a young post-quantum scheme. The no-hybrid stance is specific to NSS; commercial deployments generally still choose hybrids.
Why ML-DSA-87 for signatures instead of SLH-DSA?
CNSA 2.0 selects ML-DSA-87, the lattice-based scheme, for general-purpose signatures. The stateful hash-based signatures LMS and XMSS (SP 800-208) are permitted only for signing software and firmware, where the number of signatures is small and state can be managed carefully — they are not a general-purpose signature choice under this suite.
When must systems be fully migrated to CNSA 2.0?
The overall goal is exclusive CNSA 2.0 use by 2033. The waves are staggered: software and firmware signing is exclusive by 2030, while web browsers and servers, cloud services, operating systems, and networking equipment reach exclusive use by 2033. Given multi-year procurement and refresh cycles, planning needs to begin well before those dates.
Work with us on CNSA 2.0
Related reading
References
- NSA: Announcing the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) — FAQ (the algorithm selections and transition timeline).
- NSA: Commercial National Security Algorithm Suite 2.0 program page.
- Wikipedia: Commercial National Security Algorithm Suite.