smartenterprisewisdom Skip to main content

Accutive Security

The Cryptography, Data Protection and Identity Security Center of Excellence

Innovation Lab
Contact Us

Post Quantum Cryptography Migration Tool

PKI · CLM · Crypto-Agility

Migrating to Post-Quantum Cryptography

A practitioner's guide to the why, the NIST-approved what, and a phased how, from cryptographic discovery through hybrid deployment to full cutover.

Quick Translator
I am using, so the PQC alternative would be ___________
 
01 · The Need

Why PQC, and why the clock is already running

A cryptographically relevant quantum computer (CRQC) running Shor's algorithm breaks the integer factorization and discrete logarithm problems that RSA, DH, ECDH, ECDSA, and EdDSA depend on. Grover's algorithm halves the effective strength of symmetric keys and hashes, which is manageable, but the asymmetric layer collapses entirely.

📥

Harvest Now, Decrypt Later

Adversaries are recording encrypted traffic today to decrypt once a CRQC exists. Any data with a confidentiality lifetime beyond the quantum horizon (PII, health, financial, IP, state secrets) is already at risk, which makes key establishment the most urgent migration target.

⏳

Migration Takes a Decade

The SHA-1 to SHA-2 transition took most enterprises 10+ years. PQC touches far more: TLS, PKI hierarchies, HSMs, code signing, VPNs, SSH, S/MIME, embedded devices. Certificate lifecycles, firmware in the field, and vendor dependencies stretch the timeline.

📜

Mandates Are Live

NIST IR 8547 sets RSA and ECC deprecation at 2030 and disallowance at 2035. CNSA 2.0 requires PQC for national security systems on a rolling schedule through 2033. OMB M-23-02 already requires federal cryptographic inventories.

Mosca's Inequality: the risk test

X + Y > Z  ⇒  exposed
X Shelf life: how long your data must stay confidential (often 10 to 25 years)
Y Migration time: how long your organization needs to fully transition (typically 5 to 10 years)
Z Threat horizon: time until a CRQC exists (many estimates cluster in the 2030s)
For most enterprises X + Y already exceeds any plausible Z, which means data encrypted today under classical key exchange should be treated as compromised in transit. This is why key establishment migrates first and signatures follow.

Regulatory and standards timeline

2016
 

NIST PQC competition opens

82 submissions enter a multi-round global evaluation of quantum-resistant algorithms.

2022
 

Winners selected · CNSA 2.0 released

Kyber, Dilithium, SPHINCS+, and Falcon are chosen. NSA publishes CNSA 2.0 with a phased PQC mandate for national security systems.

2024
 

FIPS 203, 204, 205 finalized

ML-KEM, ML-DSA, and SLH-DSA become final standards in August 2024. Production deployment can begin.

2025
 

HQC selected · CNSA 2.0 software signing deadline

NIST selects HQC as the backup KEM (code-based, distinct math from ML-KEM). CNSA 2.0 expects new software and firmware signing to be PQC.

2030
 

RSA / ECC deprecated (NIST IR 8547)

112-bit classical strength disallowed; RSA-2048 and ECC-256 signatures deprecated for federal use. CNSA 2.0 expects PQC as default across networking.

2035
 

Classical asymmetric disallowed

RSA, ECDSA, EdDSA, DH, and ECDH fully disallowed under NIST IR 8547. Full CNSA 2.0 enforcement across all deployments.

02 · The Standards

NIST-approved algorithms in detail

Three final FIPS standards, one draft, one backup KEM selection, and two stateful hash-based schemes for firmware. Select a tab to view design basis, parameter sets, and exact key, ciphertext, and signature sizes.

ML-KEM · Module-Lattice Key Encapsulation Mechanism

FIPS 203 · Final Aug 2024

Formerly CRYSTALS-Kyber. The primary standard for key establishment, replacing ECDH, DH, and RSA key transport. Security rests on the Module Learning With Errors (MLWE) problem over polynomial rings. It is an IND-CCA2 secure KEM built from an IND-CPA PKE via the Fujisaki-Okamoto transform.

Family
Structured lattice (MLWE)
Replaces
ECDH, DH, RSA-KEM
Shared secret
32 bytes
Performance
Faster than ECDH in most stacks
Parameter set NIST category Encaps key (pk) Decaps key (sk) Ciphertext Guidance
ML-KEM-512 1 (≈ AES-128) 800 B 1,632 B 768 B Constrained devices only
ML-KEM-768 3 (≈ AES-192) 1,184 B 2,400 B 1,088 B Default for TLS, SSH, VPN; the CNSA 2.0-adjacent industry consensus
ML-KEM-1024 5 (≈ AES-256) 1,568 B 3,168 B 1,568 B CNSA 2.0 requirement; high-assurance and long-lived secrets
Deployment reality: hybrid X25519MLKEM768 is already the default TLS 1.3 group in Chrome, Firefox, and major CDNs, and OpenSSH 9.9+ ships mlkem768x25519-sha256. The handshake grows by roughly 2 KB, which mainly matters for constrained links and middleboxes that assume small ClientHellos.

