Post-Quantum Migration Is Now a Program-Management Problem

Introduction

In August 2026, the IETF published a standards-track specification for hybrid post-quantum key agreement in TLS 1.3.

A month earlier, Microsoft added hybrid post-quantum key exchange to Windows Server 2025. Google Cloud has begun moving public endpoints and load balancers toward ML-KEM and published a roadmap targeting its own PQC migration by 2029. NIST says its first three finalized post-quantum standards are ready to implement now.

The cryptography is no longer waiting for a hypothetical future before entering production infrastructure, and the migration problem is no longer waiting either.

The UK National Cyber Security Centre expects large organizations to need two to three years merely to discover where vulnerable public-key cryptography exists, assess it, define a migration strategy and build an initial plan. Its first major target is 2028, followed by high-priority migration by 2031 and broad completion by 2035.

That changes the executive question from which post-quantum algorithm security architects prefer to whether an enterprise can identify thousands of cryptographic dependencies, understand when their vendors will support replacement mechanisms, sequence changes without breaking interoperability, fund hardware and software refreshes, and complete the work before old cryptography becomes an unacceptable dependency.

Post-quantum migration has become a program-management problem.

At a glance

• NIST-standardized post-quantum algorithms are available now, while protocol and platform support accelerated materially during 2026.
• Large enterprises may need years just to discover where vulnerable public-key cryptography sits and map the dependencies around it.
• TLS, certificates, code signing, PKI, hardware roots of trust and application cryptography will not all move on one schedule.
• Vendor readiness, equipment lifecycle and interoperability can determine migration timing as much as the cryptographic standard itself.
• The organizations best positioned for PQC will know what uses cryptography, how long it must remain secure, what it depends on and how difficult it will be to replace.

The standards question is no longer blocking the first migration work

For years, a reasonable objection to large-scale PQC migration was that the standards were still being selected. That position is harder to sustain now.

NIST’s first three finalized post-quantum standards—FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA—are ready for implementation. NIST now states directly that organizations should begin migrating to the new standards.

Standards work has not stopped. NIST is still evaluating additional signature algorithms, and application-specific specifications continue to evolve. In June 2026, for example, NIST released working drafts for adding post-quantum mechanisms to Personal Identity Verification credentials.

That continuing work does not make enterprise preparation premature; it makes the migration uneven. Some cryptographic uses already have standardized algorithms and deployable product support, while others are still waiting for protocol, platform or ecosystem changes.

The enterprise program has to manage both conditions at once.

2026 made post-quantum deployment something enterprises can test

The year has produced an important change in implementation maturity.

In August, the IETF published RFC 10024, defining hybrid TLS 1.3 key-agreement mechanisms that combine ML-KEM with traditional elliptic-curve Diffie-Hellman.

Microsoft’s July Windows Server 2025 update added support for hybrid post-quantum key exchange in TLS 1.3. Microsoft has also introduced ML-DSA support in Active Directory Certificate Services on updated Windows Server 2025 systems and is preparing changes to the wider Windows code-signing ecosystem.

Google Cloud’s June load-balancing update introduced hybrid X25519MLKEM768 key exchange for TLS 1.3, initially as an opt-in capability. Its rollout moves to default enablement beginning in October 2026, with customers retaining an opt-out period before a later mandatory stage.

In July, Google Cloud KMS made ML-DSA and SLH-DSA signing algorithms generally available, alongside tooling that helps identify asymmetric keys susceptible to future quantum attacks.

AWS extended hybrid ML-KEM TLS support across Secrets Manager clients in April, allowing supported client versions to negotiate post-quantum key exchange with the service.

These releases do not prove that an enterprise estate is ready. They show that the practical testing window has opened.

Discovery is part of the schedule, not a preliminary checkbox

A migration plan cannot begin with “replace RSA.”

An enterprise first has to know where RSA, elliptic-curve cryptography and other quantum-vulnerable public-key mechanisms are being used. That is difficult because cryptography may be embedded in TLS termination, VPNs, SSH, application libraries, certificate authorities, code signing, device identities, firmware validation, HSM configurations, SaaS integrations, service meshes, backup systems and third-party appliances.

