Post-Quantum Cryptography Migration Checklist 2026

📅 October 18, 2026  |  🏷 Cyber Security  |  Cyber Security, Information Security, Threat Management

Harvest Now, Decrypt Later. That three-word phrase represents the most structurally dangerous threat in the history of cryptography—and it’s already operational. Nation-state actors are systematically exfiltrating encrypted traffic today, banking on the assumption that sufficiently powerful quantum computers will arrive within the next decade to crack the RSA-2048 and ECC keys protecting that data. NIST’s finalization of its first post-quantum cryptography standards in August 2024 wasn’t a theoretical milestone; it was a starting gun. Engineers who haven’t begun their migration planning are already behind schedule.

Understanding the Quantum Threat Landscape

The cryptographic bedrock of modern enterprise infrastructure—RSA, Diffie-Hellman, and Elliptic Curve Cryptography—derives its security from the computational difficulty of factoring large integers or solving discrete logarithm problems. Shor’s Algorithm, when run on a sufficiently powerful fault-tolerant quantum computer, reduces these problems from exponential-time to polynomial-time complexity. Translation: what currently takes longer than the age of the universe to crack could be broken in hours.

IBM’s quantum roadmap projects 100,000+ qubit systems by 2033. CISA and NSA’s “Commercial National Security Algorithm Suite 2.0” (CNSA 2.0), released in 2022, mandated that National Security Systems complete PQC migration by 2035. That timeline is not a suggestion—it’s a floor, not a ceiling.

Why Classical Security Controls Don’t Prepare You

Many security teams make the mistake of conflating cryptographic agility with quantum resistance. Rotating TLS certificates more frequently, extending key lengths to RSA-4096, or enforcing stricter access controls addresses zero of the underlying algebraic vulnerabilities that quantum computing exploits. A 4096-bit RSA key doesn’t buy meaningfully more time against a Cryptographically Relevant Quantum Computer (CRQC) than a 2048-bit key does. The attack surface isn’t about key size within the same algorithm family—it’s about the fundamental hardness problem the algorithm relies on.

Classifying Your Cryptographic Risk by Data Longevity

Not all encrypted data has equal exposure risk. A useful risk classification framework considers two axes: time-to-compromise (how long before CRQCs become practical) and data sensitivity shelf life (how long the data remains valuable if decrypted). Health records, financial transaction histories, state secrets, and intellectual property with decade-long relevance sit in the highest-risk quadrant. Session tokens and short-lived authentication credentials sit in the lowest. Your migration priority queue should be built on this matrix, not on which systems are easiest to upgrade.

NIST PQC Standards: What Engineers Must Know

In August 2024, NIST formally published three post-quantum cryptographic standards under FIPS designations: ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) for key encapsulation mechanisms, ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (FIPS 205, formerly SPHINCS+) for hash-based digital signatures. A fourth standard, FN-DSA (formerly FALCON), is anticipated in early 2025. These aren’t experimental proposals—they are the deployable standards your migration should be built around.

Algorithm Selection Guide for Common Use Cases

One engineering nuance worth emphasizing: ML-KEM produces larger public keys and ciphertexts than ECDH. ML-KEM-768 public keys are 1,184 bytes compared to 32 bytes for X25519. This has tangible implications for TLS handshake sizes, memory-constrained devices, and protocol buffer allocations. Benchmark your specific environments before committing to a security level.

The Cryptographic Inventory Audit: Where to Start

Before a single line of PQC code gets written, engineers need a comprehensive cryptographic bill of materials (CBOM). A 2023 Ponemon Institute study found that 60% of organizations could not fully enumerate the cryptographic algorithms in active use across their infrastructure. That number must reach zero before migration can be planned with any accuracy.

Building Your Cryptographic Bill of Materials

A thorough CBOM effort spans five discovery layers:

