Post-Quantum Cryptography Timeline & Mandates: Why the Clock Is Ticking

Part of the Post-Quantum PKI Migration Guide

Executive Summary: Federal mandates—NSM-10, NSA's CNSA 2.0, and Executive Order 14144—require government agencies and contractors to complete post-quantum cryptography (PQC) migration by 2030-2035. NIST finalized quantum-safe algorithm standards in August 2024, making implementation requirements concrete. The "harvest now, decrypt later" threat means adversaries are already collecting encrypted data to decrypt once quantum computers exist—making data with long confidentiality requirements vulnerable today. Starting planning now is mandatory for regulated industries; recommended for everyone else.

For Decision Makers: Why This Matters Now

The Quantum Threat Is Real

Quantum computers capable of breaking current encryption (RSA, ECC) don't exist yet—but that's not the relevant question. The relevant question: Will quantum computers exist before your encrypted data loses value? Planning your PQC transition now determines whether you respond on your terms—or scramble to meet a compliance deadline.

For most organizations: Email from 2024 has no value in 2040. Customer transactions from today are irrelevant in 2045. Current encryption (RSA-2048, ECC-256) is sufficient.

For some organizations: Healthcare records must remain confidential for 50+ years. Financial transactions create legal liability decades later. Government secrets have multi-generational confidentiality requirements.

The "Harvest Now, Decrypt Later" threat: Adversaries are collecting encrypted traffic today, storing it, and plan to decrypt it once quantum computers become available (estimated 2030-2032). A 2025 study by Sectigo and Omdia found 60% of organisations now view this threat with extreme concern. If your data has value beyond 2030, it's vulnerable today. See Harvest Now, Decrypt Later for detailed analysis of this threat and why your 2015 data will be public by 2032 unless you act now.

Federal Mandates Create Hard Deadlines

Three overlapping federal directives establish the PQC migration mandate:

• NSM-10 (National Security Memorandum 10, May 2022): Requires all federal agencies to begin PQC migration, submit annual inventories of quantum-vulnerable systems, and mitigate most quantum risk by 2035
• OMB M-23-02: Mandates annual inventories of quantum-vulnerable systems through 2035, prioritised by High-Value Assets
• Executive Order 14144: Maintains PQC urgency under the current administration, requires TLS 1.3 (or successor) across all federal systems by January 2, 2030, and delegates oversight to NSA and OMB
• Quantum Cybersecurity Preparedness Act: Requires inventories and preparation of PQC migrations; OMB must issue guidance within one year of NIST final standards

Together, these directives create a phased migration timeline:

2025: Inventory Complete

• All federal agencies must complete inventory of cryptographic systems (per OMB M-23-02)
• Identify systems using vulnerable algorithms (RSA, DSA, ECDSA, DH, ECDH)
• Assessment of migration complexity and dependencies
• NSA stops approving new NSS systems using RSA, DH, and ECC for key establishment

2027: Migration Begins (CNSA 2.0 Acquisition Deadline)

• All new NSS acquisitions must be CNSA 2.0 compliant by January 1, 2027
• Federal agencies begin deploying post-quantum algorithms
• Priority: Systems handling classified or sensitive data
• Government contractors must support hybrid certificates

2030: Classified Systems Complete

• All NSS networks must exclusively use CNSA 2.0 algorithms
• EO 14144 requires TLS 1.3 (or successor) across all federal systems by January 2, 2030
• Hybrid mode (classical + quantum-safe) acceptable during transition
• Classical-only algorithms prohibited for new deployments

2035: Full Migration (NSM-10 Ultimate Deadline)

• All federal systems fully migrated, including legacy infrastructure
• Classical algorithms completely phased out
• CNSA 2.0 custom applications and legacy equipment deadline: 2033
• Quantum-safe (quantum-resistant) cryptography becomes default for all government PKI

CNSA 2.0 Timeline & Requirements

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0), released by the NSA in September 2022, is the most operationally specific of the federal mandates. It replaces CNSA 1.0 and sets clear deadlines for phasing out RSA, Diffie-Hellman, and ECC across National Security Systems. Unlike the broader NSM-10 directive, CNSA 2.0 specifies exactly which system types must transition and when.