ML-DSA · Module-Lattice Digital Signature Algorithm

FIPS 204 · Final Aug 2024

Formerly CRYSTALS-Dilithium. The primary general-purpose signature standard, replacing RSA and ECDSA for certificates, code signing, and document signing. Based on MLWE and Module-SIS, using the Fiat-Shamir with Aborts construction. Deterministic and hedged signing modes are defined; hedged is the default to resist fault attacks.

Family
Structured lattice (MLWE / MSIS)
Replaces
RSA, ECDSA, EdDSA
Speed
Fast sign and verify
Tradeoff
Signatures ~10 to 50x larger than ECDSA
Parameter set NIST category Public key Private key Signature Guidance
ML-DSA-44 2 (≈ SHA-256 collision) 1,312 B 2,560 B 2,420 B Size-sensitive uses; short-lived certs
ML-DSA-65 3 (≈ AES-192) 1,952 B 4,032 B 3,309 B Default for TLS certificates and general PKI
ML-DSA-87 5 (≈ AES-256) 2,592 B 4,896 B 4,627 B CNSA 2.0 requirement; roots and high assurance
PKI impact: a full ML-DSA-65 TLS chain (leaf + intermediate + transmitted signatures) adds roughly 14 to 15 KB to the handshake versus an ECDSA chain. Plan for CA and CLM platform support, larger CRLs and OCSP responses, and TCP initial congestion window effects.

SLH-DSA · Stateless Hash-Based Digital Signature Algorithm

FIPS 205 · Final Aug 2024

Formerly SPHINCS+. A conservative signature scheme whose security reduces only to the properties of the underlying hash function (SHA2 or SHAKE), with no lattice assumptions. This makes it the hedge of choice for trust anchors and long-lived signatures. Twelve parameter sets: two hash families × three security levels × "s" (small signature, slow signing) or "f" (fast signing, large signature).

Family
Stateless hash-based (FORS + hypertree)
Replaces
RSA/ECDSA where assurance > size
Public keys
Tiny: 32 to 64 B
Tradeoff
Large signatures, slow "s" signing
Parameter set NIST category Public key Signature Character
SLH-DSA-128s 1 32 B 7,856 B Smallest sig; signing is slow (fine for offline CAs)
SLH-DSA-128f 1 32 B 17,088 B ~40x faster signing, ~2x sig size
SLH-DSA-192s 3 48 B 16,224 B Mid assurance, offline signing
SLH-DSA-192f 3 48 B 35,664 B Mid assurance, fast signing
SLH-DSA-256s 5 64 B 29,792 B Root CA / long-term archival favorite
SLH-DSA-256f 5 64 B 49,856 B Highest level, fast signing
Each set exists in SHA2 and SHAKE variants (e.g. SLH-DSA-SHA2-256s). Because a root signs rarely and its signature travels in a cert that is cached, the size and speed penalties are acceptable exactly where the conservative security matters most.

FN-DSA · FFT over NTRU-Lattice Digital Signature Algorithm

FIPS 206 · Draft

Formerly Falcon. An NTRU-lattice scheme using fast Fourier sampling that produces the most compact signatures of any selected PQC algorithm, attractive wherever bytes are precious (constrained protocols, blockchain, dense certificate chains). Standardization has trailed the 2024 trio because its floating-point Gaussian sampler is hard to implement in constant time, raising side-channel concerns for signing on shared or embedded hardware. Verification is simple and fast.

Family
NTRU lattice (SIS over NTRU)
Status
Draft; do not deploy for production signing yet
Strength
Smallest signatures + keys combined
Risk
FP sampler side channels
Parameter set NIST category Public key Signature (avg) Guidance
FN-DSA-512 1 897 B ~666 B Bandwidth-critical uses once final
FN-DSA-1024 5 1,793 B ~1,280 B High assurance, compact chains
Track FIPS 206 but architect so ML-DSA is the default and FN-DSA can slot in later where size wins matter. Verify-only deployments (e.g. verifying Falcon-signed objects) carry far less risk than signing.

HQC · Hamming Quasi-Cyclic KEM

Selected Mar 2025 · Standard pending

