CNSA 2.0 Compliance: A Practitioner Guide to Quantum-Safe Cryptography Migration
CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the NSA's replacement algorithm suite for organizations operating National Security Systems (NSS), mandating full migration from RSA, ECDSA, ECDH, and DH to quantum-resistant algorithms by 2030. The underlying standards, NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), were finalized in August 2024 and apply broadly beyond the defense sector to any organization with long-lived cryptographic assets.
The threat driving urgency is harvest-now-decrypt-later (HNDL): adversaries, particularly nation-state actors, are collecting encrypted traffic today with the intent to decrypt it once sufficiently powerful quantum computers become available. For data with a confidentiality requirement exceeding 10-15 years, the quantum threat is not future-state. The encrypted data being harvested today will still exist when the decryption capability arrives.
CNSA 2.0 vs CNSA 1.0: What Changed
CNSA 1.0 (published 2015) established the previous NSA-approved algorithm suite: AES-256, SHA-384, RSA-3072+ or ECDSA P-384 for signing, ECDH P-384 or DH-3072+ for key exchange. These remain secure against classical computers but are vulnerable to Grover's algorithm (symmetric) and Shor's algorithm (public-key) running on a large-scale quantum computer.
CNSA 2.0 replaces the public-key components entirely:
| Function | CNSA 1.0 (Legacy) | CNSA 2.0 (Quantum-Safe) |
|---|---|---|
| Key Establishment | ECDH P-384 | ML-KEM-1024 (FIPS 203) |
| Digital Signatures | ECDSA P-384 | ML-DSA-87 (FIPS 204) |
| Digital Signatures (alt) | RSA-3072+ | SLH-DSA-256 (FIPS 205) |
| Symmetric Encryption | AES-256 | AES-256 (unchanged) |
| Hashing | SHA-384 | SHA-384 / SHA-512 (unchanged) |
| Software Signing | Not specified | XMSS or LMS (stateful HBS) |
The symmetric algorithms (AES-256, SHA-384) are retained because Grover's algorithm halves their effective key size: AES-256 provides approximately 128-bit post-quantum security, which NSA deems sufficient. RSA and ECC are eliminated entirely for long-term use cases because Shor's algorithm breaks them completely given sufficient qubits.
The NIST Post-Quantum Standards: What They Are
NIST's post-quantum cryptography standardization project selected algorithms from a 7-year international competition. The three primary standards finalized in August 2024 are:
FIPS 203: ML-KEM (Module-Lattice Key Encapsulation Mechanism)
Formerly CRYSTALS-Kyber. The primary quantum-safe algorithm for key establishment and key encapsulation. ML-KEM-1024 is the CNSA 2.0-specified variant (highest security parameter). Based on the Module Learning With Errors (MLWE) problem over structured lattices, believed hard for both classical and quantum computers.
Key performance note: ML-KEM is faster than ECDH in most implementations and produces manageable key and ciphertext sizes (1,568 bytes for ML-KEM-1024 public key + 1,568 bytes ciphertext), making it viable for TLS, SSH, and application-layer key exchange.
FIPS 204: ML-DSA (Module-Lattice Digital Signature Algorithm)
Formerly CRYSTALS-Dilithium. The primary quantum-safe algorithm for digital signatures. ML-DSA-87 is the CNSA 2.0-specified variant. Also based on MLWE. Signature sizes are larger than ECDSA (4,595 bytes for ML-DSA-87 vs. 64 bytes for P-256 ECDSA), which is relevant for high-volume signing use cases and certificate chains.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
Formerly SPHINCS+. Hash-based signature scheme whose security relies only on properties of cryptographic hash functions, not lattice hardness assumptions. This is the conservative choice: if lattice problems prove breakable, SLH-DSA remains secure. Signature sizes are large (49,856 bytes for SLH-DSA-SHAKE-256f), making it suitable for software signing, certificate authorities, and code signing rather than high-frequency transaction signing.
NIST IR 8547: Deprecation Timeline
NIST IR 8547 (final) sets the deprecation schedule: RSA, ECDSA, ECDH, and DH are deprecated after 2030 and disallowed after 2035 for federal use.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Harvest-Now-Decrypt-Later: Why the Clock Is Already Running
The conventional framing of post-quantum cryptography as a future threat is incorrect for organizations with long-lived confidentiality requirements. Harvest-now-decrypt-later (HNDL) attacks change the threat timeline.
Nation-state adversaries, particularly those with the resources to eventually operate quantum computers, are collecting encrypted data today. NSA, CISA, and intelligence community assessments have consistently assessed that Russia and China are conducting large-scale collection of encrypted traffic from key exchange protocols, VPN traffic, and encrypted communications. The collection is happening now; the decryption capability is future-state.
Data at risk from HNDL:
- Long-term secrets: encryption keys, HSM seeds, master secrets
- Government classified communications (current NSS systems)
- Intellectual property and trade secrets with multi-decade value
- Health records (HIPAA retention requirements: 6-10 years; actual sensitivity: lifetime)
- Financial contracts and legal documents
Data NOT at risk from HNDL:
- Short-lived session keys (TLS sessions): by the time a quantum computer exists to break them, the data they protected has no remaining value
- Ephemeral key exchange using forward secrecy (PFS): TLS 1.3 with ECDHE already uses ephemeral keys; even if the long-term cert key is broken, past sessions are not compromised
Organizations should prioritize post-quantum migration for key establishment in long-lived data protection scenarios first, then certificate hierarchies and software signing, then general-purpose TLS.
CNSA 2.0 Migration Timelines by System Type
NSA's CNSA 2.0 advisory specifies different timelines by product category. These apply to NSS systems but serve as a reference model for commercial organizations.
Software and Firmware Signing (Immediate Priority)
NSA requires CNSA 2.0 algorithms for all new software and firmware signing by 2025, with full transition by 2030. Use SLH-DSA or ML-DSA for signing; transition existing signing infrastructure to quantum-safe algorithms before distributing firmware updates that will persist on devices for decades.
Network Security Devices (2026 Target)
VPNs, firewalls, routers, and switches used in NSS must support CNSA 2.0 algorithms by 2026. For commercial organizations, this means requiring CNSA 2.0 / ML-KEM support in procurement RFPs and evaluating vendor roadmaps for IKEv2, TLS 1.3, and IPsec implementations.
Operating Systems and Cryptographic Libraries (2026 Target)
Microsoft, Apple, Google, and major Linux distributions are integrating FIPS 203/204/205 into their cryptographic libraries. OpenSSL 3.x added experimental PQC support; liboqs (Open Quantum Safe) provides production-grade implementations. Require OS and library vendor roadmap commitments in procurement.
PKI and Certificate Hierarchies (2030 Deadline)
All certificate authorities, OCSP responders, and certificate management systems must support CNSA 2.0 algorithms by 2030. This includes migrating root CAs, intermediate CAs, and issued certificates. Plan for hybrid certificates (classical + post-quantum) during the transition period: X.509 hybrid certificate formats are under active IETF standardization.
Key Management Systems and HSMs (2030 Deadline)
HSM vendors (Thales, Entrust, Utimaco) are rolling out CNSA 2.0 support in firmware updates. Verify your HSM firmware supports ML-KEM and ML-DSA key generation and storage. HSM replacement may be required for older hardware that cannot support new algorithm families.
End-User Devices (2033 Target)
Client devices, smart cards, and end-user authentication tokens have the longest transition timeline due to hardware replacement cycles. This is the tail of the migration: focus earlier phases on infrastructure before end-user hardware.
Starting Your Cryptographic Inventory
You cannot migrate what you have not inventoried. A cryptographic inventory (also called a cryptographic bill of materials or CBOM) catalogues every place cryptography is used in your environment.
What to inventory:
- TLS/SSL certificate usage: which certificates, what key types and sizes, what validity periods, where they are deployed
- Code signing certificates and infrastructure
- Data-at-rest encryption: key management systems, key rotation schedules, algorithm configuration
- VPN and IPsec configurations: IKE version, DH group, cipher suites
- SSH host keys and authorized key configurations
- Application-layer cryptography: custom implementations, JWTs, database encryption keys
- HSMs: make, model, firmware version, algorithm support
Tooling for cryptographic discovery:
- TLS scan: sslyze, testssl.sh, or commercial certificate management platforms to identify all external and internal TLS endpoints
- Code signing: audit code signing certificates in your CI/CD pipeline, firmware signing infrastructure, and software distribution systems
- Network scanning: nmap with TLS scripts to enumerate cipher suites across internal network segments
Prioritize by data sensitivity and longevity: systems protecting secrets with value beyond 10-15 years (government data, health records, IP) are highest priority. Short-lived session encryption is lowest priority because data collected today will have no value when quantum computers arrive.
Hybrid Cryptography During the Transition
The IETF, NIST, and NSA all recommend hybrid cryptography as the transition approach: combining a classical algorithm (ECDH, ECDSA) with a post-quantum algorithm (ML-KEM, ML-DSA) so that security depends on the hardness of both problems. If the post-quantum algorithm proves breakable by a classical computer attack (a risk during the standardization period), the classical component still provides security. If the classical component is broken by a quantum computer, the post-quantum component provides security.
Hybrid key exchange in TLS 1.3:
RFC 8446 (TLS 1.3) supports hybrid key exchange via the key_share extension. IETF draft hybrid TLS extensions define how to combine ML-KEM with X25519 or P-256. The combined shared secret is derived from both key exchange outputs via a KDF.
Chrome 124+ and Firefox 132+ have enabled X25519+ML-KEM hybrid key exchange by default, making hybrid TLS the practical standard for browser traffic. Server-side support requires OpenSSL 3.x with liboqs integration or BoringSSL (used by Google).
Hybrid certificates:
X.509 hybrid certificate formats are under IETF standardization. In practice, running dual certificate hierarchies, a classical PKI for compatibility and a post-quantum PKI for systems that support it, is the near-term approach before hybrid certificate standards are widely deployed.
The bottom line
CNSA 2.0 and the finalized NIST post-quantum standards (FIPS 203, 204, 205) define the cryptographic future. For organizations outside the NSS scope, the migration is not optional long-term: NIST IR 8547 deprecates RSA, ECDSA, and ECDH for federal use after 2030, and commercial standards will follow. The practical starting point today is: build your cryptographic inventory (know what algorithms and key types you have, where they are deployed, and what data they protect), assess HNDL risk for long-lived sensitive data, evaluate vendor roadmaps for HSM, TLS, and PKI infrastructure CNSA 2.0 support, and begin piloting hybrid TLS in lower-stakes environments. The organizations that start inventory and vendor assessment now will be positioned to execute an orderly migration; those that wait will face compressed timelines and forced hardware replacement under deadline pressure.
Frequently asked questions
What is CNSA 2.0 and who does it apply to?
CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the NSA's mandated cryptographic algorithm suite for systems handling National Security Information. It replaces CNSA 1.0 and mandates migration from RSA, ECDSA, ECDH, and DH to quantum-resistant algorithms (ML-KEM, ML-DSA, SLH-DSA) by 2030. Mandatory compliance applies to U.S. national security systems and contractors operating those systems. Commercial organizations are not directly mandated, but NIST's post-quantum standards (FIPS 203/204/205) will become federal procurement requirements broadly, and the HNDL threat applies to any organization with long-lived sensitive data.
What are the NIST post-quantum standards and when were they finalized?
NIST finalized three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM, for key encapsulation, formerly CRYSTALS-Kyber), FIPS 204 (ML-DSA, for digital signatures, formerly CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, for hash-based signatures, formerly SPHINCS+). CNSA 2.0 specifies ML-KEM-1024, ML-DSA-87, and SLH-DSA-256 as the required parameter sets for national security use. A fourth standard, FIPS 206 (FN-DSA, formerly FALCON), was also finalized and is an alternative signature scheme.
What is a harvest-now-decrypt-later attack and should I be worried?
Harvest-now-decrypt-later (HNDL) means an adversary collects your encrypted traffic today and stores it, planning to decrypt it once quantum computers powerful enough to break RSA/ECC become available. This is a real and active threat: intelligence assessments confirm nation-state actors are conducting bulk collection of encrypted traffic. You should be worried if your data has a confidentiality requirement longer than 10-15 years: government records, health data (lifetime sensitivity), intellectual property, legal contracts, or any data that will still be sensitive when large-scale quantum computing arrives.
How do ML-KEM, ML-DSA, and SLH-DSA compare to RSA and ECDSA in performance?
ML-KEM is comparable to or faster than ECDH in key generation and encapsulation speed, with manageable key sizes (ML-KEM-1024 public key: 1,568 bytes). ML-DSA is slower than ECDSA and produces significantly larger signatures (ML-DSA-87: 4,595 bytes vs. 64 bytes for P-256 ECDSA), which is relevant for high-volume signing and certificate chain sizes. SLH-DSA is the slowest and largest (49,856 bytes for SLH-DSA-SHAKE-256f signatures) but has the most conservative security assumptions. For TLS handshakes and general key exchange, ML-KEM is performant enough that the transition overhead is modest.
What should we do first to start post-quantum migration?
Start with a cryptographic inventory: identify all TLS/SSL certificates, code signing infrastructure, VPN and IPsec configurations, HSMs, SSH host keys, and application-layer cryptography. Tools like sslyze, testssl.sh, and network TLS scanners help automate discovery. Then assess harvest-now-decrypt-later risk for long-lived sensitive data. Next, evaluate HSM vendor roadmaps for CNSA 2.0 support: HSMs often require firmware updates or hardware replacement and have the longest lead time. Pilot hybrid TLS (X25519+ML-KEM) in development and staging environments. Build CNSA 2.0 algorithm requirements into vendor procurement RFPs now.
What is hybrid cryptography and why is it recommended during the transition?
Hybrid cryptography combines a classical algorithm (ECDH, ECDSA) with a post-quantum algorithm (ML-KEM, ML-DSA) so that security depends on both being unbroken. This provides protection during the transition: if the post-quantum algorithm has an undiscovered classical attack, the classical component still protects; if the classical component is broken by a quantum computer, the post-quantum component still protects. Chrome 124+, Firefox 132+, and several major TLS libraries already support X25519+ML-KEM hybrid key exchange. IETF is standardizing hybrid X.509 certificate formats. Hybrid is the recommended approach during the transition period rather than immediate wholesale replacement.
When do HSMs need to support CNSA 2.0 and what should we ask vendors?
NSA's CNSA 2.0 timeline targets network security device support by 2026 and PKI/key management by 2030. For HSMs specifically, ask vendors: (1) Does current firmware support ML-KEM key generation, storage, and operation? (2) Is ML-DSA and SLH-DSA signing supported? (3) Can firmware be updated to add CNSA 2.0 support, or does it require hardware replacement? (4) What is the target firmware release date for FIPS 203/204/205 compliance? Major vendors including Thales Luna, Entrust nShield, and Utimaco are shipping CNSA 2.0 support in 2025-2026 firmware updates, but verify specific model support before assuming compatibility.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.