PQC Migration Strategy: Start One Layer At a Time

Post-quantum cryptography (PQC) migration is no longer a planning exercise. The standards are published, the deadlines are in place, and the Harvest Now, Decrypt Later (HNDL) threat is already active. The challenge now is execution.

Most security teams already know the situation: NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) on August 13, 2024, and NSA’s CNSA 2.0, originally published September 2022 and updated through FAQ v2.1 in December 2024, sets phased deadlines by system type for newly procured National Security Systems, with new acquisitions required to support quantum-safe algorithms from January 1, 2027, and exclusive-use dates ranging from 2030 for firmware and networking equipment to 2033 for operating systems, web services, and cloud infrastructure.

The problem is not knowing what needs to happen. It is figuring out where to start when everything feels equally urgent. A full PQC migration is large, and it eventually touches TLS certificates, VPN tunnels, code signing, certificate authorities, HSMs, and applications at every layer, from network infrastructure down to individual services and endpoints. Trying to map all of that before making a single change is how programs stall, with teams spending months building comprehensive roadmaps while nothing actually gets protected.

What most teams miss is that you do not need to migrate everything at once to meaningfully reduce your risk. In a layered encryption stack, migrating even one layer to quantum-safe key exchange can protect the payload inside it from HNDL collection, which changes what starting looks like entirely. Instead of trying to move everything at the same time, you pick the layer that gives you the most protection for the least operational disruption and move that first. This blog walks through four enterprise scenarios and shows where that layer is for each one.

Why Starting With One Layer Makes Sense

Think about how your traffic is protected today. A VPN wraps a TLS session, that TLS session might wrap application-layer encryption on top, and each layer has its own session key that is independent of the others. This architecture is actually good news for PQC migration. An HNDL attacker capturing your traffic today cannot recover the payload if the layer protecting that payload uses quantum-safe key exchange, and ML-KEM, standardized in FIPS 203, is designed to resist attacks from a cryptographically relevant quantum computer (CRQC). One migrated layer stops the HNDL threat for everything protected inside it.

There is an important distinction to keep in mind. This protection applies to confidentiality only, and authentication is a different problem entirely. Every layer that uses RSA or ECDSA for authentication needs to migrate too, but that is a separate workstream with a different urgency level:

• Adversaries are actively harvesting encrypted data today to decrypt it once quantum computers become capable, making the HNDL threat a current operational risk, not a future one.
• Authentication attacks require a real-time CRQC, which is still further out.

That means confidentiality migration is the more pressing problem right now, and authentication migration is the longer, harder project you need to start planning in parallel.

With that framing in place, here is what actually determines which layer to migrate first.

What Makes a Good First Layer

Not all layers are equal when it comes to migration effort versus protection gained. Four things determine which one to move first:

Centralization

A layer you can update in one place and protect thousands of users is worth far more than one requiring changes on every endpoint. VPN concentrators, load balancers, and certificate authorities are centralized; client devices and individual application servers are not. Go centralized first.

What It Actually Covers

Migrating the outermost layer of your stack protects both payload and connection metadata, whereas migrating an inner layer protects the payload but leaves metadata exposed. Depending on your threat model, that distinction matters.

Whether You Can Do It Today

Some layers are fully under your control, while others depend on vendor firmware updates, protocol standards, or changes requiring ecosystem-wide coordination. The best first layer is one you can actually move now.

Whether It Uses Public-Key Cryptography at All

Layers using only symmetric cryptography, like AES-256 session encryption or HMAC-SHA-256 for integrity, have no Shor-algorithm vulnerability and can wait. Any layer using RSA, ECDH, or ECDSA for key exchange or authentication is your immediate focus.

These four questions narrow things down quickly. Here is how they play out across the four scenarios that come up most often.

Scenario 1: Enterprise PKI and Internal Certificate Infrastructure

