Evidence signature
Public signals bind to governed proof.
No customer data.
QScout proof sequence. Evidence Handshake. public-to-private proof path. No customer data.
A comprehensive 5-phase framework for migrating enterprise cryptographic infrastructure toNIST-standardized post-quantum algorithms. Covering algorithm selection, hybrid deployment, compliance timelines, and the operational realities that determine whether your migration succeeds or stalls.
The question is no longer whether quantum computers will break RSA and ECC, but when. NIST published final post-quantum cryptographic standards in August 2024 — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). The standardization phase is over. The migration phase has begun.
Three converging pressures make immediate action necessary:
Nation-state adversaries are intercepting and storing encrypted traffic today using Harvest Now, Decrypt Later (HNDL) strategies. When a cryptographically relevant quantum computer (CRQC) becomes operational — expert estimates range from 2029 to 2040 — all data encrypted with RSA, ECDSA, or ECDH becomes retroactively readable. If your data has a sensitivity lifetime exceeding 5-10 years, the threat window is already open.
Learn about HNDL attacks →CNSA 2.0 requires quantum-safe algorithms for National Security Systems by 2030 and prohibits classical-only cryptography by 2035. OMB M-23-02 mandates federal agencies complete cryptographic inventories. NIST IR 8547 already classifies RSA, ECDSA, and EdDSA as "not recommended" for new systems. These are not aspirational targets — they are compliance deadlines with procurement and contract implications.
View the compliance checklist →Enterprise PQC migration is not a patch deployment. It requires cryptographic inventory, risk assessment, architecture planning, hybrid deployment, application testing, PKI overhaul, vendor coordination, and continuous monitoring. Typical enterprise migrations take 3-8 years (source: NIST PQC transition guidance). Organizations that begin in 2026 will be completing migration near the 2030 CNSA 2.0 deadline. Organizations that wait will miss it.
Calculate your quantum risk →Understanding the regulatory timeline is critical for migration planning. These are not suggestions — they are standards and compliance deadlines that will affect government contracts, regulatory audits, and cyber insurance requirements.
Final standards for ML-KEM, ML-DSA, and SLH-DSA released. Organizations can begin production implementation.
HQC selected as backup KEM. FN-DSA (FALCON) selected for standardization as FIPS 206 (in development). NIST IR 8547 declares RSA/ECC "not recommended" for new systems.
NSA requires quantum-safe algorithms for all National Security Systems. RSA, ECDSA, ECDH deprecated for government use.
Classical-only cryptography prohibited in National Security Systems. All systems must use NIST-approved PQC algorithms exclusively.
NIST FIPS 203, FIPS 204, and FIPS 205 specify three post-quantum algorithm families. Each serves a distinct cryptographic purpose. Selecting the right algorithm for each use case is the foundation of a successful migration. For a complete reference, see the quantum-safe algorithm reference and the PQC glossary.
Recommendation: Default choice for TLS key exchange, VPN tunnels, and encrypted communications. ML-KEM-768 recommended for most enterprise use cases.
Recommendation: Default choice for code signing, document signing, certificate issuance, and API authentication. ML-DSA-65 recommended for most enterprise use cases.
Recommendation: Conservative fallback for organizations requiring algorithmic diversity beyond lattice assumptions. Slower signing but relies only on hash function security. Recommended for root CA certificates, firmware signing, and long-lived documents.
PQC migration is a multi-year program, not a technology swap. This framework structures the migration into five sequential phases, each with defined inputs, activities, and gate criteria. Skipping phases is the primary cause of migration failures.
You cannot migrate what you cannot see. The first phase builds a complete Cryptographic Bill of Materials (CBOM) cataloging every algorithm, key, certificate, and protocol across your enterprise. This includes TLS configurations on all endpoints, certificate authority chains, key management system contents, embedded firmware cryptography, third-party API integrations, database encryption, VPN configurations, and code signing infrastructure.
Manual inventory is insufficient for organizations with more than a few hundred endpoints. Automated discovery tools scan networks, parse configurations, and identify cryptographic assets that manual audits miss. A QScout Free QScout scan provides an initial view of your external TLS posture and cryptographic debt.
Complete CBOM with coverage exceeding 95% of endpoints. All cryptographic assets tagged with algorithm, key size, protocol version, owner, and business criticality.
Not all cryptographic assets carry equal quantum risk. Phase 2 evaluates each asset against three dimensions: quantum vulnerability (is the algorithm broken by Shor's or Grover's?), data sensitivity (how long must confidentiality be maintained?), and business criticality (what is the impact of compromise?). The intersection of these dimensions produces a prioritized migration queue.
The Quantum Risk Calculator provides an interactive tool for estimating exposure. For enterprise-wide assessment, the Board Number methodology quantifies quantum risk in financial terms that board members and executive leadership can act on.
Prioritized migration queue ranked by quantum risk score. HNDL exposure window calculated for all data classes. Board-ready risk report with financial impact estimates.
Architecture planning maps each use case to the appropriate NIST-standardized algorithm and defines the hybrid deployment strategy. Key decisions include: ML-KEM parameter selection (768 vs. 1024), signature algorithm choice (ML-DSA vs. SLH-DSA for different trust anchors), hybrid pairing strategy (X25519+ML-KEM-768 for TLS, RSA-3072+ML-DSA-65 for certificates during transition), and the crypto-agility abstraction layer design.
Crypto-agility is not optional. It is the architectural property that allows algorithm substitution without application changes. Organizations that hardcode algorithm choices will face the same migration burden again when standards evolve. The architecture must treat algorithm selection as configuration, not code. See NSM-10 requirements for federal crypto-agility mandates.
Algorithm selection matrix mapping every use case to specific NIST algorithms. Hybrid deployment architecture documented. Crypto-agility layer designed and reviewed.
Hybrid deployment is the bridge between classical and quantum-safe cryptography. In hybrid mode, each cryptographic operation combines a classical algorithm with a post-quantum algorithm. For TLS key exchange, this means X25519+ML-KEM-768: the shared secret is derived from both algorithms, so security is maintained even if one algorithm is later found to be weak. Chrome, Firefox, and Cloudflare already support this configuration in TLS 1.3.
Hybrid deployment serves three purposes: it provides quantum protection immediately, it maintains backward compatibility with systems that do not yet support PQC, and it hedges against the possibility of weaknesses in newly standardized algorithms. The IETF has published draft standards for hybrid key exchange in TLS, and major cloud providers (AWS, Google Cloud, Azure) support hybrid configurations.
During this phase, deploy hybrid configurations to production systems in priority order from the Phase 2 risk assessment. Monitor for performance regression — PQC algorithms generally add 1-3ms to TLS handshakes and increase bandwidth by 1-2KB per handshake. These overheads are negligible for most enterprise workloads but may require optimization for latency-sensitive or bandwidth-constrained applications.
Hybrid PQC deployed to all priority-1 and priority-2 systems. Performance baselines established. Interoperability validated across all dependent services. Rollback procedures tested.
Full migration deprecates classical-only cryptographic paths and transitions to PQC-only configurations where hybrid is no longer required. This phase is driven by compliance deadlines (CNSA 2.0 prohibition by 2035) and by the maturation of PQC implementations across the vendor ecosystem. Not all systems will reach PQC-only simultaneously — the transition will be gradual and governed by interoperability requirements.
Continuous monitoring is the permanent operational state after migration. Cryptographic drift detection identifies regression — systems that revert to classical-only configurations, certificates issued with deprecated algorithms, or new deployments that bypass the crypto-agility layer. Compliance validation ensures ongoing alignment with evolving standards as NIST publishes updates and additional algorithm selections.
All systems migrated to PQC or hybrid PQC. Classical-only paths deprecated. Continuous cryptographic monitoring operational. Drift detection alerting confirmed. Compliance documentation audit-supporting.
Deploying PQC algorithms without adversarial testing is deploying blind. Migration validation must confirm that PQC implementations are correct, that hybrid configurations maintain security guarantees, and that no classical-only fallback paths remain exploitable.
QStrike validates PQC implementations through provider-aligned validation and classical attack vectors. It tests TLS negotiation with PQC cipher suites, verifies hybrid key exchange produces correct shared secrets, identifies downgrade attack vectors where classical-only fallbacks remain, and measures cryptographic performance under adversarial conditions. Every migration should include QStrike validation before and after deployment.
These five failure modes account for the majority of stalled or failed PQC migrations. Each is preventable with proper planning.
Organizations focus on the CRQC timeline (2029-2040) and ignore the fact that adversaries are harvesting encrypted data today. If your data has a sensitivity lifetime exceeding 5 years, you are already within the HNDL threat window. Financial records, healthcare data, classified communications, and intellectual property are all targets.
Calculate your HNDL exposure using the data sensitivity lifetime minus the migration timeline. If the result is negative, you are already late.
Jumping straight to algorithm selection without knowing what cryptography is deployed where. Shadow IT, embedded firmware, legacy protocols, and third-party integrations often contain undocumented cryptographic dependencies that surface during migration and cause outages.
Complete a full Cryptographic Bill of Materials (CBOM) before selecting algorithms. Automated scanning tools like QScout catch what manual audits miss.
Implementing ML-KEM or ML-DSA directly in application code without a crypto-agility abstraction layer. When NIST updates recommendations or a vulnerability is discovered, every hardcoded integration requires code changes, testing, and redeployment.
Build a crypto-agility layer: abstract algorithm selection behind configuration, not code. Enable algorithm rotation without application changes.
ML-KEM-768 public keys are 37x larger than X25519. ML-DSA-65 signatures are 52x larger than Ed25519. These size increases break assumptions in packet buffers, database columns, certificate stores, QR codes, and bandwidth-constrained IoT channels.
Audit every system that stores, transmits, or processes keys and signatures for size constraints. Test with actual PQC payloads, not estimates.
PQC migration is not a single project with a completion date. It is a permanent shift to continuous cryptographic lifecycle management. New algorithms will be standardized, existing algorithms will be updated, and quantum hardware capabilities will evolve.
Establish continuous cryptographic monitoring. Deploy drift detection to catch regression. Plan for algorithm rotation as a recurring operational process.
Enterprises should start PQC migration immediately. NIST published final PQC standards (FIPS 203, 204, 205) in August 2024. The NSA CNSA 2.0 timeline requires quantum-safe algorithms for National Security Systems by 2030 and prohibits classical algorithms by 2035. Given that enterprise migrations typically take 3-8 years (source: NIST PQC transition guidance), organizations that have not begun planning are already behind schedule. The Harvest Now, Decrypt Later (HNDL) threat means sensitive data encrypted today with RSA or ECC is already at risk of future decryption.
ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) is a lattice-based key encapsulation mechanism used for key exchange and encryption. ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) is a lattice-based digital signature algorithm for authentication and code signing. SLH-DSA (FIPS 205, formerly SPHINCS+) is a stateless hash-based signature scheme that provides a conservative fallback not dependent on lattice assumptions. Most enterprises will use ML-KEM for TLS key exchange and ML-DSA for digital signatures, with SLH-DSA reserved for high-assurance applications requiring algorithmic diversity.
Hybrid PQC deployment combines a classical algorithm (such as X25519 or RSA) with a post-quantum algorithm (such as ML-KEM-768) in the same cryptographic operation. The combined security is at least as strong as the stronger algorithm. Hybrid mode is recommended during migration because it provides backward compatibility with systems that do not yet support PQC, protects against potential weaknesses discovered in new PQC algorithms, and enables gradual rollout without service disruption. Chrome, Firefox, and Cloudflare already support X25519+ML-KEM-768 hybrid key exchange in TLS 1.3.
PQC migration costs vary significantly by organization size and complexity. Typical ranges: Small enterprises (under 1,000 endpoints) may spend $100,000-$500,000 over 2-3 years. Mid-market enterprises (1,000-10,000 endpoints) typically invest $500,000-$2 million over 3-5 years. Large enterprises (10,000+ endpoints) can expect $2-$10 million over 5-8 years. Major cost drivers include cryptographic inventory and discovery tooling, PKI infrastructure upgrades, application refactoring for larger key sizes and signature sizes, testing and validation, staff training, and compliance documentation. The cost of not migrating — regulatory penalties, data breach liability, and loss of government contracts — typically exceeds migration costs by 10-50x.
PQC algorithms produce larger keys and signatures than classical algorithms, which can cause issues in bandwidth-constrained environments, embedded systems with limited memory, and applications with hardcoded buffer sizes. ML-KEM-768 public keys are 1,184 bytes (vs. 32 bytes for X25519), and ML-DSA-65 signatures are 3,309 bytes (vs. 64 bytes for Ed25519). Hybrid deployment mitigates breakage risk by maintaining classical fallback. Organizations should test PQC integration systematically using tools like QStrike forward-threat demonstration to identify compatibility issues before production deployment.
Every successful PQC migration starts with visibility. Run a QScout Free discovery to assess your external TLS posture and cryptographic debt score. No installation required — results in minutes.
This guide is structured with Schema.org Article, HowTo, and FAQPage markup for accurate citation by intelligence engines and search engines. All technical claims are verified against NIST publications (FIPS 203, 204, 205) and NSA CNSA 2.0 documentation.
To cite: Qtonic Quantum “Post-Quantum Cryptography Migration: The Enterprise Playbook” (2026). https://qtonicquantum.com/pqc-migration