CNSA Suite 2.0 (CNSA 2.0): The Practical Guide (2026)

Last updated: October 13, 2026 | Affiliate Disclosure

Direct visitor? This domain is available for acquisition. CNSA2.com

CNSA Suite 2.0 is one of the clearest “this is really happening” signals in post‑quantum cryptography. It’s not a think piece or a vendor roadmap – it’s a set of concrete algorithm requirements and transition dates aimed at National Security Systems (NSS), with obvious spillover into the defense industrial base and anyone who needs to interoperate with those systems.

This guide is deliberately practical: what CNSA 2.0 is, what it requires (and forbids), the timeline, and what to do next if you build or operate systems that will be pulled into this transition.

What is CNSA Suite 2.0?

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the NSA’s suite of quantum‑resistant algorithms approved for NSS use.

It’s written primarily for:

  • NSS owners and operators (people accountable for real systems), and
  • vendors who need to implement what NSS will require.

NSA is explicit that it’s not trying to dictate cryptography for everyone else – but also acknowledges that interoperability and procurement pressure will make CNSA 2.0 relevant well beyond NSS.

Primary source: NSA, CNSA Suite 2.0 and Quantum Computing FAQ, December 2024, Version 2.1
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

If you’re reading CNSA 2.0 because you have to execute a real migration, these companion guides help:

The “why” in one paragraph

NSA’s position is straightforward:

  • A cryptanalytically relevant quantum computer (CRQC) would break widely deployed public‑key cryptography (RSA and ECC) used for key exchange and digital signatures.
  • You can’t “fix” that by just using bigger RSA keys or bigger curves.
  • So NSS needs a transition plan now, with a target of quantum resistance by 2035 (per NSM‑10), and concrete earlier milestones to keep the migration from slipping forever.

That urgency is what makes CNSA 2.0 operationally important: it forces organizations to confront crypto migration as an engineering program, not an abstract risk.

What algorithms are in CNSA 2.0? (and what that actually means)

The NSA FAQ includes a table of the CNSA 2.0 algorithms and parameters. Here’s the practical summary.

General purpose algorithms (core suite)

  • AES (FIPS 197): use 256‑bit keys for all classification levels.
  • ML‑KEM (FIPS 203): use ML‑KEM‑1024 for key establishment at all classification levels.
  • ML‑DSA (FIPS 204): use ML‑DSA‑87 for digital signatures at all classification levels (including firmware/software signing use cases).
  • SHA‑2 (FIPS 180‑4): use SHA‑384 or SHA‑512 for all classification levels.

Algorithms allowed only in specific applications (not general purpose)

  • LMS (NIST SP 800‑208): allowed for digitally signing firmware/software; NSA recommends LMS SHA‑256/192 as a preferred parameter set.
  • XMSS (NIST SP 800‑208): allowed for digitally signing firmware/software.
  • SHA‑3 (FIPS 202): SHA3‑384 or SHA3‑512 allowed only for internal hardware functionality (example: boot-up integrity checks). NSA explicitly says SHA‑3 is not approved as a general-purpose hash in CNSA 2.0.

All of the above comes directly from the NSA FAQ’s algorithm table and follow‑on clarifications.

What CNSA 2.0 explicitly does not allow (important details people miss)

This is where a lot of “PQC summary” blog posts get sloppy. CNSA 2.0 has some sharp edges.

RSA and ECC can’t be “saved” with larger sizes

NSA is direct: you cannot address the quantum threat by using larger RSA or ECC.

SLH‑DSA (SPHINCS+) is not part of CNSA 2.0

Even though NIST standardized SLH‑DSA (FIPS 205), NSA says it is not part of CNSA and not approved for any use in NSS.

This matters because many people assume “NIST standardized it” automatically implies “NSA will allow it in CNSA.” Not here.

HSS and XMSSMT are not allowed (only LMS and XMSS)

NIST SP 800‑208 includes HSS and XMSSMT, but NSA approves only LMS and XMSS for NSS use.

HashML‑DSA (pre-hash mode) is not allowed (for now)

