Exploring CNSA 2.0: The Core Algorithms for Next-Gen Security

Introduction

In September 2022, the National Security Agency (NSA) released the Commercial National Security Algorithm (CNSA) Suite 2.0, a significant update to its cryptographic standards for protecting national security systems (NSS). This suite, updated as of May 2025, introduces quantum-resistant algorithms to counter the emerging threat of quantum computing, which could potentially break traditional cryptographic methods like RSA and elliptic curve cryptography (ECC).

CNSA 2.0 is designed to ensure the long-term security of sensitive data, covering both classified and unclassified information used in NSS. This article explores the components of CNSA 2.0, their applications, and the transition timeline for adoption.

CNSA 2.0, defined: the NSA’s mandated cryptographic algorithm suite for National Security Systems, pairing a quantum-resistant key establishment mechanism (ML-KEM) with quantum-resistant signature algorithms (ML-DSA, LMS, XMSS) and stronger symmetric primitives (AES-256, SHA-384/512), each solving a distinct problem, never interchangeable with one another, on a dated transition schedule running through 2035.

Key Takeaways

• ML-KEM and ML-DSA solve different problems: ML-KEM establishes a shared secret (key exchange), ML-DSA produces a signature. Neither substitutes for the other, and software/firmware signing uses ML-DSA, LMS, or XMSS, never ML-KEM.
• This page is the general CNSA 2.0 algorithm reference, covering the full suite (encryption, key establishment, hashing, signing). For the dated migration architecture specifically for code signing, hybrid signing patterns, HSM readiness, and testing/rollback procedure, see Architecting the CNSA 2.0 Transition Strategies.
• Software and firmware signing carries the earliest deadline in the entire suite: prefer and support LMS/XMSS by 2025, exclusive use by 2030, well ahead of the 2035 deadline for the rest of NSS.
• SLH-DSA (FIPS 205) is a valid NIST post-quantum signature standard but is not part of CNSA 2.0 and is not approved for NSS use.

Background and Purpose

CNSA 2.0 updates the earlier CNSA 1.0, which was established in 2016 to replace NSA Suite B. The primary motivation for CNSA 2.0 is the advancement of quantum computing, which could render algorithms like RSA, Diffie-Hellman (DH), ECDH, and ECDSA vulnerable through Shor’s algorithm.

To address this, CNSA 2.0 incorporates post-quantum cryptographic algorithms standardized by the National Institute of Standards and Technology (NIST) and validated by the NSA. These algorithms are intended for use in all NSS, ensuring robust protection against both classical and quantum attacks.

Algorithm	Function	Specification	Parameters
General Purpose Algorithms
Advanced Encryption Standard (AES)	Symmetric block cipher for information protection	FIPS PUB 197	Use 256-bit keys for all classification levels.
ML-KEM (previously CRYSTALS-Kyber)	Asymmetric algorithm for key establishment	FIPS PUB 203	ML-KEM-1024 for all classification levels.
ML-DSA (previously CRYSTALS-Dilithium)	Asymmetric algorithm for digital signatures in any use case, including signing firmware and software	FIPS PUB 204	ML-DSA-87 for all classification levels.
Secure Hash Algorithm (SHA)	Algorithm for computing a condensed representation of information	FIPS PUB 180-4	Use SHA-384 or SHA-512 for all classification levels.
Algorithms Allowed in Specific Applications
Leighton-Micali Signature (LMS)	Asymmetric algorithm for digitally signing firmware and software	NIST SP 800-208	All parameters approved for all classification levels. LMS SHA-256/192 is recommended.
eXtended Merkle Signature Scheme (XMSS)	Asymmetric algorithm for digitally signing firmware and software	NIST SP 800-208	All parameters approved for all classification levels.
Secure Hash Algorithm 3 (SHA3)	Algorithm used for computing a condensed representation of information as part of hardware integrity	FIPS PUB 202	SHA3-384 or SHA3-512 allowed for internal hardware functionality only (e.g., boot-up integrity checks).

General-Purpose Algorithms

CNSA 2.0 includes a core set of algorithms for encryption, key exchange, digital signatures, and hashing, forming the cryptographic foundation for NSS.

Symmetric Algorithms

AES-256

The Advanced Encryption Standard (AES) remains the cornerstone of symmetric encryption in CNSA 2.0. Following the FIPS PUB 197 standard, AES-256 uses 256-bit keys across all classification levels, offering maximum security against both classical and quantum threats.