Some of it will be visible in centralized platforms. Some will sit inside products whose owners do not think of themselves as running cryptographic infrastructure.

NIST’s Migration to Post-Quantum Cryptography project now has an entire workstream devoted to Cryptographic Visibility and Risk Management, focused on building and maintaining a comprehensive cryptographic inventory that can guide migration.

The US federal approach began with the same problem. OMB directed agencies to maintain prioritized inventories of systems containing cryptography vulnerable to a cryptographically relevant quantum computer, with annual reporting continuing toward the 2035 migration objective.

The inventory therefore cannot be a one-time spreadsheet created by the security team. It has to become a maintained view of cryptographic dependency; otherwise migration plans begin ageing before implementation starts.

The estate will not move on one clock

One of the easiest ways to underestimate PQC migration is to assign a single completion date to “cryptography.”

A cloud load balancer can receive new TLS capabilities through a managed-service update.

A certificate authority may require operating-system updates, new cryptographic providers and changes to certificate profiles.

A code-signing chain can involve build systems, verification software, trust stores, long-lived certificates and third-party distribution platforms.

An industrial device or hardware root of trust may not be upgradeable at all.

NCSC’s migration guidance explicitly tells organizations to identify dependencies on suppliers and physical infrastructure and to account for long-lived hardware roots of trust in their initial planning.

Microsoft’s 2026 product changes illustrate the same point from another direction: hybrid TLS support arrived through a Windows Server update, PQC certificate support in AD CS has its own platform requirements, and code signing is being handled as a separate ecosystem transition.

The cryptographic algorithms may come from the same NIST family, but the migration work does not arrive as one release.

Key exchange may move before signatures and PKI

Much of the visible deployment progress is currently around protecting network sessions against capture-now, decrypt-later risk.

Hybrid key exchange is attractive because it can add ML-KEM while retaining a traditional mechanism during the transition. RFC 10024 standardizes that approach for TLS 1.3, and cloud providers are already putting it into production.

Other cryptographic uses have different constraints.

Digital signatures may need to remain verifiable for many years. Certificate formats and PKI infrastructure have to support new algorithms. Devices and applications must process larger keys, signatures or messages. Trust chains may span software that upgrades on very different schedules.

NIST’s June PIV drafts are a useful example: incorporating ML-DSA and ML-KEM into federal identity credentials requires changes across the algorithm profile, command interface and data model rather than a single algorithm substitution.

Google’s own roadmap separates key exchange, key management, digital signatures, certificate work and hardware-backed services into different migration milestones. The company is targeting completion of its broader Google Cloud migration by 2029 rather than representing PQC as one product switch.

“TLS is ready” and “the company is quantum-safe” are not equivalent statements.

Enterprise plans need to reflect that difference.

Supplier readiness can sit on the critical path

Most large organizations do not control every cryptographic implementation they use. They consume cryptography through network appliances, SaaS platforms, operating systems, HSMs, libraries and hardware whose security functions may not be independently replaceable.

PQC migration therefore has a supply-chain schedule.

NCSC specifically tells organizations to communicate migration requirements to suppliers during the initial planning period and identify supplier dependencies before later migration phases.

For procurement teams, that creates questions which did not need to be routine several years ago:

When will the product support NIST-standardized PQC?

Which functions are supported—key establishment, signing, certificates or all three?

Is support hybrid, pure post-quantum or configurable?

Does enabling it require new hardware, firmware, licenses or client versions?

How will old and new versions coexist during rollout?

What is the vendor’s deprecation plan for quantum-vulnerable mechanisms?

These are program dependencies because an enterprise cannot migrate a component before the surrounding ecosystem can interoperate with it.

Hybrid deployment makes coexistence a normal migration state

Most enterprises will spend years with traditional and post-quantum cryptography operating together.

That is already visible in current deployments.

RFC 10024 deliberately defines hybrid mechanisms combining ML-KEM and traditional ECDHE. Google’s load balancers use X25519MLKEM768. AWS describes hybrid post-quantum key exchange as the current industry norm for protecting TLS connections while migration progresses.

