Post-Quantum Cryptography Migration Planning for Enterprises

Why Migration Planning Starts Now

NIST published three post-quantum cryptography standards in 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a hash-based signature alternative. The standards are final. The algorithms are ready. The migration clock is running.

Enterprise PQC migration is not a firmware update you push overnight. It touches every certificate, every key, every TLS handshake, every signed binary, and every encrypted data store in your infrastructure. Organizations with thousands of services, millions of certificates, and decades of accumulated cryptographic dependencies face a multi-year transition.

The harvest-now-decrypt-later (HNDL) threat adds urgency. Adversaries capture encrypted traffic today and store it for future quantum decryption. Data with long secrecy lifetimes is already at risk. Waiting for a confirmed Q-Day date before starting migration guarantees you will finish late.

Phase 1: Inventory

Every PQC migration begins with a complete cryptographic inventory. You cannot replace algorithms you have not found.

Discover all certificates. QCecuring’s CLM platform scans your infrastructure — cloud providers, on-premises servers, load balancers, API gateways, and container orchestrators — to find every TLS/SSL certificate. It reports the signature algorithm, key size, issuing CA, and expiration date for each certificate.

Catalog SSH keys. QCecuring’s SSH KLM discovers SSH key pairs across your server fleet. It identifies key types (RSA, ECDSA, Ed25519), key sizes, and access relationships. SSH keys are often overlooked in migration planning, but they use the same quantum-vulnerable algorithms as TLS certificates.

Map code signing certificates. QCecuring’s Code Signing platform tracks the certificates used to sign software packages, firmware images, and container images. These certificates use RSA or ECDSA signatures that need post-quantum replacements.

Identify cryptographic libraries. Document which libraries provide cryptographic operations in your applications. OpenSSL, BoringSSL, AWS-LC, Java’s SunJCE, and .NET’s CNG each have different PQC readiness timelines. Your migration schedule depends on when your libraries support ML-KEM and ML-DSA.

Record protocol configurations. Document TLS versions, cipher suites, and key exchange algorithms negotiated by each service. TLS 1.2 with RSA key exchange is quantum-vulnerable. TLS 1.3 with ECDHE is also vulnerable. Both need migration to ML-KEM-based key exchange.

The output of Phase 1 is a complete cryptographic asset register — the foundation for every subsequent phase.

Phase 2: Assess

With the inventory complete, classify each cryptographic asset by quantum vulnerability and business risk.

Flag quantum-vulnerable algorithms. RSA (all key sizes), ECDSA, ECDH, DSA, and DH are all vulnerable to Shor’s algorithm. Mark every asset using these algorithms for migration. AES and SHA-2/SHA-3 are quantum-resistant at current key sizes and do not require replacement.

Score by data sensitivity. Apply Mosca’s theorem to each system. Calculate the secrecy lifetime of the data it protects, estimate the migration time for that system, and compare against Q-Day projections. Systems where secrecy lifetime plus migration time exceeds the Q-Day window are already at risk.

Evaluate dependency chains. A single service may depend on certificates from multiple CAs, keys managed by different teams, and libraries maintained by different vendors. Map these dependencies to identify bottlenecks. A CA that does not yet issue ML-DSA certificates blocks every service that depends on it.

Check compliance requirements. Regulatory frameworks are adding PQC mandates. The NSA’s CNSA 2.0 requires ML-KEM adoption by 2030 for National Security Systems. NIST SP 800-131A will update algorithm deprecation timelines. PCI DSS, HIPAA, and SOX auditors will follow. Identify which compliance frameworks apply to your organization and their PQC deadlines.

The output of Phase 2 is a risk-ranked list of cryptographic assets with migration priorities.

Phase 3: Plan

Convert the risk assessment into a concrete migration roadmap with timelines, resource allocations, and success criteria.

