NSA Updates CNSA 2.0 Guidance After NIST Finalizes Post-Quantum Standards

December 29, 2024 – The U.S. National Security Agency has released Version 2.1 of its Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) FAQ, updating its post-quantum cryptography guidance for National Security Systems (NSS) following NIST’s finalization of the first three post-quantum cryptography standards in August 2024. The update replaces the April 2024 V2.0 FAQ and incorporates the now-official FIPS references, tightens algorithm restrictions, and provides the most detailed enforcement timeline NSA has published to date.

The core algorithm suite remains unchanged from what NSA signaled in the original September 2022 advisory and my earlier coverage, but the V2.1 FAQ resolves several ambiguities that had lingered while NIST’s standards were still in draft. The pre-standard names are gone: CRYSTALS-Kyber is now ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), specified in FIPS 203, and CRYSTALS-Dilithium is now ML-DSA (Module-Lattice-Based Digital Signature Standard), specified in FIPS 204. NSA requires the highest parameter sets only: ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures, at all classification levels.

Critically, NSA has clarified that any implementation calling itself “CRYSTALS-Kyber” or “CRYSTALS-Dilithium” that does not adhere to the final FIPS 203 or FIPS 204 specifications is not CNSA 2.0 compliant. Pre-standard implementations, including those built against draft versions of the algorithms, will not satisfy the requirement.

What Changed in V2.1

The V2.1 FAQ introduces several clarifications and restrictions that go beyond the April 2024 V2.0:

Finalized FIPS references. The algorithm table now cites FIPS 203 and FIPS 204 directly, replacing the “TBD” placeholders from the original 2022 advisory. CNSSP 15 — the policy document that governs which algorithms NSS must use — now formally includes CNSA 2.0.

SLH-DSA excluded from all NSS use. SLH-DSA (formerly SPHINCS+), the stateless hash-based signature algorithm that NIST standardized as FIPS 205, is explicitly not approved for any use in National Security Systems. Despite being hash-based, it is not part of CNSA 2.0.

HashML-DSA prohibited. The pre-hash mode of ML-DSA, which allows message compression before signing, is not permitted in NSS. NSA’s reasoning: it offers no functionality beyond what SHA-384 or SHA-512 combined with standard ML-DSA-87 already provides, and restricting it avoids interoperability fragmentation.

FN-DSA (Falcon) will not be added. NSA states it does not plan to add future NIST post-quantum standards to CNSA 2.0. The FAQ explicitly addresses FN-DSA: NSA agrees with NIST that ML-DSA is preferred because FN-DSA appears more susceptible to implementation errors affecting security.

SHA-3 allowed in narrow cases. SHA3-384 or SHA3-512 may now be used for internal hardware integrity functions (such as boot-up checks), at the vendor’s discretion. This is a concession to speed the transition — some vendors’ internal processes benefit from SHA-3 properties. SHA-3 remains prohibited as a general-purpose hash algorithm in CNSA 2.0.

Multi-tree signature schemes excluded. HSS (the multi-tree variant of LMS) and XMSS^MT are not approved for NSS. Only single-tree LMS and XMSS are allowed for software and firmware signing.

ML-DSA approved for firmware signing. While LMS and XMSS remain the preferred near-term choice for firmware roots of trust (because validated implementations are already commercially available), ML-DSA is now explicitly approved for all signing use cases, including firmware, once validated implementations become available.

The Enforcement Timeline

The V2.1 FAQ provides the most granular enforcement schedule NSA has released. The headline numbers match the original 2022 advisory, but V2.1 adds enforcement mechanics that give them teeth:

No mandatory CNSA 2.0 transition before December 31, 2025. Systems already validated under a NIAP or CSfC profile remain approved until their validation period ends.

January 1, 2027: the procurement gate. All new acquisitions for NSS must support CNSA 2.0 algorithms, unless an exception is explicitly noted. This is the date that turns CNSA 2.0 from guidance into a procurement requirement.