PKI is where most organizations feel the pressure most acutely, and it is also the layer with the longest lead time, which is exactly why it needs to start first. Most TLS certificates in production environments use RSA or ECDSA today, and replacing them with ML-DSA or hybrid alternatives requires updating:

• The issuing CA and root certificates
• Certificate profiles across every template
• Every system that validates signatures
• The HSMs holding the CA private keys

None of that is fast. A CA issuing ML-DSA certificates under a root that still uses RSA leaves a classical weak link in the chain, so the migration needs to be planned as a coordinated effort. Phased and hybrid approaches are supported by NIST and are often the practical path, but the dependencies between components mean planning must start early.

Where To Start: Internal PKI First

The good news is that your internal PKI is fully under your control, with no need for browser root program approval, CA/B Forum ratification, or coordination with any public CA. You can start issuing hybrid certificates for internal use today, combining an ML-DSA signature alongside the existing ECDSA or RSA signature, so systems that support ML-DSA get quantum protection while systems that do not yet support it fall back to the classical component without breaking anything. You start building the foundation for a migration that will eventually need to cover your entire certificate estate.

The external PKI story is harder, since publicly trusted TLS server certificates are tied to browser root programs, CA compliance audits, and standards bodies that move slowly. That migration will happen, but it will take years, and you should not let it block your internal work.

One date worth keeping in mind: under NIST IR 8547, currently an initial public draft as of mid-2026, lower-security classical algorithms such as RSA-2048 and ECC P-256 are targeted for deprecation by 2030 and disallowance by 2035. That sounds distant until you count the time needed to update certificate profiles, re-issue every certificate, and validate every relying party.

Getting your internal PKI moving is the right first step, but there is a parallel track that can deliver HNDL protection even faster.

Scenario 2: VPN and IPsec Site-to-Site Tunnels

VPN concentrators are one of the clearest examples of centralized control in enterprise security, where one configuration change at the concentrator protects traffic for every user and every site flowing through it without touching a single endpoint. Most enterprise site-to-site VPN deployments use IKEv2-based IPsec with ECDH or classic Diffie-Hellman key exchange, both of which are vulnerable to Shor’s algorithm. An HNDL attacker capturing that traffic today stores the ciphertext alongside the key exchange transcript, and when a CRQC arrives they can work backward from the transcript, derive the session keys, and decrypt everything that ever went through that tunnel.

The RFC 9370 Fix

RFC 9370, published by the IETF in May 2023, addresses this directly by defining a multiple key exchange framework for IKEv2 that lets you chain an additional key exchange round into the handshake. You run ML-KEM alongside the classical ECDH exchange, and the derived session key depends on both, meaning breaking just the classical component no longer gives the attacker the session key. Several major VPN vendors have shipped hybrid ML-KEM support for IKEv2, and in many environments enabling it is a configuration change rather than a hardware refresh, so check your current firmware release notes before assuming otherwise.

This is the single-layer principle working as intended: one change at the concentrator, and the traffic inside that tunnel gets quantum-safe confidentiality against HNDL regardless of whether the applications behind it have started their own PQC migrations. VPN peer authentication still uses RSA or ECDSA certificates in most deployments, so the authentication side still needs to move eventually, but that is the PKI migration workstream and the HNDL protection from the hybrid IKEv2 key exchange is independent of it.

For organizations that deal in signed software or firmware, there is a scenario where authentication migration actually cannot wait.

Scenario 3: Code Signing and Software Supply Chain

Code signing is one of the few places where the urgency of authentication migration starts to match the urgency of confidentiality migration, and the reason is shelf life. A signed firmware binary created today might be installed on a device years from now, and if the device validates that signature at install time while a CRQC can forge signatures using the original RSA or ECDSA key, a malicious update passes validation with no warning. The long life of signed artifacts means you are not just protecting against future real-time attacks but also against the possibility that a future attacker retroactively forges signatures on artifacts that are still being trusted years from now.