1. Network traffic analysis: Use tools like Zeek (Bro), TLS fingerprinting, or commercial solutions like Crypto4A’s CryptoCenter to passively identify cipher suites in active TLS sessions. Pay special attention to internal service-to-service traffic, which is frequently overlooked.
2. Application source code scanning: Static analysis tools, including Semgrep with cryptographic rulesets or SAST platforms like Checkmarx, can surface hardcoded keys, deprecated cipher calls, and custom cryptographic implementations.
3. Library and dependency auditing: Map every cryptographic library in your software supply chain. OpenSSL version, BouncyCastle version, native OS crypto APIs—each has different PQC readiness timelines.
4. PKI and certificate inventory: Export all certificates from your CA infrastructure. Flag all RSA and ECC certificates by expiry date and usage context. Certificates with expiry dates past 2030 are particularly urgent.
5. Hardware Security Module (HSM) capability mapping: Many deployed HSMs lack firmware support for PQC algorithms. Thales Luna and Entrust nShield have begun releasing PQC-capable firmware, but device-specific upgrade paths vary considerably.

Prioritizing Migration Targets

Once your CBOM exists, apply a three-tier priority model. Tier 1 covers systems protecting long-lived sensitive data or that form the cryptographic root of trust (root CAs, HSMs, key management infrastructure). Tier 2 covers internet-facing TLS endpoints, VPN gateways, and authentication systems. Tier 3 covers internal systems, development environments, and ephemeral encryption contexts. Each tier has different urgency and different acceptable hybrid deployment timelines.

Hybrid Cryptography: The Pragmatic Bridge Strategy

Full PQC deployment in a single cutover is operationally unrealistic for most enterprise environments. Hybrid cryptography—combining a classical algorithm (e.g., X25519) with a post-quantum algorithm (e.g., ML-KEM-768) in the same key exchange—provides quantum resistance while maintaining interoperability with non-PQC-capable endpoints. If the PQC component is compromised by an unforeseen classical attack, the classical component still provides established security guarantees. If a CRQC breaks the classical component, the PQC component maintains confidentiality.

Google deployed hybrid post-quantum key agreement in Chrome for a subset of TLS 1.3 connections in 2023, logging performance and compatibility data at scale before broader rollout. Cloudflare similarly conducted hybrid PQC experiments starting in 2022. Both found that TLS handshake latency increased by roughly 1–3ms in hybrid mode—a negligible cost for most enterprise applications but one worth validating in latency-sensitive environments like high-frequency trading or real-time control systems.

Protocol-Specific Implementation Considerations

Hybrid PQC isn’t uniformly supported across protocols. Engineers need to verify support at each layer:

• TLS 1.3: RFC 8446 extension points support hybrid key exchange. OpenSSL 3.x with the OQS provider (Open Quantum Safe project) enables PQC cipher suites today.
• SSH: OpenSSH 9.0+ introduced support for the sntrup761 + X25519 hybrid as the default key exchange. Verify your SSH daemon version across all managed hosts.
• S/MIME and PGP: Migration here lags significantly. Most email gateway solutions do not yet support PQC signing or encryption. Plan for a longer transition horizon in secure email workflows.
• Code signing: Microsoft Authenticode, Apple notarization, and RPM/DEB package signing chains all require vendor-side PQC rollout that engineers cannot unilaterally accelerate. Track vendor roadmaps actively.

Common Migration Pitfalls and How to Avoid Them

A 2025 survey by the Cloud Security Alliance found that 47% of organizations that began PQC migration projects encountered unexpected protocol breakage within legacy internal systems—primarily from hard-coded key size assumptions and buffer overflow conditions caused by the larger key material in PQC algorithms. The engineering debt from decade-old cryptographic implementations tends to surface only under migration pressure.

The Five Most Dangerous Migration Mistakes