CNSA 2.0 technology-specific milestones:

Key CNSA 2.0 details:

• Hybrid deployments (classical + quantum-resistant) are permitted during the transition but the goal is pure PQC by the exclusive use dates
• SLH-DSA (SPHINCS+) is not included in CNSA 2.0 and is not approved for NSS use—only ML-KEM (FIPS 203) and ML-DSA (FIPS 204), plus LMS/XMSS (SP 800-208) for stateful hash-based signatures
• FN-DSA (Falcon/FIPS 206) is also not yet approved; NIST submitted the draft standard for review in August 2025, with finalisation expected late 2026 or early 2027
• Enforcement mechanism: NSS using any non-approved algorithms requires a waiver specific to the algorithm, implementation, and use case. In practice, failing to meet CNSA 2.0 milestones means losing eligibility for classified system deployments

CNSA 1.0 vs CNSA 2.0: CNSA 1.0 relied on RSA-3072+, ECC P-384, AES-256, and SHA-384 for protecting NSS. CNSA 2.0 replaces all public-key algorithms with quantum-resistant alternatives while retaining AES-256 and SHA-384 for symmetric operations. This is not an incremental update—it's a generational replacement of the cryptographic foundation.

Defense Contractor & Government Supplier Compliance

Defense contractors and suppliers to National Security Systems face the most aggressive PQC timeline in the private sector. This isn't "eventually"—it's a procurement eligibility requirement.

What defense contractors must do and when:

• January 1, 2027: All new NSS acquisitions must be CNSA 2.0 compliant. If your product handles classified data and doesn't support ML-KEM/ML-DSA, it cannot be procured for new deployments
• September 21, 2026: NIST moves all remaining FIPS 140-2 certificates to Historical status. After this date, only FIPS 140-3 validated modules may be used for new federal procurement. FIPS 140-3 validation currently averages over 500 days—vendors not already in the pipeline face a 12–18 month gap
• CSfC program updates: The Commercial Solutions for Classified (CSfC) program is updating Capability Packages to require CNSA 2.0 algorithms. NIAP validation is required for all cryptographic modules in NSS
• By 2030: All NSS network equipment must exclusively use CNSA 2.0. Contractors providing VPN, router, or network infrastructure products need quantum-resistant implementations in production by 2028 at the latest to allow deployment and validation time
• By 2033: All custom applications, legacy equipment, and operating systems must use CNSA 2.0 exclusively

The practical implication: Defense Industrial Base organisations should treat 2027 as a hard deadline for PQC capability, not 2035. Contract officers will increasingly require CNSA 2.0 compliance as an evaluation criterion, and the FIPS 140-3 validation timeline means starting late creates a procurement gap that no amount of urgency can close.

Impact on the broader private sector:

• Government contractors: Must align with CNSA 2.0 timeline (2027-2030)
• Critical infrastructure (16 sectors): Expected regulation 2026-2028
• Financial services: Industry regulations anticipated 2028-2032
• EU: Coordinated PQC roadmap targets transition start by end of 2026, critical infrastructure protection by end of 2030
• Everyone else: No mandates yet, but algorithm transition inevitable

NIST Standards Are Finalized

In August 2024, NIST published final standards for post-quantum cryptography:

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

• Replaces: RSA and Diffie-Hellman for key exchange
• Use case: TLS handshakes, secure key establishment
• Status: Standardized (FIPS 203), implementations shipping

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

• Replaces: RSA and ECDSA for digital signatures
• Use case: TLS certificates, code signing, document signatures
• Status: Standardized (FIPS 204), production deployments available from DigiCert and AWS Private CA

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

• Replaces: RSA/ECDSA in high-security contexts
• Use case: Root CAs, long-term signatures, firmware signing
• Status: Standardized (FIPS 205), conservative fallback option. Not included in CNSA 2.0

What "standardized" means: These are no longer experimental. Commercial PKI vendors are shipping production support. Applications can start testing compatibility. Migration planning can proceed with confidence in algorithm stability.

