CNSA 2.0 timeline: algorithms and deadlines explained

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the set of post-quantum algorithms the NSA requires for US National Security Systems (NSS) and for the commercial products used in them. The suite is ML-KEM-1024 for key establishment, ML-DSA-87 for general signatures, LMS and XMSS for software and firmware signing, AES-256 for symmetric encryption, and SHA-384 or SHA-512 for hashing. Exclusive use is required by the end of 2030 for software and firmware signing and for traditional networking equipment, and by the end of 2033 for web browsers and servers, cloud services, operating systems and niche equipment.

Who CNSA 2.0 applies to

CNSA 2.0 is not a general United States cryptography rule and it is not an international standard. It governs National Security Systems: the systems that handle classified information or that are critical to military and intelligence functions. It reaches three groups of people. First, the organizations that own and operate those systems. Second, the integrators who build them. Third, and this is the group most often surprised, the commercial vendors whose products are procured for them.

Federal civilian agencies follow a different track. Their obligations come from Executive Order 14412 (2026-06-22) and OMB memorandum M-26-15 (2026-06-24), summarized on our US federal post-quantum page: automated cryptographic inventory, agency migration plans due 2026-10-22, TLS 1.3 required by 2030-01-02, high-value systems on post-quantum key establishment by the end of 2030 and on post-quantum signatures by the end of 2031, full migration by 2035 under NSM-10. The two tracks point the same way, but the dates and the scope differ. Read the one that applies to the contract in front of you. The dated milestones for CNSA 2.0 itself are collected on our CNSA 2.0 reference page.

This article is information, not legal advice. Procurement language in a specific contract always takes precedence over a general summary.

The algorithm suite

CNSA 2.0 does not merely say post-quantum. It names parameter sets, and it names the highest ones.

Three points deserve attention. ML-KEM is the standardized form of CRYSTALS-Kyber, published by NIST as FIPS 203 on 2024-08-13 alongside FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). Pre-standard Kyber groups such as X25519Kyber768Draft00 are obsolete and do not satisfy anything. Next, CNSA 2.0 asks for the top parameter sets, ML-KEM-1024 and ML-DSA-87, not the ML-KEM-768 that browsers negotiate by default today. A product that supports only X25519MLKEM768 is post-quantum, but it is not CNSA 2.0. Finally, the suite points to LMS and XMSS, defined in SP 800-208, for signing software and firmware. These are stateful: the signing key must never reuse a one-time key index, so the signing infrastructure has to guarantee state persistence. SLH-DSA (FIPS 205) is stateless and does not appear in the suite described above.

AES-256 and the SHA-2 family are in the suite because they are not broken by Shor's algorithm. Grover's algorithm is the reason AES-256 is preferred over AES-128 for long-term protection, and the reason the hash sizes are 384 bits and above.

The deadlines, category by category

CNSA 2.0 sets dates for exclusive use, which is stricter than support. Exclusive use means the CNSA 2.0 algorithms are the only ones in play for that function: RSA, ECDSA and ECDH are gone, not merely deprioritized. Support must therefore land well before the deadline, because the fleet has to be fully converted by it.

These dates come from the CNSA 2.0 FAQ version 2.1 (December 2024) and the CNSA 2.0 Algorithms advisory of 2025-05-30. The ordering is deliberate. Signing comes first because a signing root has a long life: firmware signed today with an ECDSA key may still be verified by devices in the field a decade from now, and reissuing a trust anchor across a deployed fleet is slow. Networking equipment comes first because it terminates the long-lived encrypted tunnels that are the most attractive target for harvest now, decrypt later: recorded traffic is protected only by the key exchange that produced its session keys, so capture today can become plaintext later. Browsers, servers, cloud platforms and operating systems get until 2033 because the dependency chain below them (libraries, hardware security modules, certificate authorities, protocol stacks) is deeper.

Why suppliers outside the United States care

Three reasons, none of them theoretical.

• Procurement language travels. CNSA 2.0 requirements are written into contracts and into requests for proposal. A component supplier two or three tiers down a defence supply chain inherits them through its customer, not through its own regulator.
• The high parameter sets are a product decision, not a configuration flag. ML-KEM-1024 and ML-DSA-87 change key and signature sizes, handshake sizes, firmware image sizes and hardware security module requirements. A roadmap that stops at ML-KEM-768 will need a second pass.
• European requirements are not identical. ANSSI makes hybridation mandatory inside its regulated scope (product qualification, defence related procedures, operators of vital importance) and states that its other post-quantum recommendations are not yet regulatory obligations. BSI TR-02102-1 (version 2026-01) is a technical guideline that recommends hybrid post-quantum key agreement and considers classical key agreement used alone acceptable only until the end of 2031, or the end of 2030 for very high protection needs. A product sold into both markets has to be able to negotiate a hybrid group and a CNSA 2.0 parameter set, which is an argument for crypto-agility in the code rather than a single hardcoded choice.

If you need to see every official deadline side by side, our overview of post-quantum migration deadlines lines up CNSA 2.0 against the EU roadmap, the UK NCSC dates and the US federal track.

What to check this quarter

Start read-only, in staging, and keep a classical fallback until the deadline that applies to you is close.

Confirm which groups your TLS stack can actually offer. ML-KEM groups require OpenSSL 3.5 or later:

openssl version
openssl list -tls-groups

Look for MLKEM1024 and SecP384r1MLKEM1024 as well as the widely deployed X25519MLKEM768. The IANA codepoints are published in the TLS parameters registry, and the hybrid mechanism itself is specified in RFC 10024 (August 2026).

Then test what a server will negotiate, one group at a time, against a staging host:

openssl s_client -connect staging.example.com:443 -groups MLKEM1024 </dev/null 2>&1 | grep -i -E "negotiated|group"
openssl s_client -connect staging.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i -E "negotiated|group"

For the signing side, generate a test ML-DSA-87 key pair and measure what the larger signatures do to your artifact sizes, your update channel and your verification code paths:

openssl genpkey -algorithm ML-DSA-87 -out mldsa87-test.key

Keep the test key out of any production trust store. The harder work is organizational: inventory every signing root and its expiry, identify the hardware security modules that must support ML-DSA-87 or stateful hash-based signing, and plan the state management that LMS and XMSS demand. Our walkthrough on how to migrate code signing to ML-DSA covers the sequencing, including dual signing during the transition.

Next step: measure what you present today

CNSA 2.0 deadlines are about what your products and services actually negotiate, not what your roadmap promises. Begin with the externally visible layer: scan your domain with PQC Status to see which key exchange groups, TLS versions and certificate algorithms your endpoints offer right now. Use the result as the first line of a gap list: endpoints with no ML-KEM group at all, endpoints that offer only ML-KEM-768 where a CNSA 2.0 contract will need ML-KEM-1024, and certificate chains still signed with RSA or ECDSA. A scan describes an externally visible TLS configuration. It is not a certification and not a compliance attestation, so pair it with your internal inventory of signing keys, firmware images and embedded libraries.