1. Skipping hybrid mode and deploying PQC-only: PQC algorithms are mature but not universally battle-tested against classical attacks. Hybrid deployments maintain your classical security backstop while adding quantum resistance. Unilaterally removing classical algorithms before PQC interoperability is confirmed across your full ecosystem is an availability risk.
2. Ignoring firmware and embedded systems: PLCs, SCADA controllers, network switches, and medical devices often contain hardcoded cryptographic implementations that cannot be remotely updated. Physical replacement cycles must be integrated into your migration roadmap.
3. Assuming vendor patch timelines will align with your schedule: Enterprise software vendors—ERP systems, identity providers, endpoint detection platforms—are on independent PQC upgrade cycles. Build your migration plan around documented vendor commitments, not aspirational roadmaps.
4. Neglecting performance benchmarking on production-representative hardware: PQC operations are computationally heavier than ECC equivalents in some contexts. ML-DSA signature verification is faster than RSA, but ML-KEM encapsulation overhead varies by hardware architecture. Test on actual production hardware profiles.
5. Treating PQC migration as a one-time event: Cryptographic agility—the ability to swap algorithms with minimal re-engineering—is a permanent architectural requirement. Build abstraction layers around cryptographic operations in your codebase so future algorithm transitions don’t require the same level of invasive refactoring.

Governance, Compliance, and Stakeholder Alignment

Post-quantum migration isn’t purely an engineering problem. CISA’s “Post-Quantum Cryptography Initiative” explicitly frames PQC readiness as a board-level risk management concern. OMB Memorandum M-23-02 required U.S. federal agencies to submit cryptographic inventories to CISA by May 2023—a requirement that many private sector organizations are adopting voluntarily as regulatory frameworks evolve.

The EU’s NIS2 Directive, fully enforceable as of October 2024, strengthens requirements for cryptographic controls across critical infrastructure sectors. While NIS2 doesn’t explicitly mandate PQC, its risk management obligations are increasingly interpreted by national competent authorities to encompass quantum threat modeling. Organizations in energy, finance, healthcare, and transport should proactively document their PQC readiness posture.

Structuring Your PQC Program for Executive Visibility

CISOs presenting PQC migration to board-level stakeholders should frame the effort through three lenses: regulatory compliance timelines (with explicit reference to NSA CNSA 2.0 and relevant sector-specific mandates), reputational and liability risk from harvest-now-decrypt-later exposure of customer data, and competitive differentiation in sectors where cryptographic security assurance is a procurement differentiator. Budget justification framed purely in technical terms fails at the board level. Frame it as risk mitigation with quantifiable timelines.

Establish a dedicated PQC steering committee with representation from engineering, security, legal, and procurement. Migration decisions—particularly around HSM replacement, PKI re-architecture, and vendor contract requirements—cross organizational boundaries that no single team can navigate unilaterally.

Key Takeaways

• Harvest-now-decrypt-later attacks are active today: Data encrypted with classical algorithms and exfiltrated now will be vulnerable once CRQCs become operational. Migration urgency scales with data sensitivity and longevity, not with quantum computer arrival timelines.
• NIST FIPS 203, 204, and 205 are the authoritative deployment targets: ML-KEM, ML-DSA, and SLH-DSA are finalized standards. Migration planning built around earlier draft algorithms needs immediate revision.
• A cryptographic bill of materials is the non-negotiable first step: You cannot migrate what you cannot enumerate. CBOM development must cover network traffic, application code, dependencies, PKI infrastructure, and hardware capabilities.
• Hybrid cryptography is the recommended bridge architecture: Deploy PQC algorithms alongside classical algorithms during the transition period. Do not remove classical algorithm support until PQC interoperability is fully validated across your ecosystem.
• Cryptographic agility must become a permanent engineering discipline: Post-quantum migration reveals the cost of cryptographic rigidity. Architect abstraction layers around all cryptographic operations to reduce the cost of future algorithm transitions.

Conclusion: Start the Clock Now

The organizations that will complete PQC migration on schedule are those that begin systematic work in 2026, not those that wait for quantum hardware to appear in news headlines. NIST’s standards are published. CISA’s guidance is clear. The technical ecosystem—from OpenSSL to cloud KMS providers—is rapidly adding PQC support. The remaining obstacle is organizational inertia.

Your specific next action: commission a cryptographic inventory audit within the next 30 days. Use the CBOM framework outlined above, leverage the Open Quantum Safe project’s liboqs for test deployments, and map your findings against the three-tier priority model. If your organization operates within U.S. federal contracting, financial services, or critical infrastructure, begin drafting your PQC roadmap document for CISO and board review before Q1 2027. The quantum clock doesn’t pause for budget cycles.