CNSA 2.0

CNSA 2.0 deliberately picks the largest standardized parameter sets. ML-KEM-1024 and ML-DSA-87 both target NIST security category 5 (comparable to AES-256), and the advisory requires those Level V parameters at every classification level, including unclassified NSS. The December 2024 FAQ update replaced the original CRYSTALS-Kyber and CRYSTALS-Dilithium names with the final FIPS names and clarified that only implementations conforming to FIPS 203 and FIPS 204 are compliant; pre-standard Kyber or Dilithium implementations are not.

Software- and firmware-signing gets its own algorithms because NIST standardized stateful hash-based signatures years before the lattice schemes and the use case is urgent: signing keys baked into secure-boot chains must outlive the transition. NSA recommends LMS with SHA-256/192, approves all SP 800-208 parameter sets, and requires state management and hardware-backed signing per that publication. ML-DSA is also approved for signing once validated implementations exist, but NSA advises vendors not to wait for it.

The 2022 advisory sets per-technology-class milestones rather than one flag day, with the whole transition complete by 2035 in line with National Security Memorandum 10. The 2024 update to CNSSP 15 then added cross-cutting acquisition dates: from January 1, 2027, all new NSS acquisitions must be CNSA 2.0 compliant unless otherwise noted; by December 31, 2030, equipment and services that cannot support CNSA 2.0 must be phased out; and by December 31, 2031, CNSA 2.0 algorithms are mandated for use.

CNSA 2.0 diverges sharply from commercial internet practice on hybrids. NSA states it has confidence in the CNSA 2.0 algorithms and will not require NSS developers to use hybrid solutions for security purposes; standalone ML-KEM-1024 is acceptable. This contrasts with the hybrid-first posture of browser and TLS deployments (groups like X25519MLKEM768) and with European agencies such as Germany's BSI and France's ANSSI, which have recommended combining post-quantum and classical algorithms during the transition.

NSA's FAQ argues that hybrids add protocol and library complexity, extra negotiation and error handling, and new interoperability failure modes. It concedes that product availability and interoperability may still lead NSS to adopt hybrid constructions (and that some protocols may need hybrid-like constructions to carry ML-KEM-1024's larger sizes), but positions hybrids as a pragmatic accommodation, not a security requirement.

Formally, CNSA 2.0 applies to National Security Systems (networks carrying classified information or otherwise critical to military and intelligence missions) via CNSSP 15, with the NSA Director acting as National Manager for NSS. Products providing cryptography for NSS need NIAP or NSA validation, and approving officials measure compliance through the Risk Management Framework. The 2024 CNSSP 15 update also revoked prior waivers, forcing non-compliant systems back through the waiver process.

In practice the suite shapes far more than NSS. Vendors of operating systems, network equipment, HSMs, and secure-boot toolchains build CNSA 2.0 support into mainstream product lines rather than maintaining government-only variants, so its category 5 parameter choices and firmware-signing requirements propagate into commercial products. Organizations outside the NSS perimeter often adopt CNSA 2.0 timelines as a conservative planning baseline for their own post-quantum migrations.