This is a step up from the 128-bit keys commonly used in many current systems, providing a stronger defense against potential cryptanalytic advances. In practice, AES-256 is widely deployed across NSS for securing classified communications, protecting stored data, and enabling encrypted channels in critical defense and intelligence applications.

Asymmetric Algorithms

ML-KEM (CRYSTALS-Kyber)

For secure key establishment, CNSA 2.0 mandates the use of the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), previously known as CRYSTALS-Kyber, standardized in FIPS PUB 203. Specifically, the ML-KEM-1024 parameter set is required for all classification levels.

ML-KEM is based on the module learning with errors (M-LWE) problem, which is believed to be resistant to quantum attacks. It replaces traditional key exchange methods like Elliptic Curve Diffie-Hellman (ECDH) and RSA, which are vulnerable to quantum computers. ML-KEM enables two parties to establish a shared secret key over an insecure channel, which can then be used for symmetric encryption.

ML-DSA (CRYSTALS-Dilithium)

For digital signatures, CNSA 2.0 specifies the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), formerly CRYSTALS-Dilithium, standardized in FIPS PUB 204. The ML-DSA-87 parameter set is mandated for all classification levels. ML-DSA ensures that digital signatures remain secure and verifiable even in a quantum computing era, replacing RSA and ECDSA signatures that could be broken by quantum algorithms. It is used for authentication and non-repudiation in various use cases, including software and firmware signing.

Hashing: SHA-384 and SHA-512

Hashing is critical for integrity verification and digital signature operations. CNSA 2.0 mandates the use of SHA-384 or SHA-512, as specified in FIPS PUB 180-4, for all classification levels. These algorithms provide a higher security margin than SHA-256, ensuring robust protection against potential cryptanalytic advances while maintaining computational efficiency for high-throughput applications.

Specialized Algorithms for Software and Firmware Signing

For applications requiring long-term security, such as software and firmware signing, CNSA 2.0 introduces hash-based signature schemes optimized for long-term integrity and robustness.

Leighton-Micali Signature (LMS) Scheme

The Leighton-Micali Signature (LMS) scheme, detailed in NIST SP 800-208, is designed for digitally signing firmware and software where signatures must remain valid for years or decades. LMS is a stateful hash-based signature scheme, meaning it uses one-time signatures and requires careful key management to ensure security.

All LMS parameter sets are approved for all classification levels, with LMS SHA-256/192 recommended for its optimal balance of security strength, computational efficiency, and implementation reliability. LMS is particularly suited for environments where hardware security modules (HSMs) are used, validated through NIST’s Cryptographic Module Validation Program (CMVP).

eXtended Merkle Signature Scheme (XMSS)

The eXtended Merkle Signature Scheme (XMSS), also specified in NIST SP 800-208, provides another option for software and firmware signing. Like LMS, XMSS is a stateful hash-based signature scheme, offering flexibility for organizations to choose configurations based on performance requirements, signature volume, and operational constraints. All XMSS parameter sets are approved across all classification levels, making it a versatile choice for long-term security applications.

Hybrid Signing and Verification Compatibility

Adopting LMS, XMSS, or ML-DSA doesn’t mean dropping classical signatures immediately. The practical pattern during transition is dual, parallel signing, an artifact carries both a classical (RSA/ECDSA) and a CNSA 2.0 signature, so systems that haven’t been updated to verify the new algorithm still trust the classical one while updated systems gain quantum-resistant verification. This matters because verifier support for LMS, XMSS, and ML-DSA is not yet universal; confirm the specific bootloaders, update mechanisms, and platforms in your environment actually recognize the algorithm you choose before relying on it as the sole signature. HSM readiness needs the same specific confirmation: check firmware support for the exact algorithm and parameter set (for example, LMS SHA-256/192) with your HSM vendor per model, since general PQC-readiness marketing claims don’t guarantee support for a specific scheme.

Additional Cryptographic Components

SHA-3 for Internal Hardware Functions

CNSA 2.0 authorizes SHA3-384 and SHA3-512, as per FIPS PUB 202, exclusively for internal hardware functions such as secure boot processes and hardware integrity checks. This limited use ensures modernization of internal cryptographic processes while maintaining strict interoperability standards and avoiding the complexity of broader SHA-3 deployment.

Transition Timeline and Enforcement