The NSA FAQ says HashML‑DSA is not allowed at present time, mainly on interoperability/need grounds, and NSA would provide limited guidance if a future protocol required it.

SHA‑3 / SHAKE are not general-purpose hashes in CNSA 2.0

NSA allows SHA3‑384/512 only in narrow internal hardware scenarios and when used inside an approved algorithm specification (e.g., allowed within LMS parameter sets as defined), but not as a general-purpose selection.

If you’re a vendor, these “not allowed” bullets are not trivia – they’re the difference between “we support PQC” and “we meet CNSA requirements.”

The CNSA 2.0 timeline (the dates people plan around)

The NSA FAQ provides concrete transition milestones via CNSSP 15 updates and NSS expectations. Key dates called out:

  • No enforcement prior to December 31, 2025 (for systems currently validated against NIAP or CSfC profiles; approval continues for the life of that validation). Any NSS not CNSA 1.0 compliant has six months from publication of the updated CNSSP 15 to come into compliance with CNSA 2.0, or 90 days to request a waiver.
  • January 1, 2027: all new acquisitions for NSS must be CNSA 2.0 compliant unless otherwise noted.
  • December 31, 2030: equipment/services that cannot support CNSA 2.0 must be phased out unless otherwise noted.
  • December 31, 2031: CNSA 2.0 algorithms are mandated for use unless otherwise noted.
  • 2035 goal: NSA intends all NSS to be quantum-resistant by 2035 (aligned to NSM‑10).

Primary source (timeline section): NSA FAQ v2.1
https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF

Why firmware/software signing is treated as urgent

CNSA 2.0 is not just about network protocols. NSA highlights that firmware roots of trust can be locked in for the lifetime of a system, and validation mechanisms are sometimes hard to update later.

That’s why NSA pushes hash-based signatures (LMS/XMSS) as a practical option that is commercially available and already standardized in SP 800‑208, even before ML‑DSA validation is widely available in every ecosystem.

If you build devices or embedded systems, this is the part to take personally: it’s much harder to retrofit cryptographic agility into a firmware validation path than into a cloud service.

What “hybrid” means in CNSA 2.0 (and why NSA is cautious)

CNSA 2.0 defines hybrid solutions as using multiple algorithms for the same function (e.g., key establishment) such that an attacker must break each component.

NSA’s position:

  • NSA has confidence in CNSA 2.0 algorithms and does not require hybrids for security.
  • Hybrids may still appear because of availability and interoperability constraints.
  • Hybrids add complexity and can increase the chance of implementation/configuration mistakes.
  • NSA specifically notes an example pressure point around IKEv2 message size constraints, where a straightforward “drop in ML‑KEM‑1024” isn’t feasible and the expected path involves an IETF-standardized approach that effectively combines smaller and then larger (encrypted) key establishments.

The practical message: if your plan is “we’ll just do hybrid everywhere,” CNSA 2.0 is a warning label. Hybrid might be necessary in some places, but it’s not a free lunch.

Who should care (even if you’re not NSS)

Even if you never touch classified systems, you should pay attention if you are:

  • a vendor selling into DoD / DIB / federal supply chains
  • a provider of VPNs, networking gear, browsers, operating systems, cloud services, or identity infrastructure used by those customers
  • an organization that expects long-lived confidentiality or long-lived signature validity (archives, code signing, firmware, long support cycles)

CNSA 2.0 tends to become “the compliance language procurement uses,” and once a buyer asks for it, your roadmap becomes their roadmap.

What to do next (operators vs vendors)

If you operate systems (owners/operators)

  1. Inventory where quantum‑vulnerable crypto exists
    • Where are RSA/ECC used for key establishment or signatures?
    • Where are signatures used that must remain verifiable for a long time (software, firmware, documents)?
  2. Identify “hard to change” crypto surfaces
    • firmware roots of trust
    • vendor appliances with long patch cycles
    • devices with limited CPU/memory headroom
  3. Plan for a long coexistence period
    NSA explicitly expects a long period with both CNSA 1.0 and CNSA 2.0 in different places. That’s normal; plan for it.
  4. Treat crypto agility as a requirement, not a nice-to-have
    NSA says cryptographic agility is necessary to accomplish the transition in time. That’s a hint about what will be rewarded in procurement and what will fail audits later.

