Quantum Threats to PKI &
How to Prepare Now
Cryptographically relevant quantum computers will break RSA and ECC — the algorithms underpinning virtually all enterprise PKI today. NIST finalized four post-quantum standards in 2024. The migration window is open. Here is what you need to know.
Why Quantum Threatens PKI
"Harvest Now, Decrypt Later"
CriticalNation-state actors are collecting encrypted traffic today with the intent to decrypt it once cryptographically relevant quantum computers exist. Data with long-term sensitivity — classified information, health records, financial data, IP — is at risk even before quantum computers exist.
Long-Lived Certificate Exposure
HighCertificates with 5–10 year lifetimes issued today using RSA or ECDSA may still be valid when quantum computers capable of breaking them become available. Root CA certificates are the highest-risk category.
Code Signing Chain Compromise
HighSoftware signed with RSA/ECDSA today could be retroactively forged once quantum computers can break the signing key. This affects firmware, OS updates, and any software with long deployment lifetimes.
Authentication Credential Theft
MediumCertificate-based authentication credentials (smart cards, client certificates) captured today could be used to forge authentication tokens in a post-quantum world.
The Timeline Question
Most estimates place cryptographically relevant quantum computers (CRQCs) capable of breaking 2048-bit RSA at 10–15 years away. That sounds distant — but PKI migrations at enterprise scale take 5–8 years. The "Harvest Now, Decrypt Later" threat means the risk is present today for any data with long-term sensitivity. NIST, NSA, and CISA all recommend beginning migration planning immediately.
NIST PQC Algorithm Standards
NIST finalized four post-quantum cryptography standards in August 2024. These are the algorithms to build your migration around.
Key Encapsulation
Module Lattice (CRYSTALS-Kyber)
Key Size
800 – 1568 bytes (pub)
Use Case
TLS key exchange, encrypted email, VPN tunnels
Notes
Primary replacement for RSA/ECDH key exchange. Three security levels: ML-KEM-512, ML-KEM-768, ML-KEM-1024.
Digital Signature
Module Lattice (CRYSTALS-Dilithium)
Key Size
1312 – 2592 bytes (pub)
Use Case
Code signing, certificate signatures, document signing
Notes
Primary replacement for RSA and ECDSA signatures. Drop-in for most PKI certificate signing use cases.
Digital Signature
Stateless Hash-Based (SPHINCS+)
Key Size
32 – 64 bytes (pub)
Use Case
Root CA signing, firmware signing, long-lived certificates
Notes
Conservative choice based on hash functions only. Larger signatures but minimal security assumptions. Ideal for root CAs.
Digital Signature
NTRU Lattice (FALCON)
Key Size
897 – 1793 bytes (pub)
Use Case
Constrained devices, IoT certificates, smart cards
Notes
Compact signatures. More complex implementation than ML-DSA — use ML-DSA unless size is a hard constraint.
Key Encapsulation
Code-Based (Hamming Quasi-Cyclic)
Key Size
2249 – 7245 bytes (pub)
Use Case
Backup KEM if lattice assumptions are broken
Notes
NIST selected as backup KEM alongside ML-KEM. Different mathematical basis provides algorithm diversity.
Enterprise PKI Migration Phases
A phased approach that maintains backward compatibility while progressively hardening your cryptographic posture.
Inventory & Cryptographic Discovery
Now — 2025
- Enumerate all certificates in your PKI: root CAs, intermediate CAs, issued end-entity certs
- Identify all RSA and ECC key usages: TLS, code signing, email, authentication, document signing
- Map certificate lifetimes — long-lived certs (5+ years) are highest priority for replacement
- Audit HSMs and crypto libraries for PQC algorithm support
- Identify applications that hardcode RSA/ECC assumptions (key size checks, algorithm OID parsing)
Hybrid Certificate Deployment
2025 — 2027
- Deploy hybrid certificates combining classical (RSA/ECDSA) + PQC (ML-DSA) signatures
- Test PQC algorithm support in TLS stacks: OpenSSL 3.x, BoringSSL, Schannel (Windows)
- Pilot ML-KEM for TLS 1.3 key exchange in non-production environments
- Update HSMs and crypto libraries to support FIPS 203/204/205/206
- Establish PQC-capable subordinate CA for issuing hybrid test certificates
PQC-Primary Infrastructure
2027 — 2029
- Issue PQC-primary certificates for all new end-entity certificates
- Migrate TLS endpoints to ML-KEM key exchange with ML-DSA authentication
- Replace RSA root CA signatures with SLH-DSA (hash-based, conservative choice for roots)
- Update certificate validation code to handle PQC OIDs and larger key/signature sizes
- Retire hybrid certificates as classical algorithm support is phased out
Full PQC Migration Complete
2029 — 2030
- All certificates issued with PQC algorithms only
- Classical algorithm support removed from CA configuration
- HSM key material for RSA/ECC root CAs securely destroyed
- Cryptographic agility framework in place for future algorithm transitions
- Post-migration audit and documentation complete
Why Hybrid Certificates First
A hybrid certificate carries two signatures — one classical (RSA or ECDSA) and one post-quantum (ML-DSA). A system that understands PQC validates the ML-DSA signature. A legacy system that doesn't falls back to the classical signature.
This approach lets you begin deploying PQC-capable certificates immediately without breaking any existing infrastructure. It's the recommended transition strategy from NIST, NSA, and IETF.
The cost is larger certificate sizes — hybrid certs are roughly 2–3× the size of classical-only certs. For most enterprise PKI use cases, this is acceptable. For constrained environments (IoT, smart cards), evaluate FN-DSA (FALCON) for its compact signature size.
Authoritative PQC Resources
Need a PQC Readiness Assessment?
InsecurePlanet offers PKI and cryptographic inventory assessments that identify your current RSA/ECC exposure and produce a prioritized PQC migration roadmap specific to your environment.