The transition to CNSA 2.0 is guided by specific timelines outlined in National Security Memorandum (NSM)-10:

• Software and Firmware Signing: Organizations are encouraged to begin adopting LMS and XMSS immediately, with full adoption required by 2025 and completion by 2030.
• Other Components: Full transition across all NSS is targeted for completion by 2035, with interim use of CNSA 1.0 algorithms permitted but CNSA 2.0 preferred.
• Specific Milestones:
  1. Web browsers/servers and cloud services: 2025 (preferred), 2033 (mandatory).
  2. Traditional networking equipment: 2026 (preferred), 2030 (mandatory).
  3. Operating systems: 2027 (preferred), 2033 (mandatory).
  4. Niche equipment and custom/legacy systems: Update or replace by 2033.

Compliance is enforced through the Risk Management Framework (RMF) SC-12 and NSA-approved or NIAP-validated products, as per CNSSP 11. Progress is monitored under NSM-8 and NSM-10.

Implications and Recommendations

CNSA 2.0 represents a proactive approach to securing national security systems against future quantum threats. Organizations involved in NSS should:

• Begin Transition Planning: Start integrating CNSA 2.0 algorithms, particularly for software and firmware signing, to meet the 2025 deadline.
• Leverage NIST Standards: Use FIPS and NIST SP standards to ensure compliance and interoperability.
• Monitor Updates: As quantum computing evolves, further updates to CNSA 2.0 may be released, requiring ongoing vigilance.

How Encryption Consulting Supports CNSA 2.0 Adoption

Encryption Consulting provides expert guidance to navigate the transition to CNSA 2.0, ensuring your systems are quantum-resistant. Here’s a concise overview of their support process:

• Cryptographic Discovery & Inventory: Scans your IT environment to identify cryptographic assets (certificates, keys, algorithms) across endpoints, applications, and devices, creating a detailed inventory for risk assessment.
• PQC Assessment: Evaluates quantum readiness by analyzing vulnerabilities in systems using RSA or ECC, reviewing PKI/HSM setups, and prioritizing migration needs with a detailed report.
• PQC Strategy & Roadmap: Designs a tailored migration plan aligned with business and CNSA 2.0 requirements, incorporating algorithm agility and a phased rollout approach.
• Vendor Evaluation & Proof of Concept: Identifies PQC-capable vendors, defines technical requirements, and conducts PoC tests to evaluate integration and performance, delivering a vendor comparison matrix.
• Pilot Testing & Scaling: Validates PQC solutions in controlled environments, ensuring interoperability and minimal disruption, followed by a scalable rollout with ongoing optimization.
• PQC Implementation: Executes full-scale migration, integrating quantum-safe algorithms, providing team training, and setting up monitoring for compliance and future upgrades.

With Encryption Consulting’s expertise, organizations can confidently transition to CNSA 2.0, building a secure, future-ready cryptographic infrastructure.

Conclusion

CNSA 2.0 is a critical step toward future-proofing cryptographic security for national security systems. By adopting quantum-resistant algorithms like AES-256, ML-KEM, ML-DSA, SHA-384/512, LMS, and XMSS, the NSA ensures that sensitive data remains protected against both current and emerging threats. The rigorous validation process and clear transition timelines provide a roadmap for organizations to achieve robust, long-term security.

Frequently Asked Questions

Is ML-KEM used to sign code or firmware?

No. ML-KEM is a key encapsulation mechanism used to establish a shared secret; it has no role in producing a digital signature. Software and firmware signing under CNSA 2.0 uses ML-DSA, LMS, or XMSS instead.

Is SLH-DSA part of CNSA 2.0?

No. SLH-DSA (FIPS 205) is a final NIST post-quantum signature standard and is legitimate for commercial use, but it is not included in the CNSA 2.0 suite and is not approved for National Security Systems.

Why does software and firmware signing have an earlier deadline than the rest of NSS?

Because firmware roots of trust are the hardest components to update after a device ships. Devices deployed today may still be in service when the broader 2035 deadline arrives, so the transition for signing specifically is required earlier, by 2030, to avoid shipping products that are already behind the curve.

Do I need to replace classical signatures immediately when adopting CNSA 2.0?

No. Dual, parallel signing, both a classical and a CNSA 2.0 signature on the same artifact, is the practical transition pattern while verifier support for the new algorithms is still uneven across platforms.