What it doesn't mean: These algorithms are guaranteed permanent. Cryptanalytic advances could weaken them. New quantum computing developments could accelerate threats. This is why crypto-agility matters more than algorithm choice.

Industry-Specific Timelines

Financial Services

• Expected regulation: 2028-2030 (following federal lead by 3-5 years)
• Driver: Long-term data retention requirements (7-10 years regulatory, 30+ years litigation)
• Early movers: Major banks already running hybrid TLS pilots at the edge in 2026

Healthcare

• Expected regulation: 2028-2032
• Driver: HIPAA confidentiality requirements (50+ year patient record retention)
• Complexity: Medical devices with 10-15 year lifecycles must support PQC

Critical Infrastructure (Energy, Transportation, Communications, etc.)

• Expected regulation: 2026-2028 (CISA coordination with NIST)
• Driver: National security implications of quantum-vulnerable infrastructure
• Challenge: Legacy industrial control systems with 20-30 year operational life
• CISA and NSA must publish a list of quantum-safe product categories by December 1, 2025 (per EO 14144)

Technology & SaaS

• No specific regulation expected
• Driver: Customer requirements (especially government/financial services customers)
• Competitive positioning: "Quantum-safe" as differentiator by 2026-2027
• 47-day certificate lifespan (2029) forces automation that also enables PQC migration

The Real Deadline: Algorithm Agility Infrastructure

Here's what most organizations miss: The deadline that matters isn't "when must we deploy PQC algorithms"—it's "when must we have infrastructure capable of deploying new algorithms quickly."

Why this matters:

If regulatory deadline is 2030 and you start infrastructure work in 2027:

• 2027-2029: Build automation, protocol abstraction, trust management (24 months)
• 2029-2030: Deploy PQC algorithms (12 months)
• Result: Deadline met, but just barely, high stress

If you start infrastructure work in 2025:

• 2025-2027: Build automation at sustainable pace (24 months)
• 2027: Infrastructure ready, can deploy PQC anytime
• 2027-2030: Test thoroughly, gradual rollout, learn from early adopters
• Result: Deadline met comfortably, low risk

The convergence with certificate lifespan reduction: The CA/Browser Forum voted to reduce public SSL/TLS certificate validity to 200 days by March 2026 and 47 days by 2029. Organizations that automate certificate management to handle 47-day renewals are simultaneously building the infrastructure needed for PQC migration—protocol-based enrollment (ACME), centralized trust stores, and lifecycle automation. The investment serves both mandates.

The brutal truth: Organizations that can't renew certificates efficiently today won't be able to migrate to PQC on deadline. The infrastructure work is the long pole, not the algorithm work.

For Engineering Leaders: Planning Your Timeline

Realistic Enterprise Migration Timeline

Based on actual PKI transformations at Fortune 500 organizations:

Phase 1: Assessment & Discovery (6-12 months)

Months 1-3: Certificate Inventory

• Network scanning for active TLS certificates
• Application inventory for embedded certificates
• Code signing and S/MIME certificate discovery
• Typical finding: 3-5x more certificates than initially estimated

Months 4-6: Application Compatibility Assessment

• Test applications against post-quantum certificates (larger sizes)
• Identify legacy systems unable to parse PQC algorithms
• Document dependencies (which apps trust which CAs)
• Create decommission vs. upgrade decision matrix

Months 7-9: Infrastructure Capability Assessment

