Post-Quantum Cryptography Migration 2026: What Enterprises Need to Do
Post-quantum cryptography (PQC) migration is no longer theoretical. NIST has finalized its first post-quantum standards, and enterprises holding long-term sensitive or regulated data need a clear plan — not next year, but now. The window between "optional preparation" and "regulatory requirement" is closing fast.
This guide covers what the NIST PQC standards mean for enterprise infrastructure, how to plan a hybrid HSM migration, the specific steps involved, and the mistakes to avoid.
The Threat: Harvest Now, Decrypt Later
The most common objection to PQC migration is "quantum computers don't exist yet." This misses the actual threat model. Adversaries — particularly nation-state actors — are harvesting encrypted data today with the intention of decrypting it once quantum computers reach sufficient capability. This is called a harvest-now-decrypt-later (HNDL) attack.
For enterprises, this means any data that must remain confidential for more than 10 years is already at risk. This includes:
- Healthcare records (HIPAA requires indefinite protection for some categories)
- Financial instruments and trading algorithms
- Intellectual property and trade secrets
- Cryptocurrency custody keys and digital asset vaults
- Legal documents under attorney-client privilege
- Government and defense-related data
If your encryption can be broken in 10-15 years and your data must stay confidential for 20+, the math is simple: the protection window has already started.
What NIST Has Finalized
NIST's post-quantum standardization process has produced three primary standards:
| Standard | Algorithm | Purpose | Key Size Impact |
|---|---|---|---|
| FIPS 203 (ML-KEM) | CRYSTALS-Kyber | Key encapsulation (replaces RSA/ECDH key exchange) | Public key ~1,568 bytes (vs. 32 bytes for X25519) |
| FIPS 204 (ML-DSA) | CRYSTALS-Dilithium | Digital signatures (replaces RSA/ECDSA signatures) | Signature ~3,293 bytes (vs. 64 bytes for Ed25519) |
| FIPS 205 (SLH-DSA) | SPHINCS+ | Hash-based signatures (backup scheme) | Signature ~17,088 bytes (conservative parameter set) |
The key takeaway: PQC algorithms work, but they produce significantly larger keys and signatures than classical equivalents. This has real implications for storage, bandwidth, certificate sizes, and HSM capacity planning.
The Hybrid Approach: Why Not Just Switch?
A direct cutover from classical to PQC algorithms is impractical for most enterprises. The hybrid approach — running classical and PQC algorithms in parallel — is the recommended migration path for several reasons:
- Algorithm confidence: While NIST-selected algorithms have undergone extensive analysis, the cryptographic community still prefers a belt-and-suspenders approach. If a PQC algorithm is later found to have weaknesses, the classical algorithm provides a fallback.
- Interoperability: Not all systems, clients, and partners will support PQC simultaneously. Hybrid mode maintains backward compatibility during the transition.
- Regulatory acceptance: Hybrid approaches are explicitly endorsed by NIST guidance and are the expected migration pattern for federal compliance.
- Risk management: Running both algorithms means that a vulnerability in either one does not compromise the system. Security is maintained as long as at least one algorithm is sound.
How hybrid works in practice: For key exchange, a TLS connection negotiates both a classical key (e.g., X25519) and a PQC key (e.g., ML-KEM-768). The shared secret is derived from both, so an attacker must break both algorithms. For signatures, documents are dual-signed with both classical (e.g., ECDSA P-384) and PQC (e.g., ML-DSA-65) keys.
Enterprise Migration Roadmap: 6 Steps
Based on our advisory work with enterprises across financial services, healthcare, and critical infrastructure, here is the migration roadmap we recommend:
Step 1: Cryptographic Inventory (Weeks 1-4)
Identify every system, protocol, and data store that uses public-key cryptography. This includes TLS configurations, VPN tunnels, code signing, document signing, certificate authorities, key wrapping for vault encryption, and API authentication. Classify each by data sensitivity and required secrecy lifetime.
Step 2: Risk Prioritization (Weeks 3-6)
Map each system to the HNDL threat model. Prioritize based on: (a) secrecy lifetime requirement, (b) exposure to network interception, (c) data value, and (d) regulatory sensitivity. Systems protecting data with 20+ year confidentiality requirements are the highest priority.
Step 3: HSM and Infrastructure Assessment (Weeks 4-8)
Determine whether your current HSMs support PQC algorithms. Recent models from Thales Luna, Entrust nShield, AWS CloudHSM, and Azure Managed HSM support PQC via firmware updates. Older hardware may require replacement. Assess key storage capacity (PQC keys are much larger), certificate infrastructure readiness, and TLS stack compatibility.
Step 4: Architecture Design (Weeks 6-12)
Design the hybrid architecture: dual key generation, hybrid certificate issuance, TLS hybrid key exchange configuration, and vault re-encryption strategy. Specify which PQC algorithms to use for each use case (ML-KEM for key exchange, ML-DSA for signatures). Plan key rotation schedules and backup procedures for hybrid key pairs.
Step 5: Phased Implementation (Months 3-18)
Roll out in phases, starting with highest-risk systems:
- Phase A: Key exchange migration (TLS, VPN) — highest exposure to HNDL
- Phase B: Signing migration (certificates, code signing, document signing)
- Phase C: Vault and cold storage re-encryption — re-wrap existing vaulted data with hybrid keys
Test recovery and restore procedures at each phase to ensure PQC-protected vaults remain restorable.
Step 6: Validation and Compliance Documentation (Ongoing)
Verify hybrid implementations produce correct results under realistic workloads. Document compliance evidence for SEC, NIS2, DORA, and sector-specific auditors. Measure Time to Clean Restore with PQC-protected vaults to ensure recovery capability is maintained. Build the evidence package auditors will ask for.
Common Migration Mistakes
- "We'll wait until quantum computers arrive." The HNDL threat is active now. Waiting means the data harvested today will be decryptable in the future. The time to protect is before collection, not after.
- "Our cloud provider handles encryption." Cloud providers manage infrastructure encryption, but application-level key management, vault encryption, and certificate operations are your responsibility. PQC migration touches all of these.
- "We'll just swap algorithms." PQC keys and signatures are 50-500x larger than classical equivalents. This affects storage capacity, network bandwidth, TLS handshake performance, certificate chain sizes, and HSM capacity. Testing under realistic load is essential.
- "IT can handle this alone." PQC migration touches legal (contract obligations for data protection), compliance (regulatory evidence), procurement (HSM hardware refresh), finance (budget for 12-24 month project), and operations (key ceremonies, DR procedures). It needs executive sponsorship.
- "We don't need to test recovery." Migrating encryption without testing that you can still restore from cold storage defeats the purpose. Every implementation phase must include recovery validation.
Who Needs to Act Now?
If your organization meets any of these criteria, PQC migration planning should be underway:
- Holds data with secrecy requirements beyond 10 years
- Subject to SEC, NIS2, DORA, HIPAA, or federal compliance
- Operates internal certificate authorities or PKI
- Uses HSMs for key management, code signing, or document signing
- Custodians of digital assets, cryptocurrency, or tokenized securities
- Government contractors or defense-adjacent
Organizations that custody digital assets or signing keys should pair hybrid HSM with hardware-grade key storage. For consumer and team hardware we recommend: Ledger, Trezor, OneKey, and Tangem.
Next Steps
Start with a cryptographic inventory — understand where you use public-key cryptography and what data it protects. Then assess your HSM readiness. These two steps take 4-8 weeks and give you the foundation for a prioritized migration plan.
For a structured assessment, see our Post-Quantum Ready service. For recovery validation of your existing or planned PQC architecture, see our Cyber-Resilience Audit.