Selected from the fourth round as the backup KEM. HQC is code-based, resting on the hardness of decoding random quasi-cyclic codes, a mathematically independent foundation from ML-KEM's lattices. Its purpose is algorithm diversity: if cryptanalysis ever weakens structured lattices, a vetted alternative already exists. A draft standard is expected around 2026 with finalization to follow.

Family
Code-based (QC decoding)
Role
Backup to ML-KEM
Tradeoff
Larger keys and ciphertexts, slower
Action now
Design for swappability, not deployment
Parameter set NIST category Public key Ciphertext
HQC-128 1 2,249 B 4,497 B
HQC-192 3 4,522 B 9,042 B
HQC-256 5 7,245 B 14,485 B
The strategic lesson of HQC is crypto-agility: your architecture should treat the KEM as a pluggable component so a future swap is a configuration change, not a re-engineering program.

LMS & XMSS · Stateful Hash-Based Signatures

SP 800-208 · Approved 2020

Leighton-Micali Signatures (LMS/HSS) and the eXtended Merkle Signature Scheme (XMSS/XMSS-MT) were approved before the FIPS 203-205 trio and are the CNSA 2.0-mandated choice for firmware and software signing. They offer hash-only security with compact signatures, but each one-time key may be used exactly once: reusing a leaf state catastrophically breaks security. That state-management burden confines them to tightly controlled signing environments, ideally an HSM that enforces state internally.

Family
Stateful hash-based (Merkle trees)
Mandated for
Firmware / software signing (CNSA 2.0)
Signature size
~1.5 to 5 KB typical configs
Critical constraint
Never reuse a one-time key state
Operational rule: state must live inside an HSM or a strictly synchronized signing service; never in a backup that could be restored to an earlier state. If your signing operation cannot guarantee that, use SLH-DSA instead and accept the larger signatures.
03 · The Plan

A phased migration plan

Treat this as a multi-year program, not a project. Key establishment moves first because of harvest-now-decrypt-later; signatures follow as PKI ecosystems mature. Expand each phase.

1

Discover & Inventory (CBOM)

You cannot migrate what you cannot see · Months 0 to 6

▾
Build a Cryptographic Bill of Materials: every algorithm, key, certificate, protocol, and library across networks, hosts, code, and HSMs.
  • Network discovery: TLS scanning of internal and external endpoints, cipher suite and protocol version capture
  • Certificate discovery: CLM platform scans (CA-integrated, network, agent-based) to find managed and unmanaged certs
  • Code and dependency analysis: static scanning for crypto API calls and embedded keys; CBOM output in CycloneDX 1.6 format
  • Catalog HSM partitions, key ceremonies, root and intermediate hierarchies, and every place private keys live
  • Record metadata that drives priority: data shelf life, key lifetime, system owner, vendor dependency
Rank every finding by exposure, not by convenience.
  • Score assets on data shelf life (X) vs. realistic migration effort (Y); anything long-lived encrypted in transit goes first
  • Flag harvest-now-decrypt-later exposure: external TLS, VPN tunnels, site-to-site links carrying regulated data
  • Identify hard dependencies: vendor products without PQC roadmaps, embedded devices that cannot be re-keyed, protocols frozen by compliance
  • Map to compliance clocks: NIST IR 8547 (2030 deprecation / 2035 disallowed), CNSA 2.0 phase dates, sector regulators
  • Produce a remediation backlog with owners, target quarters, and budget signals
Re-architect so the next algorithm change (including a future HQC or FN-DSA swap) is operational, not developmental.
  • Centralize crypto behind abstraction layers and policy engines instead of hard-coded algorithm choices
  • Upgrade the estate: TLS 1.3 everywhere, current OpenSSL/BoringSSL, PQC-capable HSM firmware, CLM platform versions with ML-DSA / ML-KEM support
  • Automate certificate lifecycle end to end (ACME, EST, SCEP, APIs); shortening cert lifetimes is itself an agility test
  • Write PQC requirements into every RFP, contract renewal, and vendor scorecard; demand published roadmaps
  • Stand up a lab: benchmark ML-KEM-768 handshakes, ML-DSA chain sizes, and HSM signing throughput against your real workloads
Hybrid schemes combine a classical and a PQC primitive so security holds if either survives. See the hybrid structure diagram below.
  • Enable X25519MLKEM768 on external TLS termination first (CDNs, load balancers, API gateways), then internal east-west traffic
  • Extend to SSH (mlkem768x25519-sha256) and IPsec/IKEv2 (RFC 9370 additional key exchanges)
  • Pilot PQC PKI: issue ML-DSA test hierarchies; evaluate composite and hybrid certificates for relying-party compatibility
  • Monitor for breakage: middleboxes dropping large ClientHellos, UDP fragmentation in IKE, cert chain size limits in embedded clients
  • Track CPU, latency, and handshake failure telemetry against the classical baseline before widening rollout
