up:: The Mandates MOC
NSA CNSA 2.0
CNSA 2.0 is the National Security Agency’s advisory that names the post-quantum algorithms U.S. National Security Systems (NSS) must use, and the years by which they must use them. Issued in September 2022 as “Announcing the Commercial National Security Algorithm Suite 2.0,” it replaces the older CNSA 1.0 list of classical algorithms (RSA, ECDH, ECDSA) with a quantum-resistant suite built around FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA), and it puts a completion date of 2035 on the whole transition. For anyone who owns, operates, or sells into a national-security system, CNSA 2.0 is the document that turns “post-quantum, someday” into “this algorithm, by this year.”
The short version:
- CNSA 2.0 is a mandate, not a recommendation. It lists the algorithms NSS are required to run and the deadlines to run them by, and NSS are judged on being NSA-approved, which is a stricter bar than “FIPS-validated.”
- The required suite is ML-KEM at Level V (ML-KEM-1024) for key establishment, ML-DSA at Level V (ML-DSA-87) for signatures, AES-256, SHA-384 or SHA-512, and the stateful hash-based schemes LMS and XMSS for signing firmware and software.
- Deadlines are staged by system type. Software and firmware signing and traditional networking gear go exclusive first (by 2030); web, cloud, and operating systems by 2033; the full transition is meant to be complete by 2035.
- CNSA 2.0 shipped in 2022, before NIST finalized its standards, so it names the algorithms by their competition names (CRYSTALS-Kyber, CRYSTALS-Dilithium). Those are now ML-KEM and ML-DSA.
- The deadlines reach past government. They land on vendors through procurement, so a company that sells into national-security buyers inherits them whether or not it runs an NSS itself.
Think of CNSA 1.0 as the list of locks the government agreed to accept on its most sensitive doors: RSA and elliptic-curve at specific strengths. A large enough quantum computer picks those locks. CNSA 2.0 is the replacement list, the locks the government will accept in a world where that machine exists, along with a schedule for the year each kind of door has to be re-fitted. The harvest-now-decrypt-later problem is why the schedule starts before the machine is here: traffic captured today can be opened later, so the doors have to change ahead of the threat.
Who does CNSA 2.0 apply to?
CNSA 2.0 governs all public-key cryptography on National Security Systems, both unclassified and classified, and it reaches the people who build for them:
- NSS owners, operators, and vendors. Everyone running or supplying cryptography on an NSS.
- Cryptographic service providers. Software and hardware that provides cryptographic services needs NIAP or NSA validation under CNSSP 11, on top of using the right algorithms.
- DoD and the Defense Industrial Base. Covered through the NSA’s cybersecurity mission authorities.
The default rule is strict: an algorithm the National Manager has not approved generally cannot be used, and using one requires a waiver specific to the algorithm, the implementation, and the use case.
Source: NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” CSA U/OO/194427-22 | PP-22-1338, September 2022.
What algorithms does CNSA 2.0 require?
CNSA 2.0 specifies one approved algorithm per cryptographic job, and it requires the strongest parameter set at every classification level. There is no “good enough for unclassified” tier here: Level V across the board.
| Function | Required algorithm | Parameters |
|---|---|---|
| Key establishment | CRYSTALS-Kyber, now ML-KEM | Level V (ML-KEM-1024), all classification levels |
| Digital signatures | CRYSTALS-Dilithium, now ML-DSA | Level V (ML-DSA-87), all classification levels |
| Symmetric encryption | AES-256 (FIPS 197) | 256-bit keys, all classification levels |
| Hashing | SHA-384 or SHA-512 (FIPS 180-4) | All classification levels |
| Firmware and software signing | LMS (NIST SP 800-208) | All parameters approved; SHA-256/192 recommended |
| Firmware and software signing | XMSS (NIST SP 800-208) | All parameters approved |
Source: NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” CSA U/OO/194427-22 | PP-22-1338, September 2022.
The two hash-based signature schemes, LMS and XMSS, carry a requirement that trips up a lot of implementations: to stay secure they must meet every part of NIST SP 800-208, including managing signing state and performing the signing in hardware. A software-only LMS implementation is not compliant.
What is the CNSA 2.0 timeline?
CNSA 2.0 sets 2035 as the outer date for the NSS transition to be complete, in line with the National Security Memorandum on quantum (NSM-10). Underneath that horizon it runs two schedules: a per-use-case adoption schedule, and a set of acquisition and compliance milestones. Both come from the advisory and its FAQ.
The per-use-case schedule tells each kind of system when to start preferring CNSA 2.0 and when to use it exclusively:
| System type | Support and prefer CNSA 2.0 | Exclusively use CNSA 2.0 |
|---|---|---|
| Software and firmware signing | by 2025 (begin immediately) | by 2030 |
| Web browsers, servers, and cloud services | by 2025 | by 2033 |
| Traditional networking equipment (VPNs, routers) | by 2026 | by 2030 |
| Operating systems | by 2027 | by 2033 |
| Niche equipment (constrained devices, large PKI) | by 2030 | by 2033 |
| Custom applications and legacy equipment | update or replace by 2033 | (covered by the 2033 update) |
The acquisition-and-compliance ladder is the procurement side, and it arrives sooner than most people expect:
| Milestone | Date | What it requires |
|---|---|---|
| New acquisitions | Jan 1, 2027 | CNSA 2.0 required in all new NSS products and services, unless a CSfC Capability Package, a NIAP Protection Profile, or a waiver says otherwise |
| Replace non-supporting equipment | Dec 31, 2030 | Equipment that cannot support CNSA 2.0 is replaced; CNSA 2.0 becomes the preferred configuration |
| Mandated for use | Dec 31, 2031 | CNSA 2.0 mandated for all NSS, again subject to a CSfC CP, NIAP PP, or waiver; by this point the vast majority of NSS cryptography should be quantum-resistant |
Source: NSA, “CNSA 2.0 FAQ” (PP-24-4014, December 2024 update).
One clause closes an obvious escape route. Even where a hybrid deployment (a classical algorithm run alongside a post-quantum one) is allowed or required for interoperability, CNSA 2.0 becomes mandatory to select at the stated date, and choosing a CNSA 1.0 algorithm on its own stops being approved. Hybrid keeps you interoperable; it does not buy you more time.
How does CNSA 2.0 relate to the NIST standards?
CNSA 2.0 and the NIST FIPS standards are two layers of the same transition. NIST publishes the algorithms as open standards for everyone; CNSA 2.0 selects from them and makes specific choices binding on national-security systems. The advisory predates the August 2024 FIPS finalization, which is why it still uses the competition names.
- CRYSTALS-Kyber in CNSA 2.0 is ML-KEM, finalized in FIPS 203.
- CRYSTALS-Dilithium in CNSA 2.0 is ML-DSA, finalized in FIPS 204.
The sharpest difference is the parameter choice. For general use, NIST recommends ML-KEM-768 as a sensible default. CNSA 2.0 requires Level V, the top parameter set (ML-KEM-1024 and ML-DSA-87), at every classification level. National-security systems are told to run the strongest option everywhere, where a commercial deployment is free to pick the lighter default. If your baseline is the NIST recommendation, CNSA 2.0 is a deliberate step above it.
CNSA 2.0 is also the national-security-systems half of U.S. post-quantum policy. It is the counterpart to the civilian-side federal mandates (OMB M-26-15, Executive Order 14306) that cover everything else: NSS sit outside the civilian memos and are governed here instead.
Why does CNSA 2.0 matter if you are not a national-security system?
The deadlines do not stay inside government. A mandate on NSS becomes a requirement on the vendors who sell to NSS, and that requirement moves down the supply chain through procurement and contracts. The Jan 1, 2027 acquisition gate is the clearest example: from that date, new NSS products and services have to support CNSA 2.0, so any company that wants to keep selling into that market has to ship post-quantum support well before then, and its own suppliers inherit the same clock. Even outside the defense market, CNSA 2.0 is the most aggressive published post-quantum timeline in the U.S. federal stack, which makes it a useful forward indicator of where regulated-industry expectations are heading.
Common misconceptions
- “FIPS-validated is enough.” For NSS it is not. Solutions must be NSA-approved, which means NIAP validation against an approved protection profile under CNSSP 11 and correct configuration under CNSSP 15. FIPS validation is necessary, not sufficient.
- “Hybrid extends the deadline.” It does not. At each mandatory date, selecting a CNSA 1.0 algorithm alone stops being approved, hybrid or not.
- “CNSA 1.0 is retired, so ignore it.” CNSA 1.0 compliance is still required during the transition. Swapping in CNSA 2.0 algorithms before NIAP profiles permit creates assessment gaps rather than closing them.
- “There is one 2035 deadline.” The per-use-case dates are earlier and they differ. Networking equipment has a 2030 exclusive-use date, five years ahead of the 2035 horizon, and the 2027 acquisition gate is earlier still.
- “LMS is a drop-in signing swap.” LMS and XMSS only stay secure if you meet all of NIST SP 800-208, including state management and signing in hardware. A software-only implementation is out of compliance.
What should you take from CNSA 2.0?
If you run or supply national-security systems, CNSA 2.0 is the accountable schedule: Level V everywhere, NSA-approved rather than FIPS-validated, and a 2027 acquisition gate that lands sooner than the 2035 headline suggests. If you do not, it is still worth reading as the leading edge of U.S. post-quantum policy and as the timeline your government-facing vendors are already migrating against. Either way, the practical move is the same one the whole transition rewards: build the ability to swap cryptographic algorithms cleanly, so meeting a dated mandate becomes a configuration change instead of a re-engineering project. That capacity is crypto-agility, and CNSA 2.0 is a concrete reason to have it.
Everything here is the map, given freely. When your team needs CNSA 2.0 turned into a dated migration plan for your own systems and vendors, that’s what an alignment briefing is for.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.