Define migration waves. Group systems into migration waves based on risk priority. Wave 1 covers critical-risk systems protecting long-lived secrets. Wave 2 covers high-risk systems with 5-15 year secrecy lifetimes. Wave 3 covers moderate-risk systems that benefit from crypto-agile preparation.

Select target algorithms. For key encapsulation, ML-KEM-768 provides the recommended security level for most applications. ML-KEM-1024 provides higher security for the most sensitive systems. For digital signatures, ML-DSA-65 balances security and performance. SLH-DSA serves as a fallback for environments that need algorithm diversity beyond lattice-based schemes.

Plan for hybrid deployments. Hybrid mode runs classical and post-quantum algorithms in parallel. A hybrid TLS handshake negotiates both ECDH and ML-KEM. If either algorithm fails, the other protects the session. Hybrid deployments reduce risk during the transition and provide backward compatibility with systems that do not yet support PQC.

Allocate resources. PQC migration requires cryptography expertise, infrastructure engineering capacity, testing environments, and vendor coordination. Budget for training, tooling, and the operational overhead of running hybrid configurations.

Set milestones and checkpoints. Define measurable milestones: percentage of certificates migrated, number of services running hybrid mode, count of quantum-vulnerable algorithms remaining. Review progress quarterly.

Phase 4: Pilot

Test PQC algorithms in controlled environments before production deployment.

Deploy ML-KEM in test TLS configurations. Configure test servers with ML-KEM-768 key exchange alongside ECDH. Measure handshake latency, connection establishment time, and bandwidth consumption. ML-KEM public keys are larger than ECDH keys (1,184 bytes vs. 294 bytes), which affects TLS handshake size.

Test ML-DSA certificate chains. Issue test certificates signed with ML-DSA-65. Validate that your certificate chain verification logic handles the larger signature sizes (3,309 bytes vs. 64 bytes for ECDSA P-256). Test with your load balancers, reverse proxies, and client applications.

Validate library compatibility. Confirm that your cryptographic libraries support the PQC algorithms you selected. Test key generation, encapsulation/decapsulation, signing, and verification operations. Verify that library updates do not break existing functionality.

Measure performance impact. PQC algorithms have different performance profiles than classical algorithms. ML-KEM key generation is fast. ML-DSA signing is competitive with RSA-2048. SLH-DSA is slower. Benchmark each algorithm in your specific workload patterns.

Test interoperability. Verify that PQC-enabled services communicate correctly with external partners, cloud providers, and third-party APIs. Interoperability gaps are common in early PQC deployments.

Phase 5: Deploy

Roll out PQC algorithms to production in the order defined by your migration waves.

Start with hybrid mode. Deploy hybrid configurations that use both classical and post-quantum algorithms. This provides quantum resistance while maintaining backward compatibility. Hybrid mode is the recommended approach during the transition period.

Automate certificate renewal with CLM. QCecuring’s CLM platform automates certificate issuance and renewal. As CAs begin issuing ML-DSA certificates, CLM streamlines the transition by automatically renewing expiring RSA/ECDSA certificates with post-quantum alternatives. This eliminates the manual effort of reissuing thousands of certificates.

Rotate SSH keys through KLM. QCecuring’s SSH KLM manages key rotation across your server fleet. When SSH implementations support post-quantum key exchange, KLM automates the transition from RSA and ECDSA keys to PQC-capable alternatives.

Update code signing workflows. Transition code signing certificates to ML-DSA signatures. QCecuring’s Code Signing platform manages the signing workflow, ensuring software packages and firmware images are signed with quantum-resistant algorithms.

Communicate with stakeholders. Notify internal teams, external partners, and customers about algorithm changes. Provide migration guides for API consumers who need to update their TLS configurations.

Phase 6: Monitor

PQC migration does not end at deployment. Continuous monitoring prevents regression and catches new vulnerabilities.

Track algorithm usage. Monitor which algorithms are negotiated in production TLS connections, SSH sessions, and code signing operations. Flag any regression to quantum-vulnerable algorithms.

Audit certificate inventory. Run regular CLM scans to detect new certificates issued with classical algorithms. New services, developer test environments, and shadow IT often introduce RSA or ECDSA certificates outside the migration program.

Monitor standards evolution. NIST selected HQC as an additional key encapsulation standard in 2025. Future updates may adjust security level recommendations or deprecate specific parameter sets. Stay current with NIST publications and update your configurations accordingly.

Review compliance posture. As regulatory frameworks add PQC requirements, verify that your deployed configurations meet the new mandates. Document your PQC posture for auditors.

Prioritization by Data Sensitivity

Not every system migrates at the same pace. Prioritize based on the data each system protects.

Tier 1: Long-lived secrets. Government classified data, healthcare records with 50+ year retention, financial archives, trade secrets, and cryptographic root keys. These face immediate HNDL risk. Migrate first.

Tier 2: Business-critical data. Customer PII, corporate financial data, authentication credentials, and intellectual property with 5-15 year sensitivity. Plan migration within 1-2 years.

Tier 3: Operational data. Session tokens, temporary credentials, and transient communications. Lower HNDL risk due to short secrecy lifetimes. Prepare crypto-agile architectures and migrate when PQC deployment matures.

Hybrid Approaches in Detail

Hybrid cryptography is the bridge between classical and post-quantum security. It provides defense-in-depth during the transition.

Hybrid key exchange. A TLS 1.3 handshake can combine ECDH with ML-KEM. The shared secret is derived from both algorithms. An attacker must break both ECDH and ML-KEM to compromise the session. This protects against the scenario where a PQC algorithm is later found to have a weakness.

Hybrid signatures. A certificate can carry both an ECDSA signature and an ML-DSA signature. Verifiers that support PQC check both. Verifiers that do not yet support PQC fall back to the classical signature. This enables gradual rollout without breaking backward compatibility.

Composite certificates. IETF drafts define composite certificate formats that embed multiple public keys and signatures in a single X.509 certificate. This simplifies hybrid deployments by keeping the certificate infrastructure unified.

The Role of CLM in Migration

Certificate lifecycle management is central to PQC migration because certificates are the most visible and numerous cryptographic assets in most enterprises.

QCecuring’s CLM platform accelerates migration in three ways:

Discovery. CLM finds every certificate in your infrastructure — including certificates in cloud environments, container orchestrators, and IoT devices that manual audits miss. This ensures your migration plan covers the full scope.

Automation. CLM automates certificate renewal. When your CAs support ML-DSA certificates, CLM handles the reissuance workflow. Instead of manually replacing thousands of certificates, teams configure renewal policies and let CLM execute.

Governance. CLM enforces policies on algorithm types, key sizes, and certificate lifetimes. During migration, governance policies can require post-quantum algorithms for new certificate issuance while flagging classical algorithms for replacement.

Common Pitfalls

Skipping inventory. Teams that jump to algorithm selection without a complete cryptographic inventory discover gaps mid-migration. Undiscovered certificates and keys create security holes that persist after the migration is declared complete.

Underestimating scope. Cryptography is embedded in places teams do not expect: third-party SDKs, firmware, IoT devices, legacy systems, and SaaS integrations. The actual migration scope is always larger than initial estimates.

Ignoring third-party dependencies. Your migration timeline depends on your vendors. If a CA does not issue PQC certificates, you cannot migrate certificates from that CA. If a cryptographic library does not support ML-KEM, applications using that library are blocked.

Treating migration as a one-time project. PQC migration is an ongoing program. New services launch with classical algorithms. Standards evolve. Libraries release updates. Continuous monitoring and governance are required to maintain a quantum-resistant posture.

Delaying because of uncertainty. The Q-Day timeline is uncertain. Migration timelines are not. Starting late guarantees finishing late. The organizations that begin now will complete migration before the organizations that wait for certainty.