Choosing the Right Algorithm

CNSA 2.0 addresses this directly by mandating ML-DSA (FIPS 204) for digital signatures in National Security Systems. For organizations outside that scope, ML-DSA and SLH-DSA (FIPS 205) are both available as finalized NIST standards:

• ML-DSA is generally faster to sign and verify and is the primary choice for most deployments.
• SLH-DSA has a more conservative mathematical foundation because it relies only on hash function security rather than lattice hardness assumptions, making it a good backup option.

One important note: SLH-DSA is suitable for general enterprise use but is not included in CNSA 2.0 for National Security Systems. Organizations in the NSS supply chain should use ML-DSA-87 as their primary signature algorithm per CNSA 2.0 requirements. For firmware and software signing in NSS environments specifically, CNSA 2.0 also approves the stateful hash-based schemes LMS and XMSS defined in NIST SP 800-208, and NSA’s preferred parameter set is LMS with SHA-256/192.

The HSM Bottleneck

The most common constraint for code signing migration is the HSM, since not all HSMs support ML-DSA in current firmware, and you should confirm that any HSM’s PQC support is FIPS 140-3 validated rather than simply firmware-present, given that FIPS 140-2 certificates move to Historical status in September 2026. Some will get there via a firmware update while others require hardware replacement, and you need to know which category your HSMs fall into before finalizing a migration plan because that determines the timeline for everything downstream.

HSM readiness isn’t just a code signing problem. It’s the same constraint that determines how quickly you can move on TLS termination.

Scenario 4: TLS Termination at the Network Edge

If you run a load balancer, reverse proxy, or API gateway that terminates TLS, this is likely your fastest and cleanest first move. Chrome 124, released in April 2024, shipped a hybrid post-quantum TLS key exchange using X25519Kyber768 as a pre-standard experiment, and Chrome 131, released in November 2024, updated to the finalized ML-KEM hybrid using codepoint 0x11EC aligned with FIPS 203. According to Cloudflare, over two-thirds of browser traffic reaching its network now uses post-quantum key exchange in the TLS handshake, and if your termination layer does not support that codepoint, the browser silently falls back to classical ECDH with neither side notifying you.

What Enabling Hybrid ML-KEM Actually Changes

Enabling ML-KEM hybrid key exchange at the TLS termination layer changes this. The server accepts the ML-KEM key share, runs the hybrid handshake, and the session key is derived from both the classical X25519 component and the ML-KEM component, so if either one is ever broken the other still protects the session. The operational impact is low:

• No changes to backend applications
• No certificate replacement required
• No client coordination needed
• One configuration change on the termination layer

OpenSSL 3.5, released April 8, 2025, includes native support for ML-KEM, ML-DSA, and SLH-DSA, and changed its default TLS keyshares to offer X25519MLKEM768 and X25519 out of the box. If your load balancer or reverse proxy runs on OpenSSL 3.5, enabling hybrid PQC key exchange may be as simple as a cipher suite configuration update, though you should check your specific vendor’s documentation to confirm what is required in your environment.

Note: X25519MLKEM768 uses X25519, which is not a FIPS-approved curve, so FIPS-only environments should use SecP256r1MLKEM768 instead, which combines P-256 with ML-KEM-768 using codepoint 0x11EB and keeps every primitive in the chain on the FIPS-approved list.

Where Each Scenario Stands

Layer	HNDL Risk	Best First Move	Key Dependency
TLS edge termination	High, all inbound traffic	Hybrid ML-KEM key exchange	OpenSSL 3.5 or vendor TLS update
Site-to-site VPN (IKEv2)	High, all tunneled traffic	RFC 9370 hybrid key exchange	Vendor firmware support
Internal PKI and CA hierarchy	High, long-lived auth chain	Hybrid ML-DSA certificates	HSM ML-DSA support
Code signing	High for long-lived artifacts	ML-DSA signing keys and chain	HSM firmware or hardware refresh

