Quick Answer
This guide is for PKI architects, security teams, and compliance officers preparing for the post-quantum cryptography transition.
CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) is the NSA's updated cryptographic algorithm suite designed to protect National Security Systems (NSS) against quantum computer threats. It mandates a transition from RSA and ECC to quantum-resistant algorithms like ML-DSA (for signatures) and ML-KEM (for key exchange).
Why this matters beyond government: Defense contractors, vendors to federal agencies, and organizations handling sensitive data will need to align with CNSA 2.0. The transition starts NOW for software signing and extends through 2033 for all systems.
💡 Key Takeaway: Unlike CNSA 1.0 (which strengthened classical algorithms), CNSA 2.0 introduces entirely new algorithm families. Your CLM platform, CA infrastructure, and certificate workflows will all need updates.
Start with our Post-Quantum Cryptography Guide for foundational concepts.
What is CNSA 2.0?
The Commercial National Security Algorithm Suite 2.0 is the NSA's cryptographic guidance for protecting classified and sensitive national security information against the threat of cryptographically relevant quantum computers (CRQCs).
Who Must Comply?
- National Security Systems (NSS) operators
- Defense Industrial Base (DIB) contractors
- Federal agencies (via CISA/OMB guidance)
- Vendors providing crypto products to government
Non-NSS organizations can treat CNSA 2.0 as a high-water mark for PQ readiness planning.
The Quantum Threat
Quantum computers running Shor's algorithm can break RSA, ECDSA, and ECDH—the cryptography protecting most certificates today. "Harvest Now, Decrypt Later" attacks make this an urgent concern even before quantum computers arrive.
CNSA 2.0 vs CNSA 1.0
| Aspect | CNSA 1.0 (2016) | CNSA 2.0 (2022+) |
|---|---|---|
| Key Exchange | ECDH P-384, DH 3072-bit | ML-KEM-1024 |
| Digital Signatures | ECDSA P-384, RSA 3072-bit | ML-DSA-87, LMS, XMSS |
| Symmetric Encryption | AES-256 | AES-256 (unchanged) |
| Hash Functions | SHA-384 | SHA-384, SHA-512 |
| Quantum Resistance | No | Yes |
Critical: CNSA 1.0 algorithms (RSA, ECDSA, ECDH) are being phased out. Do not deploy new CNSA 1.0-only systems. All new systems should plan for CNSA 2.0 or hybrid approaches.
CNSA 2.0 Algorithm Suite
Approved Algorithms
| Algorithm | Purpose | Standard | Notes |
|---|---|---|---|
| AES-256 | Symmetric Encryption | FIPS 197 | Block cipher for data protection |
| ML-DSA-87 | Digital Signatures | FIPS 204 | Formerly CRYSTALS-Dilithium |
| ML-KEM-1024 | Key Encapsulation | FIPS 203 | Formerly CRYSTALS-Kyber |
| SHA-384 | Hash Function | FIPS 180-4 | General-purpose hashing |
| SHA-512 | Hash Function | FIPS 180-4 | Higher security margin |
| LMS | Stateful Hash-Based Signatures | SP 800-208 | For firmware/software signing |
| XMSS | Stateful Hash-Based Signatures | SP 800-208 | For firmware/software signing |
Explicitly NOT Approved for CNSA 2.0
| Algorithm | Reason |
|---|---|
| SLH-DSA (SPHINCS+) | Signature sizes too large for NSS use cases |
| HSS | Multi-tree variant not included in CNSA 2.0 suite |
| XMSS^MT | Multi-tree variant not included |
| SHA-3 | SHA-2 preferred; SHA-3 not required |
| RSA | Vulnerable to quantum attacks (Shor's algorithm) |
| ECDSA/ECDH | Vulnerable to quantum attacks |
Note on SLH-DSA (SPHINCS+): While NIST standardized SLH-DSA in FIPS 205, the NSA did not include it in CNSA 2.0 due to large signature sizes. Organizations outside NSS scope may still consider it for specific use cases.
Transition Timeline by Category
The NSA has defined different transition timelines based on system category. Each category has a "prefer" date (when you should start using CNSA 2.0) and an "exclusive" date (when CNSA 1.0 is no longer acceptable).
Software/Firmware Signing
Code signing for software and firmware updates
Web Browsers/Cloud/Servers
TLS for public websites, internal APIs, and cloud control planes
Traditional Networking
VPNs, routers, switches, network equipment
Operating Systems
OS-level PKI, kernel signing, secure boot
Visual Timeline
Certificate-Specific Requirements
CA Hierarchy Transitions
Root CA Considerations
- New PQC Root CAs will need to be established
- Cross-signing with classical roots during transition
- HSMs must support ML-DSA key generation
Issuing CA Transitions
- Hybrid certificates (dual signatures) for interoperability
- Gradual rollout by certificate type/criticality
- CRL/OCSP infrastructure updates required
X.509 Profile Changes
| Field | CNSA 1.0 | CNSA 2.0 |
|---|---|---|
| Signature Algorithm | ecdsa-with-SHA384 | id-ML-DSA-87 |
| Subject Public Key | EC P-384 | ML-DSA-87 / ML-KEM-1024 |
| Key Size Impact | ~96 bytes (EC pubkey) | ~2.5 KB (ML-DSA-87 pubkey) |
| Signature Size Impact | ~96 bytes | ~4.6 KB (ML-DSA-87) |
Certificate Size Warning: PQC certificates are significantly larger than classical certificates. Test TLS handshake performance, especially for constrained devices and high-volume endpoints.
Certificate Validity Considerations
Given the transition timeline, carefully consider certificate validity periods. For long-lived and high-assurance use cases, prefer hybrid (classical+PQC) certificates during the transition to maintain backward compatibility while gaining quantum resistance.
- Short-lived certs (90 days - 1 year): Easier to transition—will naturally age out
- Long-lived certs (5+ years): Issue hybrid certs now or plan mid-life re-issuance
- Code signing certs: Timestamp services must also transition to PQC
CNSA 2.0 → CLM Controls Mapping
Map CNSA 2.0 requirements to your Certificate Lifecycle Management controls and processes.
| CNSA 2.0 Requirement | CLM Implementation | Resource |
|---|---|---|
| Algorithm inventory | Discover all certs, flag non-PQC algorithms | Certificate Discovery Guide |
| Transition planning | Certificate expiry aligned with transition dates | Certificate Lifecycle Guide |
| HSM key protection | PQC-capable HSM procurement/upgrade | HSM Guide |
| Code signing transition | Dual-sign artifacts, update timestamp service | Code Signing Guide |
| Crypto agility | CLM platform supports multiple algorithm types | Crypto Agility Guide |
| Vendor/CA assessment | Evaluate CA PQC roadmaps, multi-CA strategy | CA Hierarchy Guide |
Stateful Hash-Based Signatures (LMS/XMSS)
Critical Warning: LMS and XMSS are stateful signature schemes. Reusing a one-time signature key compromises the entire private key. This requires specialized key management infrastructure.
What Makes Them Stateful?
LMS and XMSS pre-generate a finite tree of one-time signature keys. Each signature "consumes" a leaf of the tree. The signer must track which leaves have been used and never reuse a leaf.
Appropriate Use Cases
- Firmware/software signing (predictable, low-volume)
- Root CA certificates (rare signing events)
- Long-lived code signing with HSM state management
NOT Appropriate For
- TLS server certificates (high-volume handshakes)
- Client authentication (many signing operations)
- Any use case without reliable state persistence
Key Management Requirements
- Persistent state storage: State must survive reboots, failovers, and disasters
- Atomic operations: State update and signature must be atomic to prevent reuse
- HSM support: Use HSMs with native LMS/XMSS support for state management
- No parallelism: Cannot safely sign in parallel without partitioning the key tree
Recommended Approach: Use ML-DSA-87 for most certificate signing needs. Reserve LMS/XMSS for specific use cases (firmware signing, Root CA) where you have proper state management infrastructure.
Implementation Checklist
1Assessment Phase (Now)
- Complete cryptographic inventory (all certificates, keys, algorithms in use)
- Identify systems processing NSS or sensitive data
- Assess HSM fleet PQC readiness
- Document certificate validity periods vs. transition dates
- Evaluate CLM platform PQC support roadmap
2Planning Phase (2025)
- Develop PQC transition roadmap with milestones
- Budget for HSM upgrades/replacements
- Engage CA vendors on PQC certificate availability
- Plan hybrid certificate strategy for interoperability
- Test PQC algorithms in lab environment
3Software Signing Priority (2025-2026)
- Deploy LMS/XMSS signing infrastructure with state management
- Update build pipelines for dual-signing
- Transition timestamp services to PQC
- Verify firmware update verification supports new algorithms
4Network & Systems (2026-2030)
- Deploy PQC-capable network equipment
- Transition VPN infrastructure to ML-KEM
- Update TLS configurations for PQC cipher suites
- Complete CA hierarchy transition to ML-DSA
- Retire classical-only certificate infrastructure
Cross-References & Resources
FixMyCert Guides
Next Steps
Ready to start your CNSA 2.0 transition? Begin with these actionable steps: