The Government Clock Is Ticking
The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) is the most concrete post-quantum cryptography mandate in the world. Released to guide the transition of National Security Systems (NSS) to quantum-resistant algorithms, CNSA 2.0 sets hard deadlines that begin in 2025 and extend through 2030.
While CNSA 2.0 formally applies to NSS — systems that handle classified information — its impact extends far beyond the defense and intelligence community. Federal contractors, regulated industries, and eventually the broader enterprise will face PQC requirements driven by CNSA 2.0's timeline.
If you're waiting for a clear signal to start PQC migration planning, this is it.
CNSA 2.0 Requirements
The Algorithm Suite
CNSA 2.0 specifies the post-quantum algorithms that NSS must adopt:
| Use Case | Required Algorithm | NIST Standard |
|---|---|---|
| Key Establishment | ML-KEM (Kyber) | FIPS 203 |
| Digital Signatures | ML-DSA (Dilithium) | FIPS 204 |
| Hash-based Signatures | LMS/XMSS | SP 800-208 |
| Symmetric Encryption | AES-256 | FIPS 197 |
| Hashing | SHA-384/SHA-512 | FIPS 180-4 |
The Timeline
CNSA 2.0 establishes a phased migration timeline:
┌──────────────────────────────────────────────────────────────┐
│ CNSA 2.0 Migration Timeline │
├──────────────────┬───────────────────────────────────────────┤
│ Capability │ Requirement │
├──────────────────┼───────────────────────────────────────────┤
│ Software/firmware│ Prefer ML-DSA or LMS/XMSS for │
│ signing │ signing immediately │
├──────────────────┼───────────────────────────────────────────┤
│ Web browsers & │ Support ML-KEM key exchange │
│ servers (TLS) │ by 2025; require by 2027 │
├──────────────────┼───────────────────────────────────────────┤
│ VPN & network │ Support ML-KEM + ML-DSA │
│ equipment │ by 2026; require by 2028 │
├──────────────────┼───────────────────────────────────────────┤
│ Operating systems│ Native PQC support │
│ & infrastructure │ by 2027 │
├──────────────────┼───────────────────────────────────────────┤
│ Legacy systems │ Complete PQC migration or │
│ & custom apps │ plan replacement by 2030 │
├──────────────────┼───────────────────────────────────────────┤
│ All NSS │ Exclusive use of CNSA 2.0 │
│ │ algorithms by 2033 │
└──────────────────┴───────────────────────────────────────────┘
What "Require by 2027" Means
Starting January 2027, TLS connections for National Security Systems must support ML-KEM for key exchange. This means:
- Web servers serving NSS must be configured for PQC key exchange
- TLS libraries must support ML-KEM (Kyber) parameters
- Network equipment must handle larger PQC handshake sizes
- Certificate infrastructure must be prepared for PQC certificates
The Compliance Cascade
From NSS to Everyone
CNSA 2.0 directly applies to NSS, but its influence cascades through the entire technology ecosystem:
Tier 1: National Security Systems (2025-2030)
- Classified government systems
- Intelligence community infrastructure
- Military communications
- Direct CNSA 2.0 compliance required
Tier 2: Federal Government (2026-2031)
- FedRAMP-authorized cloud services
- Government-wide information systems
- Federal contractor infrastructure
- NIST guidance will follow CNSA 2.0 patterns
Tier 3: Defense Industrial Base (2027-2032)
- CMMC (Cybersecurity Maturity Model Certification) will incorporate PQC
- DIB companies handling CUI (Controlled Unclassified Information)
- Supply chain partners to defense contractors
- Contract requirements will mandate PQC
Tier 4: Regulated Industries (2028-2033)
- Financial services (PCI DSS, SOX)
- Healthcare (HIPAA)
- Critical infrastructure (NERC CIP)
- Regulatory bodies will follow government lead
Tier 5: General Enterprise (2029-2035)
- Driven by vendor defaults (cloud providers, OS vendors)
- Insurance requirements
- Customer and partner expectations
- Industry best practices
The Timeline for You
Even if you're not in the defense sector, this timeline affects you:
2026: Browser and server vendors enable PQC by default
→ Your infrastructure must handle PQC connections
2027: Federal contractors begin PQC requirements
→ If you sell to government, you need PQC readiness
2028: Cloud providers default to PQC for new services
→ Your applications must work with PQC
2029: Compliance frameworks incorporate PQC requirements
→ Auditors ask about your PQC migration plan
2030: PQC becomes the expected standard
→ Classical-only cryptography is a finding
Your PQC Migration Plan
Phase 1: Cryptographic Discovery (Start Now)
Before you can migrate, you must know what you have. Conduct a comprehensive cryptographic inventory:
What to Inventory
cryptographic_inventory: certificates: - type: tls attributes: [algorithm, key_size, signature_algorithm, expiry] - type: code_signing attributes: [algorithm, key_size, issuing_ca] - type: client_auth attributes: [algorithm, key_size, purpose] keys: - type: ssh attributes: [algorithm, key_size, age, location] - type: encryption attributes: [algorithm, key_size, purpose, data_sensitivity] - type: signing attributes: [algorithm, key_size, purpose] protocols: - type: tls attributes: [version, cipher_suites, key_exchange] - type: ipsec_vpn attributes: [ike_version, dh_groups, encryption] - type: ssh attributes: [version, key_exchange, mac_algorithms] applications: - attributes: [crypto_libraries, hardcoded_algorithms, api_dependencies]
Tools for Discovery
- CLM platforms (TigerTrust) for certificate and key inventory
- Network scanners for TLS configuration analysis
- Code scanning for hardcoded cryptographic parameters
- Configuration management tools for infrastructure-wide audit
Phase 2: Risk Assessment (Q2 2026)
Not all cryptographic assets need to migrate simultaneously. Prioritize based on:
Data Sensitivity × Exposure Timeline
| Data Sensitivity | Long-lived Data (10+ years) | Medium-lived (2-10 years) | Short-lived (< 2 years) |
|---|---|---|---|
| Top Secret/Critical | Migrate immediately | Migrate by 2027 | Migrate by 2028 |
| Confidential/High | Migrate by 2027 | Migrate by 2028 | Migrate by 2029 |
| Internal/Medium | Migrate by 2028 | Migrate by 2029 | Migrate by 2030 |
| Public/Low | Migrate by 2029 | Migrate by 2030 | As convenient |
Harvest Now, Decrypt Later Exposure
For data in transit, assess the "harvest now, decrypt later" risk:
- Is the data sensitive enough that an adversary would store it?
- Will the data still be valuable in 10-15 years?
- Is the data transmitted over networks that adversaries can monitor?
If yes to all three, prioritize PQC for that data channel immediately.
Phase 3: Infrastructure Preparation (Q3-Q4 2026)
Update Cryptographic Libraries
Ensure your infrastructure supports PQC algorithms:
library_requirements: openssl: ">= 3.2" # PQC support via oqs-provider boringssl: "latest" # Google's PQC-enabled TLS nss: ">= 3.97" # Mozilla's PQC support go_crypto: ">= go1.23" # Experimental PQC rustls: ">= 0.23" # PQC key exchange support
Test PQC Compatibility
Run compatibility tests across your infrastructure:
- Enable hybrid PQC key exchange on test servers
- Verify all clients can negotiate PQC connections
- Check for middlebox interference (firewalls, proxies, IDS/IPS)
- Measure performance impact of PQC handshakes
- Validate certificate chain processing with larger PQC certificates
Address Performance Considerations
PQC algorithms have different performance characteristics:
| Algorithm | Key Size | Signature Size | Speed vs. ECDSA |
|---|---|---|---|
| ML-DSA-65 (Dilithium3) | 1,952 bytes | 3,293 bytes | ~2x slower signing |
| ML-KEM-768 (Kyber768) | 1,184 bytes | 1,088 bytes | Comparable to X25519 |
| SLH-DSA-128 (SPHINCS+) | 32 bytes | 7,856 bytes | ~100x slower signing |
Larger key and signature sizes affect:
- TLS handshake latency (especially on mobile/IoT)
- Certificate chain size
- OCSP response size
- Network bandwidth for certificate-heavy operations
Phase 4: Hybrid Migration (2027)
Deploy hybrid cryptography — using both classical and PQC algorithms simultaneously:
Hybrid TLS Configuration
# NGINX with hybrid PQC key exchange ssl_ecdh_curve X25519Kyber768:X25519:P-256; # When PQC certificates are available (2027+): # Use hybrid certificate with both ECDSA and ML-DSA signatures ssl_certificate /path/to/hybrid-cert.pem; ssl_certificate_key /path/to/hybrid-key.pem;
Why Hybrid First
Hybrid mode provides:
- Protection against quantum attacks (via PQC algorithm)
- Protection against PQC algorithm flaws (via classical algorithm)
- Backward compatibility with clients that don't support PQC
- Graceful migration path with no big-bang cutover
Phase 5: Full PQC Migration (2028-2030)
Once PQC algorithms are widely deployed and proven:
- Transition from hybrid to PQC-only where appropriate
- Remove classical algorithm dependencies
- Update policies to require PQC algorithms
- Verify compliance with applicable regulations
CLM's Role in PQC Migration
Why Your CLM Platform Is Central
Certificate lifecycle management platforms are uniquely positioned to drive PQC migration because they:
- Already know your certificates: The cryptographic inventory starts with your certificate inventory
- Control certificate issuance: Can enforce PQC algorithm requirements through policy
- Automate rotation: Can migrate certificates to PQC algorithms through normal renewal cycles
- Provide visibility: Dashboard showing PQC migration progress across the organization
The 47-Day Advantage
Short-lived certificates (47 days by March 2029) make PQC migration almost effortless:
Manual annual renewal PQC migration:
→ Must coordinate a massive certificate replacement campaign
→ 10,000 certificates = 10,000 coordinated changes
→ High risk of outages during migration
Automated 47-day renewal PQC migration:
→ Update the renewal policy to request PQC certificates
→ Wait 47 days
→ Every certificate has naturally rotated to PQC
→ Zero coordination, zero downtime
Organizations that resist certificate automation will face PQC migration as a separate, painful project. Organizations with automated certificate lifecycle management will barely notice the transition.
How TigerTrust Enables PQC Migration
TigerTrust provides the tools for every phase of PQC migration:
- Cryptographic inventory: Complete visibility into every algorithm, key size, and certificate type
- Risk assessment: Identify high-priority assets for early PQC migration
- Policy enforcement: Configure algorithm requirements that automatically apply to new and renewed certificates
- Migration tracking: Dashboard showing PQC migration progress across your certificate portfolio
- Automated rotation: Migrate to PQC algorithms through normal certificate renewal — no manual intervention
The quantum clock is ticking. Start your PQC migration planning at tigertrust.io.