Once you have picked your first layer and moved it, the next question becomes what the authentication side looks like and how much time you actually have.

The Authentication Gap You Cannot Ignore

Across every scenario above, the same pattern comes up: confidentiality migration is doable now with bounded scope and clear paths, while authentication migration is harder, slower, and runs through the PKI hierarchy and the HSMs sitting under it. NIST IR 8547, currently an initial public draft, targets lower-security classical algorithms such as RSA-2048 and ECC P-256 for deprecation by 2030, with full disallowance of all quantum-vulnerable public-key algorithms by 2035. CNSA 2.0’s acquisition deadline of January 1, 2027, already has organizations in the National Security Systems supply chain inside the compliance window, and root CAs, intermediate CAs, HSMs, OCSP responders, and the certificate validation code in every relying party all need to move.

The organizations that struggle to meet these timelines will not be ones that underestimated the quantum threat. They will be the ones that:

• Started their cryptographic inventory too late
• Discovered mid-program that their HSMs needed hardware replacement
• Found a business-critical application that depended on a certificate profile that took months to change

Starting the inventory now, even if your first migration is still weeks away, is what creates the room to finish on time.

How Encryption Consulting Can Help

If you are wondering where and how to begin your post-quantum journey, Encryption Consulting is here to support you every step of the way through our PQC Advisory Services.

We begin with a Cryptographic Discovery and Inventory, scanning your entire environment to identify certificates, keys, algorithms, and protocols across endpoints, applications, APIs, and infrastructure, building the baseline you need before any migration can begin. From there, we conduct a PQC Assessment to evaluate your exposure to quantum threats, identify RSA and ECC-dependent systems, and deliver a prioritized report of vulnerable assets with risk severity ratings.

With that clarity, we develop a PQC Strategy and Roadmap: a phased migration plan aligned to your risk appetite, regulatory requirements, and long-term security goals, including cryptographic agility so your systems can adapt as standards evolve. We then support Vendor Evaluation and Pilot Testing, helping you select the right tools, run proof-of-concept tests, and validate interoperability before any full-scale rollout, before finally managing full implementation across your PKI, signing infrastructure, and TLS configurations with monitoring aligned to your long-term cryptographic health.

CBOM Secure

Encryption Consulting’s CBOM Secure gives a clear view of your cryptographic posture across environments. Instead of dealing with spreadsheets, manual OpenSSL outputs, or scattered configuration files, it shows which algorithms are in use, what needs to change for post-quantum security, and whether systems meet your security policy. It automates crypto inventories, checks TLS configurations, validates algorithms, and aligns policies so teams can move from discovery to action without guessing.

CodeSign Secure

Getting started with post-quantum signatures can feel like a lot of new algorithms, key sizes, integration work, and compliance questions, and that is exactly where CodeSign Secure comes in. It supports ML-DSA along with other NIST-approved algorithms, and whether you are signing software, firmware, documents, or certificates, it handles the technical details so you do not have to. It offers:

• ML-DSA support in signing workflows
• Integration with your existing PKI and HSM setups
• Automation hooks for CI/CD tools
• Secure key storage options
• Compliance-friendly audit trails

If your team is looking to test or roll out post-quantum signatures without building everything from scratch, we are happy to help.

Conclusion

PQC migration is urgent and it is doable. The standards are finalized, the tools are available, and the deadlines are set, so what is left is execution. Start with the layer that is most centralized, most exposed to HNDL risk, and most within your control today, which for most organizations means TLS edge termination or the VPN concentrator. From there, the internal PKI and HSM assessment runs in parallel, code signing follows based on artifact shelf life, and external certificate infrastructure comes last, paced by the broader public PKI ecosystem.

Every layer you migrate stops the accumulation of HNDL-exposed traffic for everything inside it. One layer migrated today is real protection, and a complete plan that never ships is not.