If you build products (vendors)

  1. Implement the right parameter sets
    “We support ML‑KEM” isn’t enough if you only support ML‑KEM‑768, for example. CNSA 2.0 specifies ML‑KEM‑1024 and ML‑DSA‑87.
  2. Don’t ship “almost compliant” variants
    NSA is explicit that only ML‑KEM and ML‑DSA that adhere to FIPS 203/204 are CNSA 2.0 compliant (not older CRYSTALS variants).
  3. Be careful with hashes
    SHA‑384/SHA‑512 are the general-purpose hashes. SHA‑3 is narrowly allowed for internal hardware integrity functions and within specific algorithm specs, not “choose SHA‑3 everywhere.”
  4. Have a validation story
    The FAQ talks about CAVP expectations for verification code and CMVP expectations for signing modules in NSS contexts, and it makes clear waivers are not a “get out of validation free” card for signing.

Vendor shortlist

This shortlist is intentionally small. It’s here to map the CNSA 2.0 transition to the vendor categories where work and budget typically land.

Disclosure: Some outbound links may be affiliate or referral links. This does not change which tools are included.

Certificate lifecycle management (CLM)

Best for: large-scale certificate inventory, renewal/rotation automation, and policy enforcement across teams.

HSMs (hardware-backed signing and key protection)

Best for: high-assurance key custody (roots/intermediates, code signing, firmware signing) and regulated environments.

Crypto discovery / inventory (visibility into where crypto is used)

Best for: building an actionable crypto inventory (certs, TLS posture, algorithm exposure) to drive migration planning.

Cloud KMS (key management primitives)

Best for: centralized key lifecycle controls in cloud environments (often part of “crypto agility” programs).

FAQ

Is CNSA 2.0 the same thing as “NIST PQC standards”?

No. CNSA 2.0 is NSA’s suite for NSS use. It references NIST standards (FIPS 203/204, plus SP 800‑208 for LMS/XMSS), but NSA’s allowed set and restrictions are not identical to “everything NIST standardized.”

What algorithms does CNSA 2.0 require for key establishment and signatures?

Per the NSA FAQ v2.1, CNSA 2.0 requires ML‑KEM‑1024 (FIPS 203) for key establishment and ML‑DSA‑87 (FIPS 204) for digital signatures, for all classification levels.

Does CNSA 2.0 allow SLH‑DSA (SPHINCS+)?

No. The NSA FAQ states that SLH‑DSA is not part of CNSA and is not approved for any use in NSS.

Can I just use bigger RSA keys or bigger elliptic curves?

No. NSA explicitly says larger RSA/ECC does not address the quantum threat.

What are the key transition dates I should remember?

From the NSA FAQ:
* no enforcement prior to December 31, 2025 (for currently validated NIAP/CSfC profiles)
* January 1, 2027: new acquisitions must be CNSA 2.0 compliant
* December 31, 2030: phase out equipment/services that cannot support CNSA 2.0
* December 31, 2031: CNSA 2.0 algorithms mandated (unless otherwise noted)
* 2035: overall NSS quantum-resistant goal (NSM‑10)

Do I need to transition everything at once?

No. NSA expects a long period where systems use both CNSA 1.0 and CNSA 2.0 in different places. The practical goal is to prefer CNSA 2.0 where possible and tighten to “CNSA 2.0 only” as products mature and interoperability standards settle.

What’s NSA’s stance on hybrid cryptography?

NSA does not require hybrid solutions for security purposes, but acknowledges hybrids may be needed for interoperability and deployment constraints. NSA also warns that hybrids add complexity and can introduce new implementation and interoperability risks.

Further reading (primary sources)

Notice of Domain Availability
CNSA2.com is available for acquisition.

Make an Offer (secure transaction via SAW.com):
• CNSA2.com
This domain is owned by us, and all transactions are securely handled through SAW.com for buyer and seller protection.

Scroll to Top