Move from hybrid to pure PQC as ecosystem confidence and mandates allow, then retire classical crypto deliberately.
  • Roll PQC root and issuing CA hierarchies to production (SLH-DSA or ML-DSA-87 roots, ML-DSA-65 issuance)
  • Re-sign long-lived artifacts: firmware (LMS/HSS per CNSA 2.0), code signing, document archives with PQC timestamps
  • Disable classical-only cipher suites and key exchanges on a published schedule aligned to 2030/2035 dates
  • Destroy or re-wrap classical-protected key material; update key ceremony and escrow documentation
  • Keep the CBOM continuously updated: migration ends, but crypto governance does not

Anatomy of a hybrid key exchange (X25519MLKEM768)

Both key exchanges run in the same handshake. An attacker must break both X25519 and ML-KEM-768 to recover the session keys, so security never regresses below today's classical baseline while gaining quantum resistance.

Hybrid for signatures & certificates

Three patterns are in play across the PKI ecosystem:

  • Composite certificates: one certificate carries both a classical and a PQC key and signature (e.g. ECDSA + ML-DSA); relying parties verify both. Cleanest security, requires updated clients.
  • Dual / parallel certificates: two separate certs, one classical and one PQC, selected by negotiation. Maximum compatibility, doubled lifecycle overhead (a strong argument for CLM automation).
  • Chameleon / catalyst approaches: PQC data embedded in extensions of a classical cert so legacy clients ignore it. Transitional only.

What hybrid does not fix

Hybrid key exchange protects future sessions, not the past or the whole stack:

  • Traffic already harvested under classical-only exchange stays exposed
  • Authentication (certificates, signatures) remains classical until the PKI itself migrates; signature forgery only matters at attack time, so it is urgent later than KEMs, but roots take longest to roll
  • Symmetric crypto needs review too: standardize on AES-256 and SHA-384/SHA-512 per CNSA 2.0
  • Hybrid is a bridge; plan the exit to pure PQC, do not let it become the destination
04 · The Map

Algorithm translation table

A working reference for mapping today's deployments to their approved post-quantum replacements.

Approved PQC Algorithm Modern Algorithm(s) Replaced Use Case
ML-KEM-768 / 1024 (FIPS 203) ECDH (P-256/P-384), X25519, DH, RSA key transport TLS 1.3 key establishment, SSH, IPsec/IKEv2, general key encapsulation; deploy hybrid (X25519MLKEM768) first
ML-DSA-65 / 87 (FIPS 204) RSA-2048/3072 (PKCS#1, PSS), ECDSA P-256/P-384, Ed25519 TLS server and client certificates, general PKI issuance, code signing, document signing, timestamping
SLH-DSA-256s / 192s (FIPS 205) RSA-4096, ECDSA P-384 (high-assurance signing) Root CAs and trust anchors, long-term archival signatures, conservative hedge where lattice risk is unacceptable
FN-DSA-512 / 1024 (FIPS 206 draft) ECDSA, Ed25519 (compact signatures) Bandwidth-constrained signing once finalized: dense cert chains, constrained protocols, verify-heavy systems
HQC (selection, standard pending) Backup to ML-KEM (same targets as ECDH/DH) Algorithm-diversity contingency for key establishment; design for swappability now
LMS / HSS · XMSS / XMSS-MT (SP 800-208) RSA / ECDSA firmware signing Firmware, boot images, and software update signing (CNSA 2.0 mandated); requires strict state management in an HSM
AES-256 (FIPS 197) AES-128, 3DES Symmetric encryption already quantum-resistant at 256-bit; Grover only halves effective strength
SHA-384 / SHA-512 / SHA3 SHA-1, SHA-256 (where margin desired) Hashing and HMAC; CNSA 2.0 specifies SHA-384 or SHA-512
Sizing rule of thumb: match NIST security categories across the stack. A Category 3 deployment pairs ML-KEM-768 + ML-DSA-65 + AES-256 + SHA-384. CNSA 2.0 environments jump straight to Category 5: ML-KEM-1024 + ML-DSA-87.
Get Started

Ready to see where you stand?

Get a tailored cryptographic risk assessment mapped to your infrastructure, timeline, and compliance obligations.

Secure Your Quantum Assessment
Reference material compiled from FIPS 203 / 204 / 205, draft FIPS 206, NIST SP 800-208, NIST IR 8547, and CNSA 2.0 guidance. Verify parameter choices against current publications before production use.
Optimized by Optimole

Download this Resource