The Commercial National Security Algorithm Suite (CNSA) is the U.S. National Security Agency’s official set of cryptographic algorithms for protecting National Security Systems (NSS), which are systems that handle classified and highly sensitive government information. Any compromise of these systems could have national-level consequences.
CNSA 1.0, introduced in 2016, reflected the security requirements and threat landscape of the time. It employed well-established public key algorithms such as RSA and Elliptic Curve Cryptography (ECC P-384), paired with robust symmetric encryption and secure hashing. For nearly a decade, this suite formed the cryptographic backbone of classified systems.
However, accelerating research into quantum computing has fundamentally altered the risk profile. In response, the NSA released CNSA Suite 2.0, replacing vulnerable public key algorithms with post-quantum cryptographic (PQC) alternatives designed to withstand both classical and quantum attacks.
CNSA 1.0 vs CNSA 2.0, in short: CNSA 1.0 (2016) relied on RSA, ECDH, and ECDSA for public-key operations; CNSA 2.0 (2022, updated through 2025) replaces key exchange with ML-KEM and signatures with ML-DSA or, for software and firmware specifically, LMS/XMSS, on a phased NSM-10 timeline running from 2025 preferred adoption to a 2035 full transition, while leaving AES-256 and SHA-384/512 largely unchanged.
Key Takeaways
- The change is concentrated in public-key operations: ML-KEM replaces ECDH/RSA for key exchange, and ML-DSA/LMS/XMSS replace ECDSA/RSA for signatures. AES-256 and SHA-384/512 carry over from CNSA 1.0 largely unchanged.
- Software and firmware signing has the earliest deadline in the entire suite (prefer by 2025, mandatory by 2030), well ahead of the 2035 deadline for the rest of NSS, because firmware roots of trust are the hardest components to update retroactively.
- This page is the historical comparison between the two suites. For the general algorithm reference, see Exploring CNSA 2.0: The Core Algorithms; for the dated migration architecture, see Architecting the CNSA 2.0 Transition Strategies; for hybrid/dual signing patterns during transition, see Hybrid Cryptography for the CNSA 2.0 Transition.
Why Quantum Changes Everything
In classical computing architectures, asymmetric encryption mechanisms such as RSA and ECC remain effectively secure within the operational lifespan of protected data, assuming no breakthroughs in cryptanalysis. However, quantum computing introduces fundamentally different computation paradigms that render these assumptions obsolete.
- Shor’s algorithm poses a direct threat to the integrity of public-key cryptographic systems. By efficiently factoring integers and computing discrete logarithms in polynomial time, Shor’s algorithm would break both RSA and ECC in drastically reduced time frames, a capability entirely out of reach for classical systems.
- Grover’s algorithm accelerates brute-force search capabilities, delivering a quadratic speed-up against symmetric key schemes. As a result, symmetric ciphers like AES must compensate by effectively doubling key lengths to preserve equivalent security margins.
The strategic relevance of quantum-resistant cryptography is critical. The “harvest now, decrypt later” approach compels immediate action: adversaries are archiving ciphertexts today with the expectation of future decryption capability. Any delay in migrating to quantum-resilient systems risks irrevocable exposure of long-lived sensitive data.
CNSA 2.0 is designed to neutralize this quantum threat well before large-scale quantum computing capabilities materialize.
What Stays the Same
CNSA 2.0 does not replace every algorithm. Several cryptographic primitives are already considered secure against quantum threats and continue to be supported:
- AES-256 remains the symmetric encryption standard across all classification levels, offering a strong security margin.
- SHA-384 continues as the default for general-purpose hashing, with SHA-512 also permitted where interoperability requires it.
- SHA-3 is not approved for broad use but is allowed in very limited contexts. Vendors may use SHA3384 or SHA3-512 for internal hardware functions that do not interoperate outside their environment, such as integrity checks in secure boot. In addition, SHA-3 is permitted when explicitly required by other approved standards, such as NIST’s LMS or XMSS.
By keeping these algorithms in place, CNSA 2.0 ensures that much of the encryption and hashing infrastructure can remain stable, with changes focused only on areas most impacted by the post-quantum transition.
Key Differences Between CNSA 1.0 and CNSA 2.0
The transition from CNSA 1.0 to 2.0 represents not just an algorithm swap but a fundamental change in cryptographic design and threat modeling.
| Category | CNSA 1.0 | CNSA 2.0 |
|---|---|---|
| Focus | Built to strengthen existing encryption, but only against today’s threats. | Designed to handle the future, especially the rise of quantum computers. |
| Key Exchange | Used RSA and ECDH, which are solid but vulnerable to quantum attacks. | Switches to Kyber, a post-quantum algorithm, and supports hybrid mode for a safer transition. |
| Digital Signatures | Relied on RSA-3072 and ECDSA, strong but not quantum-resistant. | General-purpose signing moves to ML-DSA (FIPS 204); software and firmware signing specifically uses LMS or XMSS (NIST SP 800-208) and carries the earliest deadline in the whole suite. |
| Quantum Safety | Not built to survive a quantum future. | Fully prepped for the post-quantum world. |
| Implementation Deadline | No official urgency to adopt. | Phased under NSM-10: software/firmware signing preferred by 2025, mandatory by 2030; other NSS components on a schedule reaching full transition by 2035. |
Hybrid Cryptography: Bridging the Transition
The transition from CNSA 1.0 to CNSA 2.0 will not happen overnight. Hybrid cryptography plays an important role during this phase by combining a classical algorithm with a post-quantum one. For example, a hybrid key exchange might use ECDH P-384 together with ML-KEM-1024, so that even if one algorithm were broken, the system would still remain secure.
The NSA has made it clear that CNSA 2.0 algorithms are strong enough on their own, but hybrids can be useful in certain situations. They are especially valuable when dealing with interoperability issues, such as in IKEv2, where the larger ML-KEM-1024 keys create challenges that can be solved through hybrid methods.
At the same time, hybrid approaches are not a perfect solution. They add complexity, can slow down standardization, and will eventually require another migration step when classical algorithms are phased out. Because of this, NSA only recommends hybrids where necessary, with the ultimate goal being a complete move to quantum-resistant CNSA 2.0 algorithms.
Production-Readiness: What to Confirm Before Migrating
Before committing a given system to CNSA 2.0 algorithms, confirm two things independently rather than assuming from the standard’s publication date alone. First, verifier compatibility: not every bootloader, TLS stack, or signing client recognizes ML-KEM, ML-DSA, or LMS/XMSS yet, so test against the specific software versions in your deployment path. Second, HSM readiness: FIPS validation and vendor firmware support for a specific PQC algorithm and parameter set lag behind the NIST standard itself, so confirm with your HSM vendor which exact schemes their current firmware supports before planning around them.
How Encryption Consulting Can Help?
Encryption Consulting helps enterprises and governments implement CNSA 2.0-aligned signing infrastructures with full PQC and hybrid crypto support.
CodeSign Secure v3.02 supports PQC out of the box, giving organizations a head start in adapting to the next era of cryptography without sacrificing usability or performance. It’s a smart move now and a necessary one for the future.
Moving to CNSA 2.0 isn’t just about selecting the right algorithm. It’s about building an end-to-end code signing strategy that protects keys, automates workflows, enforces policy, and ensures compliance. That’s exactly what CodeSign Secure was built for.
Here’s how CodeSign Secure supports CNSA 2.0:
- LMS & XMSS-Ready: Already supports the post-quantum signature schemes required for software and firmware signing.
- HSM-Backed Key Protection: Your private keys stay protected inside FIPS 140-2 Level 3 HSMs, ensuring no exposure.
- State Tracking Built-In: Automatically manages state for LMS and XMSS to ensure every signature is compliant.
- DevOps Friendly: Integrates natively with Jenkins, GitHub Actions, Azure DevOps, and more.
- Policy-Driven Security: Use RBAC, multi-approver (M of N) sign-offs, and custom security policies to control every aspect of your code signing.
- Audit-Ready Logging: Get full visibility into every signing operation for easy reporting and compliance.
Whether you’re signing software for Windows, Linux, macOS, Docker, IoT devices, or cloud platforms, CodeSign Secure is ready to help you transition safely and efficiently.
Frequently Asked Questions
Does CNSA 2.0 replace AES and SHA?
No. AES-256 and SHA-384/SHA-512 carry over from CNSA 1.0 largely unchanged; they’re already considered quantum-resistant when used with sufficient key/output length. The changes are concentrated in public-key key exchange and signature algorithms.
Is Kyber the same thing as ML-KEM?
Yes. ML-KEM (FIPS 203) is the standardized name for CRYSTALS-Kyber after NIST finalized it. Similarly, ML-DSA (FIPS 204) is the standardized name for CRYSTALS-Dilithium.
Why does software and firmware signing have a 2030 deadline instead of 2035?
Because firmware roots of trust are among the hardest components to update once a device is deployed. Devices shipping today may still be in service well past 2030, so NSM-10 sets an earlier deadline for signing specifically to avoid shipping products that are already behind schedule by the time they reach the field.
Conclusion
CNSA 2.0 retains the proven symmetric encryption and hashing functions from its predecessor while replacing all vulnerable public key mechanisms with quantum-resistant algorithms. This forward-looking overhaul, anchored by ML-KEM for key establishment, ML-DSA for signatures, and hash-based schemes for code signing, positions National Security Systems to withstand both current and future cryptographic threats.
With hybrid cryptography easing the migration, organizations can begin adoption now, ensuring that systems, policies, and supply chains are quantum-ready before adversaries can exploit the next great leap in computing.