• Evaluate current certificate enrollment processes (manual vs. automated)
• Assess trust store management (embedded vs. centralized)
• Review monitoring capabilities (can you see what's deployed?)
• Gap analysis: what infrastructure changes needed?

Months 10-12: Strategy & Roadmap Development

• Prioritization: which systems migrate first?
• Vendor selection: which PQC-capable CAs to use?
• Architecture decisions: protocol abstraction vs. vendor-specific
• Budget and resource planning for 3-5 year effort

Phase 2: Infrastructure Modernization (12-18 months)

This is the critical phase most organizations underestimate.

Months 13-18: Protocol Abstraction Deployment

• Deploy certificate enrollment infrastructure (ACME, SCEP, EST endpoints)
• Migrate applications from manual/vendor-specific to protocol-based enrollment
• Test rollback procedures and failure modes
• Train teams on new operational procedures

Months 19-24: Trust Store Centralization

• Build centralized trust store repository
• Migrate applications to fetch roots from central source
• Test trust store update propagation (how fast can you roll out new roots?)
• Implement monitoring: which applications are using which roots?

Months 25-30: Automation & Monitoring

• Certificate lifecycle automation (discovery, renewal, revocation)
• CMDB integration for continuous inventory
• Alerting for non-compliant configurations
• Compliance reporting infrastructure

Phase 3: PQC Algorithm Deployment (12-24 months)

Months 31-36: Hybrid Certificate Testing

• Deploy hybrid certificates (classical + PQC) in test environments
• Application compatibility validation
• Performance testing (PQC signatures are computationally heavier)
• Identify and address compatibility issues

Months 37-48: Production Rollout (Gradual)

• Low-risk systems first (dev/test, internal tools)
• Medium-risk systems (employee-facing applications)
• High-risk systems (customer-facing, revenue-critical)
• Continuous monitoring for issues, quick rollback if needed

Months 49-54: Classical Algorithm Removal

• Transition from hybrid to PQC-only certificates
• Remove classical algorithms from trust chains
• Final compliance validation
• Audit evidence collection

Total Timeline: 42-54 months (3.5-4.5 years) for large enterprises

Can it be faster?

• Organizations with existing automation: 30-36 months possible
• Organizations starting from manual processes: 48-60 months realistic
• Cutting corners creates risk: failed migrations cost more than extended timelines

Critical Path: What Determines Timeline

The gating factors aren't algorithms—they're organizational:

1. Application Migration Velocity (12-24 months)

• How many applications need certificate enrollment changes?
• How quickly can you test and deploy changes?
• Change management overhead for each deployment?

Typical velocity: 20-40 applications per month for large organizations with mature DevOps. 5-10/month for organizations with heavyweight change management.

With 500 applications to migrate: 12-25 months at best.

2. Legacy System Handling (6-18 months)

• Some systems can't support post-quantum (too old, vendor out of business)
• Options: Upgrade, replace, isolate, or accept classical-only risk
• Each decision requires business case, approval, implementation

Financial impact: $500K-$5M in unexpected legacy system upgrades/replacements.

3. Team Training & Expertise (6-12 months)

• Current teams skilled in manual certificate processes
• Need expertise in: ACME protocol, API-based automation, trust store management
• Learning curve for new operational patterns

Underestimating this leads to failed automation attempts and reverting to manual processes.

4. Vendor Dependencies (3-12 months)

• PKI vendor release cycles for PQC support
• Application vendor updates for PQC compatibility
• Hardware vendor firmware updates (load balancers, HSMs, network appliances)
• FIPS 140-3 validation backlog (500+ day average validation time)

You don't control vendor timelines—plan accordingly.

Milestone Planning

Realistic milestones for 2025-2030 timeline:

2025: Foundation Year

• Q1: Complete inventory, identify scope
• Q2: Infrastructure strategy finalized, vendor selection complete
• Q3: Begin protocol abstraction deployment
• Q4: First applications migrated to automated enrollment

2026: Infrastructure Year

• Q1: 25% of applications using protocol-based enrollment. March: 200-day public SSL/TLS certificate lifespan begins
• Q2: 50% migration complete
• Q3: 75% migration complete, centralized trust stores operational. September 21: FIPS 140-2 to Historical (FIPS 140-3 required for new procurement)
• Q4: Infrastructure modernization complete, ready for algorithm deployment

2027: Testing Year

• Q1: Hybrid certificates deployed to test environments. January 1: CNSA 2.0 acquisition deadline for new NSS systems
• Q2: Non-production systems running hybrid certificates
• Q3: Low-risk production systems migrated
• Q4: Medium-risk production systems migrated

2028: Production Year

• Q1: High-risk production systems begin hybrid migration
• Q2: 50% production coverage with hybrid certificates
• Q3: 75% production coverage
• Q4: 90%+ coverage, final holdouts identified

2029: Optimization Year

• Q1: Begin transition from hybrid to PQC-only. 47-day public SSL/TLS certificate lifespan begins
• Q2: Performance optimization, cost reduction
• Q3: Classical algorithm deprecation planning
• Q4: PQC-only deployment to non-critical systems

2030: Completion Year

• Q1: Critical systems migrated to PQC-only. January 2: EO 14144 TLS 1.3 mandate deadline
• Q2: Classical algorithms removed from all but isolated legacy. CNSA 2.0 exclusive use deadline for software/firmware signing and network equipment
• Q3: Compliance validation, audit evidence collection
• Q4: Federal deadline met, migration complete

Technical Deep Dive: Standards & Implementation Status

For teams implementing PQC support

NIST PQC Algorithm Specifications

NIST published three quantum-resistant algorithm standards as Federal Information Processing Standards (FIPS). These are the algorithms your infrastructure must support:

All finalized algorithms represent fundamentally different mathematical foundations from RSA and ECC. Below are the detailed specifications for each.

ML-KEM-768 (Key Encapsulation Mechanism - Recommended Parameter Set) [Formerly CRYSTALS-Kyber]

Use in TLS: Replaces DHE/ECDHE in TLS 1.3 key exchange. Client and server establish shared secret for symmetric encryption.

Deployment consideration: Larger public keys may exceed MTU in some networks, requiring fragmentation. Test with network middleboxes (firewalls, proxies) to ensure compatibility.

ML-DSA-65 (Digital Signature Algorithm - Recommended Parameter Set) [Formerly CRYSTALS-Dilithium]

Use in certificates: This is what impacts your PKI. X.509 certificates use ML-DSA for CA signatures and TLS server certificates.

Deployment consideration: Certificate chains with 3 levels (root → intermediate → leaf) using ML-DSA-65 will be ~12KB instead of ~4KB with RSA. This affects:

• TLS handshake size (more packets, slower on high-latency links)
• Certificate storage (browsers, applications cache certificates)
• OCSP responses (include certificate chain, will be larger)

SLH-DSA-128f (Stateless Hash-Based Signature - Fast Variant)

Use case: Root CAs and long-term signatures where signing performance doesn't matter but conservatism does. SLH-DSA is based on hash functions (SHA-256), which are extremely well-understood. If lattice-based cryptography (ML-DSA) is broken by cryptanalytic advance, SLH-DSA provides fallback.

Important note: SLH-DSA is not included in CNSA 2.0 and is not approved for NSS use. For National Security Systems, use ML-DSA for signatures and LMS/XMSS (SP 800-208) for stateful hash-based signing.

Deployment consideration: 17KB signatures are impractical for TLS (would break many systems). Use for offline signatures only: root CA certificates, code signing, document signing.

Hybrid Certificate Formats

During transition, organizations deploy hybrid certificates containing both classical and post-quantum algorithms. This ensures compatibility with legacy systems while providing quantum-safe protection. CNSA 2.0 permits hybrid deployments during the transition period.

X.509 Hybrid Certificate Extension:

Total hybrid certificate size: ~8-10KB (vs. ~2KB for RSA-only)

Verification process: Application must verify BOTH signatures. Certificate is valid only if:

1. Classical signature validates correctly
2. Post-quantum signature validates correctly
3. Both signatures cover same certificate content

Compatibility strategy:

• Legacy applications: Verify classical signature only, ignore PQC (graceful degradation)
• Modern applications: Verify both signatures, reject if either fails
• Quantum-safe only: Some applications may choose to reject if PQC signature missing

Deployment timeline:

• 2025-2027: Deploy hybrid certificate capability
• 2027-2030: Transition applications to hybrid certificates
• 2030-2033: Remove classical signatures, PQC-only
• 2033+: Classical algorithms fully deprecated

Commercial PKI Vendor Support

Status as of March 2026:

DigiCert

• ML-DSA/SLH-DSA: GA for private certificates via Private CA and Trust Lifecycle Manager
• Enrollment methods: CSR, EST, REST API
• HSM support: Crypto4A (FIPS 140-validated, PQC-native) and Thales SafeNet Luna (firmware 7.9+)
• Public CA certificates (CertCentral): Not yet available—pending CA/Browser Forum standards for PQC OIDs in public certificates (expected late 2025/early 2026 as RFCs)
• PQC Labs sandbox: Available for free testing
• TrustCore SDK: Supports ML-KEM, ML-DSA, TLS 1.3, FIPS 140-3
• OCSP for ML-DSA: Not yet supported (RFC not yet defined)

Sectigo

• Sectigo PQC Labs: GA (launched February 2025), powered by Crypto4A quantum-safe HSMs
• PQC Labs supports: Pure PQC certificate issuance in sandbox, ML-DSA and ML-KEM testing
• Production PQC via Sectigo Certificate Manager: In development, targeting 2026
• QUANT strategy framework: Quantum-resistant, Uncover, Assess, Navigate, Track
• Focus: Crypto-agility and certificate lifecycle management as foundation for PQC

GlobalSign

• PQC research: Active, with published analysis of PQC certificate structures
• Production PQC certificates: Not yet available
• Industry position: Focused on pure PQC certificates (not hybrid), aligning with CA/Browser Forum direction
• Timeline: Dependent on IETF/CA Browser Forum standardisation of PQC OIDs for public certificates (expected formal definitions by end of 2026)

Microsoft AD CS

• PQC support: No official timeline announced
• Hybrid certificates: No public roadmap
• Assessment: Likely 2027+ based on CNSA 2.0 operating system deadline

AWS Private CA

• ML-DSA support: GA (launched November 2025)
• Capabilities: Full CA hierarchy, certificate issuance, CRL, and OCSP using ML-DSA
• Availability: All commercial AWS Regions, GovCloud, and China Regions
• Integration: AWS KMS supports ML-DSA key management for code signing, mTLS, and IAM Roles Anywhere

Google Certificate Authority Service

• PQC support: No official announcement for CA Service
• Chrome: ML-KEM key exchange already deployed for TLS (since late 2024)
• PQC certificate authentication: Following IETF/CA Browser Forum standardisation

Open Source (OpenSSL, BoringSSL)

• OpenSSL 3.5.0+: ML-DSA key generation and CSR creation supported
• OQS (Open Quantum Safe) provider: ML-KEM, ML-DSA implementations available
• BoringSSL: ML-KEM used in Chrome/Android TLS key exchange
• Production-grade FIPS-validated PQC modules: Still limited; FIPS 140-3 validation backlog remains a bottleneck

Reality check: Even with vendors shipping PQC support, expect:

• Public TLS certificate issuance with PQC algorithms blocked until CA/Browser Forum baseline requirements are updated (expected 2026-2027)
• Client library updates lagging server support
• FIPS 140-3 validated PQC implementations remaining scarce until 2027+
• Documentation and interoperability gaps requiring trial-and-error

Private PKI (internal certificates) can adopt PQC now. Public PKI must wait for standards body alignment.

Performance Impact Assessment

Certificate chain size impact (TLS handshake):

Impact on TLS handshake:

CPU impact (signature verification):

Counterintuitive result: Post-quantum signatures verify FASTER than RSA on most hardware. The larger certificate size is offset by faster verification.

Real bottleneck: Network transmission, not CPU. Organizations with high-latency connections (satellite, remote offices) should test hybrid certificates early.

Compatibility Testing Checklist

Before production deployment, test PQC certificates against:

TLS Clients:

• [ ] Web browsers (Chrome, Firefox, Safari, Edge)
• [ ] Mobile browsers (iOS Safari, Android Chrome)
• [ ] CLI tools (curl, wget, openssl s_client)
• [ ] Programming language libraries (Python requests, Java HttpClient, Go net/http)
• [ ] Legacy clients (IE11, old Android/iOS versions)

Network Middleboxes:

• [ ] Firewalls (inspect-and-decrypt TLS)
• [ ] Proxies (corporate web filtering)
• [ ] Load balancers (TLS termination)
• [ ] WAF (Web Application Firewalls)
• [ ] DDoS mitigation (Cloudflare, Akamai)

Certificate Validation:

• [ ] OCSP responders (can they sign responses with PQC?)
• [ ] CRL distribution (do PQC CRLs exceed size limits?)
• [ ] Certificate Transparency logs (do they support PQC?)
• [ ] Trust store management (can systems load larger certificates?)

Application-Specific:

• [ ] Email clients (S/MIME with PQC)
• [ ] Code signing tools (can they verify PQC signatures?)
• [ ] VPN clients (certificate-based authentication)
• [ ] IoT devices (can they parse larger certificates?)

Common failure modes discovered during testing:

• Network appliances with hardcoded 4KB certificate buffer (crash on 15KB hybrid cert)
• OCSP responders exceeding HTTP header size limits with large signatures
• Mobile apps with aggressive timeouts failing on slower PQC handshakes
• Legacy Java applications unable to parse unknown signature algorithms
• TPM 2.0 modules lacking ML-DSA support (TCG specification as of March 2024 does not include ML-DSA)

Testing strategy: Start with non-critical systems (internal tools, dev environments) and gradually expand. Maintain classical-only fallback for quick rollback.

Common Questions

"When will quantum computers actually break RSA?"

Honest answer: We don't know. Estimates range from 2035 to "never."

NIST's working assumption: 10-15 years (2035-2040) for quantum computers capable of breaking RSA-2048 in practical timeframes (hours to days). But:

Optimistic scenario: Breakthrough in quantum error correction could accelerate timeline to 2030-2032.

Pessimistic scenario: Fundamental physics limitations may prevent large-scale quantum computers from ever being practical.

Risk management perspective: If there's 20% chance of 2035 and 80% chance of "never," is that acceptable risk? Depends on:

• Value of data being protected
• Cost of migration vs. cost of breach
• Regulatory requirements (NSM-10, CNSA 2.0 don't care about probability—they set deadlines)

For most organizations: PQC migration is driven by mandates, not imminent quantum threat.

"Can we just wait for better algorithms?"

What "better" means:

• Smaller signatures (FN-DSA/FIPS 206 offers smaller sigs than ML-DSA, expected late 2026/early 2027)
• Faster operations (ML-DSA is already fast enough)
• Higher security levels (ML-DSA-87 exists for extra paranoia)
• Different security assumptions (alternatives to lattice-based crypto)

Will better algorithms appear? Probably yes, over next 10-20 years.

Does waiting make sense? No, because:

• Federal/industry mandates don't wait for perfect algorithms
• Building crypto-agility infrastructure takes 2-3 years regardless
• With crypto-agility, switching to "better" algorithms is easy later

Strategy: Build infrastructure now (protocol abstraction, automation, monitoring). Deploy NIST algorithms to meet compliance. Switch to "better" algorithms when available—which will be trivial if you built crypto-agility.

"What about quantum key distribution (QKD)?"

What it is: Use quantum mechanics properties to establish encryption keys with provable security against quantum computers.

Why it's not relevant for most organizations:

• Requires specialized fiber optic infrastructure (can't go over internet)
• Range limited to ~100km without quantum repeaters (which don't exist yet)
• Extremely expensive ($500K+ per link)
• Doesn't solve authentication problem (still need digital signatures)

Where it might be used:

• Government/military secure facilities
• High-security data centers
• Bank-to-bank private connections

For everyone else: PQC algorithms (ML-KEM for key exchange, ML-DSA for signatures) are the practical solution.

"Do we need PQC for internal certificates?"

Depends on threat model:

Public-facing TLS certificates: Yes, because:

• Adversaries can intercept traffic and store it
• "Harvest now, decrypt later" threat applies
• Compliance requirements will mandate it

Internal certificates (intranet, private networks): Maybe, because:

• If adversary has network access to intercept internal traffic, you have bigger problems
• But: insider threat exists, contractors/vendors may have access
• Regulatory requirements may not distinguish internal vs. external

Device certificates (IoT, client authentication): Depends, because:

• Long-lived devices (10+ year lifecycle) should use PQC
• Short-lived devices (<5 years) may not need immediate PQC

Code signing certificates: Yes, because:

• Signed code may be used for decades
• Breaking signature allows malware insertion
• CNSA 2.0 prioritises software/firmware signing as the earliest transition target

S/MIME email certificates: Depends, because:

• Email archives may be stored indefinitely
• But most email has short-term confidentiality requirements
• High-security organizations should use PQC

Risk-based approach: Prioritize PQC for certificates protecting long-term confidentiality or high-value targets. Internal, short-lived certificates can wait.

Getting Started

Immediate Actions (Next 30 Days)

1. Determine regulatory applicability
   • Are you subject to federal mandates? (Government contractor, critical infrastructure, defense industrial base)
   • Do CNSA 2.0 deadlines apply? (Any product sold to NSS must be compliant by January 2027)
   • What's your industry's expected timeline? (Financial 2028-2030, Healthcare 2028-2032)
   • Do you handle data with long confidentiality requirements?
2. Complete initial inventory
   • Scan public-facing TLS certificates (use SSL Labs, crt.sh, or network scanners)
   • Identify certificate-issuing authorities (how many CAs are you using?)
   • Estimate certificate count (start with low-hanging fruit: TLS, code signing)
3. Assess current automation level
   • How are certificates requested today? (Manual web forms, API, or protocols)
   • How are trust stores managed? (Embedded in apps, OS-level, or centralized)
   • Do you have certificate monitoring? (Expiration alerts, compliance checks)
   • Are you ready for 200-day certificate lifespans (March 2026)?

90-Day Planning Objectives

1. Complete crypto-agility assessment
2. Develop 3-5 year roadmap with realistic milestones aligned to CNSA 2.0 dates
3. Build business case for infrastructure investment ($800K-$2.5M for large enterprises)
4. Begin vendor discussions about PQC support timelines and FIPS 140-3 validation status

Long-Term Success Criteria

2025-2026: Infrastructure foundation

• Protocol-based enrollment operational (ACME, SCEP, EST)
• Certificate discovery and monitoring implemented
• Team trained on automation procedures
• 200-day certificate lifecycle managed via automation

2027-2028: Algorithm deployment capability

• Hybrid certificates tested and validated
• Application compatibility issues identified and resolved
• Compliance reporting infrastructure operational
• CNSA 2.0 acquisition compliance demonstrated (if applicable)

2029-2030: Production migration

• Federal deadline met (if applicable)
• Industry regulations satisfied
• Classical algorithms deprecated
• 47-day certificate lifecycle fully automated

Post-2030: Crypto-agility proven

• Next algorithm change takes weeks, not years
• Infrastructure investment paid off
• Organization ready for ongoing cryptographic evolution

Want Expert Assessment?

We've helped Fortune 500 enterprises and major financial institutions plan PQC migration while building crypto-agile infrastructure that eliminates vendor lock-in.

What we provide:

• Regulatory timeline assessment (NSM-10, CNSA 2.0, EO 14144—which mandates apply to you?)
• Crypto-agility readiness evaluation (can you migrate on deadline?)
• Realistic timeline and budget planning (3-5 year roadmap aligned to federal milestones)
• Infrastructure-first strategy (build automation, then deploy algorithms)

What makes us different:

• Experience from actual implementations (not theoretical)
• Infrastructure focus (algorithm choice is secondary)
• Customer owns everything (3AM deployed in your AWS account)
• Post-quantum ready (hybrid certificate support operational)

Contact us for PQC readiness assessment

We'll tell you honestly whether you need to start now, or if you have time to plan more deliberately.

Related Resources

References

1. National Institute of Standards and Technology. (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard.
2. National Institute of Standards and Technology. (2024). FIPS 204: Module-Lattice-Based Digital Signature Standard.
3. National Institute of Standards and Technology. (2024). FIPS 205: Stateless Hash-Based Digital Signature Standard.
4. National Institute of Standards and Technology. (2020). SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes.
5. The White House. (2022). National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems (NSM-10).
6. National Security Agency. (2022). Commercial National Security Algorithm Suite 2.0 (CNSA 2.0).
7. Office of Management and Budget. (2022). M-23-02: Migrating to Post-Quantum Cryptography.
8. The White House. (2025). Executive Order 14144: Sustaining Select Efforts to Strengthen the Nation's Cybersecurity.
9. Mosca, M. (2018). Cybersecurity in an Era with Quantum Computers. Institute for Quantum Computing.