Post-quantum cryptography (PQC) replaces the RSA and elliptic curve algorithms that quantum computers will eventually break. This guide covers the NIST PQC standards (FIPS 203, 204, 205, 206), the quantum threat timeline, hybrid certificate deployment, and a practical 24-month migration roadmap for enterprise PKI.
Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to resist attacks from both classical and quantum computers. Unlike the RSA and elliptic curve algorithms that underpin today's PKI infrastructure, PQC algorithms are built on mathematical problems that remain hard even for a sufficiently powerful quantum computer running Shor's algorithm.
In 2024, NIST published the first three post-quantum cryptographic standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). A fourth standard, FIPS 206 (FN-DSA), is expected shortly. These standards mark the end of the research phase and the beginning of the deployment phase. Organizations that depend on public key cryptography, which is virtually all of them, now face a concrete migration timeline.
This guide focuses on the PQC standards themselves, their practical implications for enterprise PKI, and the operational steps required to begin migrating. For a broader treatment of the organizational capability needed to swap algorithms at scale, see our companion guide on crypto-agility.
Public key infrastructure relies on the computational difficulty of specific mathematical problems. RSA depends on integer factorization. ECDSA and ECDH depend on the elliptic curve discrete logarithm problem. A sufficiently large quantum computer running Shor's algorithm can solve both problems in polynomial time, rendering every RSA and ECC key breakable.
This is not a theoretical curiosity. It has direct consequences for every digital certificate in your infrastructure:
PQC addresses these threats by replacing the vulnerable mathematical foundations with problems that quantum computers cannot efficiently solve: structured lattices, hash functions, and error-correcting codes.
An attacker with a cryptographically relevant quantum computer (CRQC) could derive the private key from any RSA or ECC certificate, enabling man-in-the-middle attacks against every TLS connection using classical algorithms.
Code signing certificates rely on digital signatures to prove software integrity. If the signature algorithm is broken, previously signed software can no longer be trusted, and an attacker can sign malicious code with a forged key.
If a root CA's private key can be derived, every certificate in the hierarchy becomes untrustworthy. The entire chain of trust must be rebuilt with quantum-resistant algorithms.
Nation-state adversaries are already intercepting and storing encrypted traffic today, intending to decrypt it once quantum computers are available. Data with a long confidentiality requirement, government communications, health records, financial transactions, trade secrets, is already at risk.
After an eight-year evaluation process that began with 82 candidate submissions, NIST has standardized four post-quantum algorithms across three use cases. Understanding these standards is essential for planning your migration.
### FIPS 203: ML-KEM (Module-Lattice-Based Key Encapsulation)
ML-KEM, derived from the CRYSTALS-Kyber submission, is the standard for key encapsulation, the mechanism used to establish shared secrets in protocols like TLS. When a client and server perform a TLS handshake, they use a key encapsulation mechanism (KEM) to agree on a symmetric encryption key. ML-KEM replaces the ECDH key exchange that TLS currently uses.
ML-KEM is defined at three security levels:
The key trade-off with ML-KEM is size. A ML-KEM-768 public key is 1,184 bytes compared to 32 bytes for X25519. This impacts TLS handshake size and, in constrained environments, may affect latency. In practice, for server-to-server and browser-to-server TLS, the overhead is manageable. For IoT devices and embedded systems, it requires careful evaluation.
### FIPS 204: ML-DSA (Module-Lattice-Based Digital Signature Algorithm)
ML-DSA, derived from the CRYSTALS-Dilithium submission, is the primary standard for digital signatures. It replaces RSA and ECDSA for signing certificates, code, documents, and any other data that requires authentication and integrity verification. ML-DSA is the algorithm that will appear in your PQC certificates.
ML-DSA is also defined at three security levels:
For comparison, an RSA-2048 signature is 256 bytes and an ECDSA P-256 signature is 64 bytes. ML-DSA signatures are significantly larger, which affects certificate chain size, CRL size, and OCSP response size. Organizations should model these impacts on their specific infrastructure before deploying.
### FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
SLH-DSA, derived from SPHINCS+, is a hash-based signature scheme. Its security relies solely on the well-understood properties of hash functions, making it a conservative alternative to lattice-based schemes. If a breakthrough were to weaken lattice-based cryptography, SLH-DSA would remain secure.
The trade-off is performance. SLH-DSA signatures range from 7,856 to 49,856 bytes depending on the parameter set, and signing is significantly slower than ML-DSA. SLH-DSA is best suited as a backup algorithm and for use cases where long-term signature validity is paramount, such as root CA certificates and firmware signing.
### FIPS 206: FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm)
FN-DSA, derived from the FALCON submission, is expected to be standardized as FIPS 206. It offers significantly smaller signatures than ML-DSA (approximately 666 bytes at Security Level 1), making it attractive for bandwidth-constrained applications. However, its key generation process is complex and requires careful constant-time implementation to avoid side-channel attacks. FN-DSA will complement ML-DSA rather than replace it, serving use cases where signature compactness is critical.
Targets NIST Security Level 1 (equivalent to AES-128). Smallest key sizes and fastest performance. Suitable for most general-purpose TLS deployments.
Targets NIST Security Level 3 (equivalent to AES-192). The recommended default for enterprise deployments, balancing security margin with acceptable performance overhead.
Targets NIST Security Level 5 (equivalent to AES-256). Largest key sizes but highest security margin. Required by some government and defense use cases.
Estimating when a cryptographically relevant quantum computer will exist is inherently uncertain. However, the risk calculus does not depend on knowing the exact date.
NIST, NSA, and CISA have all issued guidance urging organizations to begin migration planning immediately. The U.S. National Security Memorandum NSM-10 sets a 2035 target for federal agencies to complete PQC migration. The European Union's cybersecurity agency ENISA has issued similar recommendations.
The largest quantum computers have around 1,000 noisy qubits. Running Shor's algorithm against RSA-2048 is estimated to require roughly 4,000 logical qubits, which translates to millions of physical qubits with current error rates. No one can break production cryptography today.
Quantum hardware is advancing rapidly. IBM, Google, and several national programs are targeting error-corrected systems in this timeframe. While breaking RSA-2048 by 2030 remains unlikely, the possibility is no longer dismissed by credible researchers.
Many forecasts converge on this window as the period of highest risk. A 2023 Global Risk Institute survey found that a majority of quantum computing experts now assign a greater-than-50% probability to a CRQC existing by 2035.
Regardless of when a CRQC arrives, data encrypted today with classical algorithms and intercepted by adversaries can be stored indefinitely. If your data must remain confidential for 10 or more years, and your adversary is a nation-state, the migration deadline is not the CRQC arrival date. It is today.
Migrating to PQC is not a one-time key swap. It is an ongoing capability that your infrastructure must support. This capability is called crypto-agility: the ability to discover, evaluate, and replace cryptographic algorithms across your entire estate without rebuilding systems from scratch.
Without crypto-agility, a PQC migration requires touching every system individually, updating configurations by hand, and coordinating changes across teams with no central visibility. With crypto-agility, you maintain a living inventory of every algorithm in use, automate certificate reissuance, and enforce policy centrally.
Key requirements for crypto-agile PQC migration include:
For a detailed treatment of building crypto-agility into your organization, including governance frameworks, tooling requirements, and process design, see the dedicated crypto-agility guide.
Your PKI platform must support issuing certificates with new algorithms without requiring a platform replacement. If your CA can only issue RSA and ECDSA, you will need a new CA for PQC.
You must know where every certificate is deployed and what algorithm it uses. A comprehensive certificate lifecycle management platform is the prerequisite for any migration at scale.
Your hardware security modules must support PQC algorithms. Verify that your HSM vendor's firmware roadmap includes ML-KEM and ML-DSA support, and that upgrades are covered by your maintenance contract.
During the transition, you will need certificates that contain both a classical and a PQC key, ensuring backward compatibility with systems that do not yet support PQC while providing quantum resistance for those that do.
Before deploying any PQC certificate, you need a complete understanding of your current cryptographic posture. This assessment is the foundation of your migration plan.
Use your certificate management platform to scan every environment: cloud infrastructure, on-premises servers, container orchestrators, network appliances, IoT devices, and code signing pipelines. Identify every certificate, every key, and every algorithm in use. Pay special attention to long-lived assets: root CA certificates, document signing keys, and encrypted archives.
Not all assets face the same risk. Prioritize based on two factors: (1) how long the data must remain confidential, and (2) how long the asset will remain in service. A VPN encrypting classified data with a 25-year confidentiality requirement is at immediate risk from harvest-now attacks. A short-lived TLS certificate protecting a public marketing website is lower priority.
For each system, identify which cryptographic operations it performs and which algorithms it supports. Document TLS libraries and versions, cryptographic APIs, HSM firmware versions, and application-layer encryption. This dependency map tells you which systems can adopt PQC today and which require upstream updates first.
PQC migration does not happen in isolation. Your certificates must be accepted by partners, clients, browsers, and third-party systems. Map your certificate trust relationships and identify which counterparties support PQC. Standards bodies like the CA/Browser Forum are developing PQC requirements for publicly trusted certificates, but the timeline for browser trust store adoption is still evolving.
Produce a clear report: total number of assets using classical-only algorithms, broken down by risk tier. This becomes the scope of your migration program and the basis for resource allocation.
Hybrid certificates are the bridge between today's classical PKI and a fully post-quantum infrastructure. A hybrid certificate contains two key pairs: one classical (RSA or ECDSA) and one PQC (ML-DSA). Systems that support PQC validate the PQC signature; systems that do not fall back to the classical signature.
This approach eliminates the need for a hard cutover and allows gradual, low-risk migration.
Start with internal, non-customer-facing services where you control both endpoints. Mutual TLS between microservices, internal API gateways, and development environments are ideal candidates. Avoid starting with public-facing TLS, which depends on browser and client support you do not control.
Your issuing CA must support PQC key types. If your current CA does not, deploy a dedicated PQC-capable issuing CA under your existing root hierarchy. Ensure the CA's HSM firmware supports ML-DSA key generation and signing. Generate the PQC issuing CA key inside the HSM.
Configure your CA to issue certificates containing both an ECDSA and an ML-DSA key. The certificate profile should include both signature algorithms so that relying parties can choose the strongest algorithm they support. Test the certificate chain validation end-to-end.
Monitor the pilot for performance impact. Measure TLS handshake latency (expect 1-3ms increase due to larger key exchange and signatures), certificate chain validation time, bandwidth consumption from larger certificates and CRLs, and application compatibility. Document any issues for remediation before expanding scope.
Based on pilot results, extend PQC hybrid certificates to additional internal services, then to partner-facing integrations where you can coordinate with counterparties, and finally to public-facing services once browser and OS support matures.
A practical PQC migration cannot be completed in a single sprint. The following roadmap provides a structured 24-month plan that balances urgency with operational reality.
Complete the cryptographic inventory and risk assessment described above. Establish a PQC migration working group with representatives from security, infrastructure, development, and compliance. Define your organization's risk tolerance and prioritization criteria. Assess HSM vendor PQC readiness and initiate firmware upgrade plans.
Stand up a PQC test environment with a PQC-capable CA. Generate ML-KEM and ML-DSA key pairs. Issue test certificates and validate them across your technology stack. Identify libraries and applications that need updates to support PQC. Begin testing hybrid TLS handshakes.
Deploy hybrid certificates on selected internal services. Monitor performance and compatibility. Train operations teams on PQC certificate management. Update incident response procedures to account for PQC-specific scenarios. Begin integrating PQC certificate issuance into your automated certificate lifecycle management workflows.
Extend PQC hybrid certificates to additional internal services and partner-facing systems. Coordinate with key partners and vendors on PQC interoperability testing. Migrate high-risk assets identified in your risk assessment (long-lived keys, high-confidentiality data channels). Update compliance documentation and audit procedures.
Establish PQC as the default algorithm for new certificate issuance where endpoints support it. Plan for classical algorithm deprecation timelines. Prepare for public-facing PQC deployment as browser and OS support matures. Document lessons learned and update your crypto-agility processes for the next algorithm transition, because there will be one.
PQC-ready certificate authority — Evertrust PKI supports post-quantum algorithm issuance, enabling you to generate ML-DSA certificates and hybrid certificates from a CA platform designed for algorithm agility.
Complete cryptographic inventory — Evertrust CLM discovers every certificate across your infrastructure and classifies them by algorithm, key size, and issuer, giving you the visibility you need to scope and execute a PQC migration.
Automated lifecycle management at scale — When you are ready to reissue thousands of certificates with PQC algorithms, Evertrust automates the full lifecycle through ACME, EST, SCEP, and CMP, ensuring migration does not become a manual bottleneck.
Policy enforcement for PQC compliance — Define organizational policies that mandate PQC algorithms for new issuance, enforce minimum security levels, and block deprecated classical algorithms, all enforced automatically before certificates are issued.
Hybrid certificate support — Evertrust enables you to issue hybrid certificates that contain both classical and post-quantum key pairs, allowing gradual migration without breaking backward compatibility.