Coexistence reduces some transition risk because organizations do not have to abandon established cryptography immediately, but it creates another kind of operational work.

Teams need to know when negotiation used PQC, which clients cannot support it, whether middleboxes interfere, what fallback occurred, and whether policy permits that fallback for the data being protected.

Google’s staged load-balancer rollout makes this visible. The service begins with opt-in testing, moves to default enablement with an opt-out period, and later removes the deferral option.

That is migration as controlled compatibility change, not just cryptographic configuration.

Crypto agility determines how painful the next change will be

PQC is unlikely to be the last cryptographic transition an enterprise faces.

Algorithms can weaken. Implementations can fail. Standards change. Protocol choices evolve.

NIST’s updated guidance defines cryptographic agility as the ability to replace and adapt algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations.

That turns crypto agility from an elegant architecture principle into a program-cost issue.

A hard-coded algorithm buried inside a product creates a future project.

A cryptographic dependency that can be discovered, policy-managed, upgraded and observed through a supported interface creates a change process.

PQC migration gives enterprises a reason to distinguish the two while they still have time. The objective should not be to complete an enormous one-off replacement and leave another generation of hard-coded assumptions behind; it should be to emerge with better control over cryptography than the organization had before the migration began.

2028 is closer than it looks from an unknown estate

NCSC’s 2035 completion date can sound distant. Its earlier milestone is more revealing.

By 2028, large organizations are expected to have completed discovery and assessment, defined migration goals and produced an initial plan covering the estate.

The agency estimates that discovery, strategy and initial planning alone can take two to three years.

For an organization starting in late 2026 with no reliable cryptographic inventory, 2028 is not a distant technical target.

It is an active program deadline.

The work between now and then is unlikely to be dominated by cryptographers choosing between mathematical constructions. Much of it will sit with security architecture, infrastructure, IAM, application teams, PKI owners, procurement, asset management, risk functions and vendors.

Standards have advanced far enough that organizational readiness is becoming the slower variable.

FAQs

What is post-quantum cryptography migration?

Post-quantum cryptography migration is the transition from public-key cryptography vulnerable to sufficiently capable quantum computers toward quantum-resistant algorithms and protocols. It includes identifying vulnerable cryptography, prioritizing systems, upgrading products and protocols, testing interoperability and eventually retiring obsolete mechanisms.

Do companies need to wait for a cryptographically relevant quantum computer before migrating?

No. NIST states that its first three finalized PQC standards are ready for implementation, while the NCSC recommends completing discovery and initial migration planning by 2028. Migration is expected to take years, which is why preparation is occurring before a cryptographically relevant quantum computer exists.

What are ML-KEM and ML-DSA?

ML-KEM is NIST’s standardized post-quantum key-encapsulation mechanism under FIPS 203. ML-DSA is its module-lattice-based digital-signature standard under FIPS 204. They address different cryptographic functions and should not be treated as interchangeable components of a migration.

Why are companies using hybrid post-quantum cryptography?

Hybrid mechanisms combine a post-quantum algorithm with established classical cryptography during transition. Current TLS deployments commonly pair ML-KEM with ECDHE, allowing organizations to gain post-quantum protection while retaining the security and interoperability properties of an established mechanism.

What should an enterprise do first for PQC migration?

The first practical requirement is cryptographic visibility: identify where quantum-vulnerable public-key cryptography is used, what data and processes it protects, which products and suppliers it depends on, and how difficult those dependencies will be to change. That inventory provides the basis for prioritization and sequencing.

The migration deadline begins before the cryptography deadline

A future quantum computer is the reason the migration exists.

It is not the date an enterprise should use to decide when to begin.

The schedule is set by slower things: discovering undocumented cryptography, replacing long-lived infrastructure, waiting for vendors, testing interoperability, coordinating certificate and signing changes, and moving systems whose maintenance windows may be measured in years.

By late 2026, enough of the standards, protocols and product support are real that waiting is itself becoming a program decision.

The cryptographic algorithms may be new. The management problem is familiar.

An enterprise needs to know what must change, what it depends on, who owns it, when the surrounding ecosystem will be ready and how much time remains to migrate without forcing the change under crisis conditions.