In September 2022, the NSA published CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) — a set of requirements for transitioning national security systems to quantum-resistant cryptography. Unlike NIST’s PQC standards (which provide options), CNSA 2.0 is prescriptive: it tells you exactly which algorithms to use, by when, with no ambiguity.
If you work with US government systems, defense contractors, or any organization handling classified or sensitive government data, CNSA 2.0 isn’t optional. It’s a mandate with hard deadlines.
But even if you’re not in the government supply chain, CNSA 2.0 serves as the clearest roadmap available for post-quantum migration. When the NSA says “stop using RSA and ECC by 2033,” the rest of the industry follows within 5-10 years.
What CNSA 2.0 Requires
CNSA 2.0 replaces the original CNSA 1.0 (which recommended RSA-3072+ and P-384). The new suite mandates quantum-resistant algorithms:
| Use Case | CNSA 2.0 Algorithm | Replaces | Deadline |
|---|---|---|---|
| Key Establishment | ML-KEM-1024 (FIPS 203) | ECDH P-384, DH | 2030 |
| Digital Signatures | ML-DSA-87 (FIPS 204) | ECDSA P-384, RSA | 2033 |
| Digital Signatures (firmware/software) | SLH-DSA (FIPS 205) | ECDSA, RSA | 2030 |
| Symmetric Encryption | AES-256 | AES-128 (upgrade) | Immediate |
| Hashing | SHA-384 or SHA-512 | SHA-256 (upgrade) | Immediate |
Key deadlines:
- 2025: Begin planning and testing. Prefer CNSA 2.0 algorithms for new systems.
- 2030: All software/firmware signing must use SLH-DSA or ML-DSA. All key establishment must use ML-KEM.
- 2033: All remaining systems must use CNSA 2.0 algorithms exclusively. RSA and ECC are prohibited for national security systems.
The Algorithms: What You Need to Know
ML-KEM (Module-Lattice Key Encapsulation Mechanism)
Previously known as CRYSTALS-Kyber. This replaces RSA key exchange and ECDH for establishing shared secrets.
- FIPS 203 (published August 2024)
- CNSA 2.0 requires: ML-KEM-1024 (highest security level)
- Key sizes: Public key ~1,568 bytes, ciphertext ~1,568 bytes (much larger than ECDH’s 32 bytes)
- Performance: Fast — comparable to ECDH on modern hardware
- Use in TLS: Hybrid key exchange (X25519 + ML-KEM-768) already deployed in Chrome and Cloudflare
ML-DSA (Module-Lattice Digital Signature Algorithm)
Previously known as CRYSTALS-Dilithium. This replaces RSA and ECDSA for digital signatures.
- FIPS 204 (published August 2024)
- CNSA 2.0 requires: ML-DSA-87 (highest security level)
- Signature size: ~4,627 bytes (vs 64 bytes for ECDSA P-256)
- Public key size: ~2,592 bytes (vs 64 bytes for ECDSA P-256)
- Performance: Signing and verification are fast; the size increase is the main challenge
- Impact on TLS: Certificates become significantly larger, increasing handshake size
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
Previously known as SPHINCS+. A conservative, hash-based signature scheme.
- FIPS 205 (published August 2024)
- CNSA 2.0 requires: SLH-DSA for firmware and software signing
- Signature size: ~7,856-49,856 bytes (depending on parameter set)
- Why it exists: Based purely on hash function security — no lattice assumptions. If lattice-based crypto is broken, SLH-DSA still stands.
- Trade-off: Much larger signatures and slower signing than ML-DSA, but more conservative security assumptions
Why CNSA 2.0 Matters Beyond Government
Even if you’re not a defense contractor, CNSA 2.0 signals where the entire industry is heading:
1. Supply chain requirements flow downstream. If your customer is a government agency or defense contractor, they’ll require CNSA 2.0 compliance from their vendors. This cascades through the supply chain.
2. “Harvest now, decrypt later” is real. Nation-state adversaries are recording encrypted traffic today, planning to decrypt it when quantum computers are available. Data with long-term sensitivity (healthcare records, financial data, trade secrets, legal communications) needs quantum-safe encryption now — not when quantum computers arrive.
3. Algorithm deprecation timelines. When the NSA says “RSA prohibited by 2033,” expect commercial CAs and browser vendors to follow within 5-7 years. Planning for RSA/ECC deprecation now avoids a rushed migration later.
4. Compliance frameworks will adopt CNSA 2.0. FedRAMP, CMMC, and NIST 800-53 will incorporate CNSA 2.0 requirements. Organizations seeking these certifications will need quantum-safe cryptography.
The Migration Challenge
Migrating to CNSA 2.0 algorithms isn’t a simple configuration change. The challenges:
Larger Keys and Signatures
| Algorithm | Public Key | Signature | Certificate Size Impact |
|---|---|---|---|
| RSA-2048 | 256 bytes | 256 bytes | ~1.2 KB per cert |
| ECDSA P-256 | 64 bytes | 64 bytes | ~0.8 KB per cert |
| ML-DSA-87 | 2,592 bytes | 4,627 bytes | ~8 KB per cert |
| SLH-DSA-256f | 64 bytes | 49,856 bytes | ~50 KB per cert |
A TLS certificate chain (end-entity + intermediate + root) using ML-DSA-87 is approximately 24 KB — vs ~3.5 KB with ECDSA. This increases TLS handshake size, which impacts:
- Connection latency (more round trips for large handshakes)
- Mobile performance (larger data transfer on cellular)
- IoT devices (constrained memory and bandwidth)
Hybrid Deployments
During the transition period, systems must support both classical and post-quantum algorithms simultaneously (hybrid mode). This means:
- TLS key exchange: X25519 + ML-KEM (both performed, shared secrets combined)
- Certificates: dual signatures (ECDSA + ML-DSA) or separate certificate chains
- Increased complexity in every cryptographic operation
Library and Hardware Support
- OpenSSL 3.x: PQC support via oqs-provider (Open Quantum Safe project)
- BoringSSL (Chrome): ML-KEM-768 hybrid already in production
- Java: Bouncy Castle has experimental PQC support; JDK native support expected in Java 24+
- HSMs: Most HSMs don’t support PQC algorithms yet. Thales and Entrust have announced roadmaps for 2025-2026.
- Hardware acceleration: No dedicated PQC hardware acceleration exists yet (unlike AES-NI for AES)
A Practical Migration Roadmap
Phase 1: Inventory and Assessment (Now)
- Cryptographic inventory (CBOM): Identify every algorithm, key, and certificate in your infrastructure. You can’t migrate what you can’t see.
- Data classification: Which data has long-term sensitivity (10+ years)? This needs quantum-safe protection first.
- Dependency mapping: Which systems depend on RSA/ECC? Which libraries, HSMs, and protocols are involved?
- Vendor readiness: Check if your CA, HSM vendor, TLS library, and cloud provider support PQC algorithms.
Phase 2: Hybrid Deployment (2025-2027)
- Enable hybrid key exchange in TLS: Configure servers to support X25519+ML-KEM-768 (Chrome and Firefox already negotiate this).
- Test PQC certificates: Issue test certificates with ML-DSA signatures from a test CA. Verify your infrastructure handles the larger sizes.
- Protect long-term data: Encrypt sensitive data at rest with AES-256 (already quantum-safe for symmetric) and use hybrid key exchange for data in transit.
- Update firmware signing: Move to SLH-DSA for firmware and software signing (CNSA 2.0’s earliest deadline).
Phase 3: Full Migration (2027-2030)
- Replace RSA/ECC certificates with ML-DSA certificates as CAs begin issuing them.
- Upgrade HSMs to models supporting PQC algorithms.
- Update all TLS configurations to prefer PQC cipher suites.
- Deprecate classical-only connections — require hybrid or PQC-only.
Phase 4: Classical Removal (2030-2033)
- Disable RSA and ECC for key exchange and signatures.
- Revoke classical certificates and replace with PQC-only.
- Verify no fallback to classical algorithms exists in any system.
What You Can Do Today
Even before full PQC migration, these steps reduce quantum risk immediately:
- Use AES-256 everywhere (already quantum-safe for symmetric encryption)
- Use SHA-384 or SHA-512 for hashing (CNSA 2.0 requirement, easy to implement now)
- Enable hybrid key exchange in TLS (X25519+ML-KEM — supported in modern browsers)
- Build a cryptographic inventory — you need this regardless of timeline
- Start testing — deploy PQC-enabled libraries in non-production environments
- Monitor NIST and CA/Browser Forum for PQC certificate issuance timelines
FAQ
Q: Do I need to worry about CNSA 2.0 if I’m not in government? A: Not immediately for compliance, but the algorithm deprecation timelines affect everyone. RSA and ECC will eventually be deprecated industry-wide. CNSA 2.0 is the clearest signal of when.
Q: Is AES-256 quantum-safe? A: Yes. Grover’s algorithm reduces AES-256 to 128-bit security against quantum computers — still computationally infeasible. AES-128 drops to 64-bit (potentially vulnerable). Use AES-256.
Q: When will CAs issue PQC certificates? A: Experimental PQC certificates are available now (from test CAs). Production issuance from major CAs is expected 2026-2027, with browser trust following shortly after.
Q: What about performance impact? A: ML-KEM and ML-DSA are computationally fast (comparable to ECDH/ECDSA). The challenge is size, not speed. Larger keys and signatures increase bandwidth, not CPU time.
Q: Should I wait for standards to stabilize? A: FIPS 203, 204, and 205 are finalized (August 2024). The algorithms are stable. What’s still evolving: hybrid certificate formats, CA issuance practices, and HSM support. Start planning and testing now; full deployment can wait for ecosystem maturity.