December 31, 2030: All equipment and services that cannot support CNSA 2.0 must be phased out.

December 31, 2031: CNSA 2.0 algorithm use becomes mandatory across the board, unless explicitly exempted. NSA expects the vast majority of cryptography in NSS to be quantum-resistant by this date.

The CNSA 1.0 compliance trap. Any NSS not currently compliant with CNSA 1.0 has six months from the publication of the updated CNSSP 15 to achieve CNSA 2.0 compliance (not CNSA 1.0), or must submit a waiver request within 90 days. This is a significant detail: if you’re behind on CNSA 1.0, you can’t catch up to 1.0; you must jump to 2.0.

The category-specific timeline from the original advisory remains:

• Software/firmware signing: support and prefer CNSA 2.0 by 2025, exclusively use by 2030
• Web browsers/servers and cloud services: support and prefer by 2025, exclusively use by 2033
• Traditional networking equipment (VPNs, routers): support and prefer by 2026, exclusively use by 2030
• Operating systems: support and prefer by 2027, exclusively use by 2033
• Niche equipment (constrained devices, large PKI systems): support and prefer by 2030, exclusively use by 2033
• Custom applications and legacy equipment: update or replace by 2033

My Analysis

Three things stand out in this update.

First, NSA is narrowing the algorithm menu, not expanding it. The decision to exclude SLH-DSA, prohibit HashML-DSA, reject multi-tree signature schemes, and preemptively rule out FN-DSA tells you exactly what NSA is optimizing for: a tight, interoperable algorithm set that minimizes the complexity of the transition. This is the right call for an organization managing cryptographic transitions across thousands of NSS implementations. But it creates a tension I’ll come back to.

Contrast this with Germany’s BSI, which explicitly recommends SLH-DSA as a conservative fallback precisely because it doesn’t depend on lattice hardness assumptions. NSA and BSI are reading the same cryptanalytic evidence and reaching different policy conclusions — NSA prioritizing operational simplicity, BSI prioritizing algorithmic diversity as a hedge against lattice breakthroughs. Organizations operating in both jurisdictions will need to reconcile these choices.

Second, the January 2027 procurement gate is the date that matters. The 2030 and 2033 milestones get the attention, but the 2027 acquisition requirement is what will actually force action. Defense acquisition cycles run 18 to 36 months. Systems being designed today will be delivered after the deadline. If your product can’t support ML-KEM-1024 and ML-DSA-87 on delivery day in January 2027, it fails the procurement gate. Period.

For anyone still treating CNSA 2.0 as a future concern, this should recalibrate the urgency. As I’ve argued in Q-Day Predictions Are Irrelevant — Deadlines Are Set, the reason to act on post-quantum cryptography is not the arrival of a cryptanalytically relevant quantum computer (CRQC). It’s the ecosystem of regulatory, contractual, and procurement deadlines that are already locked in. CNSA 2.0 is the sharpest example of that in practice.

Third, there’s a FIPS 140-3 squeeze coming. The V2.1 FAQ repeatedly references the need for NIAP validation and CMVP-validated cryptographic modules. But NIST is moving all FIPS 140-2 certificates to Historical status in 2026, and the CMVP validation pipeline for post-quantum algorithms is still ramping up. Organizations that need FIPS 140-3 validated modules with ML-KEM and ML-DSA support are going to hit a bottleneck: the validation process takes 12 to 18 months, and the queue is growing. Start early.

For organizations beginning their PQC migration — whether driven by CNSA 2.0 or by the broader Harvest Now, Decrypt Later (HNDL) threat — the PQC Migration Framework provides a structured, open-source starting point. The Practical Steps to Quantum Readiness guide walks through the process in detail.

The NSA’s V2.1 update is not a policy revolution. It’s a policy crystallization. The algorithms, the timelines, and the enforcement mechanisms are now locked in with a specificity that leaves little room for ambiguity. The planning phase is over. Implementation has started.