Post-quantum cryptography (PQC) has officially entered the implementation phase. The first standards are finalized, migration guidance is taking shape, and organizations are being encouraged to begin preparing their infrastructure today.

In August 2024, the National Institute of Standards and Technology (NIST) finalized three PQC standards. ML-KEM addresses the establishment of shared encryption keys, while ML-DSA and SLH-DSA provide new standards for digital signatures. NIST has also selected HQC for future standardization as an alternative to ML-KEM based on different mathematics.

Organizations now face a very important, practical question: how can these standards be introduced across complex infrastructure without causing extremely costly disruptions to the systems they're meant to protect? The answer will vary between environments, but finding it early results in far more control over the transition. In this article, we'll walk through the urgency driving Post-Quantum Migrations, the challenges organizations can expect to face during those migrations, and the steps organizations should take to ensure Post-Quantum readiness in a timeframe that is reasonable and, most of all, secure.

Post-quantum migration reaches across the technology stack

As we explained in our previous articles on quantum computing and post-quantum cryptography, a sufficiently powerful quantum computer is expected to undermine or "break" widely used public-key cryptography such as RSA and Elliptic Curve Cryptography (ECC).

Updating the cryptography used by a single application can be manageable. At enterprise scale, however, the work quickly spreads across three broad areas: connection security, identity and software trust, and long-lived or vendor-controlled technology.

Connection security

Today, public-key cryptography helps establish trusted connections throughout enterprise organizations. Transport Layer Security (TLS) protects public websites and APIs, while Virtual Private Networks (VPNs) and Secure Shell (SSH) secure remote access.

Internal services also rely on encrypted connections. A change at one end of that connection only works if the system at the other end understands the new configuration too.

Identity and software trust

Cryptography also plays the crucial role of establishing whether people, services, and software can be trusted by the organization. It supports authentication systems and digital certificates, and code-signing workflows depend on it to prove that software came from a legitimate source and hasn't been altered.

Changes in this particular category can reach surprisingly far. Replacing one certificate or signature algorithm can affect user authentication, automated deployments, and every single client that validates the result.

Long-lived and vendor-controlled technology

The most difficult category involves systems that organizations can't update quickly. Hardware security modules, for example, may have strict compatibility requirements, and Internet of Things (IoT) devices & embedded firmware can remain in service for years.

Integrated third-party platforms create a different version of that same challenge. Even if the organization understands by themselves exactly what needs to change, they might still have to wait for a vendor to support it.

Each category comes with its own set of owners and designated update cycles. Some changes can happen through an ordinary software configuration; others can require entirely new hardware or a carefully coordinated vendor release.

All in all, that scale makes PQC migration an infrastructure-wide technology program.

Why migration needs to begin before quantum computers arrive

These days, quantum computers are perpetually lurking just beyond the horizon, but the exact distance of that horizon is difficult to determine.

To put it bluntly, there's currently no universally accepted date for the arrival of a Cryptographically Relevant Quantum Computer (CRQC). Forecasts vary because quantum computers still need to overcome some pretty significant engineering challenges, particularly around stability and error correction at scale.

It's understandable if that uncertainty makes urgent PQ migration planning a bit awkward, but waiting for a definitive breakthrough announcement isn't a good idea - it would leave organizations with far too little room to respond calmly. Also, the race to begin exploiting pre-quantum encrypted data has already begun.

Long-lived data creates immediate exposure

As we've described in a prior article, a “harvest now, decrypt later” attack occurs when a threat actor intercepts encrypted information today and stores it until the technology needed to decrypt it (i.e., quantum computing) becomes available.

The strategy is most attractive when information has a long shelf life. Government communications and medical records are obvious examples because they can remain sensitive for decades. Intellectual property and authentication material may also retain their value long after they're originally intercepted by bad actors.

For that particular subset of information, the quantum threat has effectively already begun. Every additional year it remains protected exclusively by quantum-vulnerable cryptography extends the window in which an attacker can collect it for future use.

The migration schedule is already long

One thing's for sure: large organizations will need years to complete a migration of this scale. The work usually moves through three broad phases.

The first phase is discovery. Teams need to locate cryptographic dependencies and understand what each one protects. Coordination then follows, bringing application owners and vendors into the plan. Only then can organizations begin testing changes and moving them into production.

The UK National Cyber Security Centre (NCSC) expects large organizations to spend two to three years on discovery, assessment, strategy, and initial planning alone. Its current guidance recommends completing that initial work by 2028, migrating the highest-priority systems by 2031, and working toward broader completion by 2035.

Those dates make the immediate priority fairly clear. Organizations have time to prepare methodically, but very little of that time is disposable.

Step 1: Build a cryptographic inventory

The first obstacle to post-quantum migration is visibility. Organizations can’t replace cryptography they don’t know they’re using.

A cryptographic inventory should clearly identify where encryption, key establishment, certificates, and digital signatures appear throughout the enterprise environment. This is sometimes formalized as a Cryptographic Bill of Materials (CBOM), which records the algorithms and dependencies associated with each system.

A useful inventory should answer three basic questions.

What cryptography is being used?

The answer to this question includes the active algorithms and the cryptographic libraries implementing them. Library versions matter because two applications may use the same algorithm while having very different upgrade paths.

The overarching goal is to identify where quantum-vulnerable public-key cryptography remains active and which systems already have a practical path toward PQC support.

Where is trust established?

Certificates and certificate authorities form another important layer of the cryptographic inventory. Teams need to understand where TLS connections terminate, when certificates expire, and which systems are responsible for validating them.

Expiration dates can, of course, create natural migration opportunities. A certificate that will be renewed soon may provide a convenient point to test a new configuration, while a certificate embedded in a device could require much more planning.

What depends on each component?

This is by far the most important question. An algorithm or certificate may look isolated until teams actually examine the business services connected to it.

For example, replacing a certificate on a public API could affect a mobile application and perpetuate through several partner integrations. Older clients may only support specific algorithms, while authentication middleware could make assumptions about the certificate format.

A complete CBOM reveals that dependency chain. Once it’s visible, teams can begin planning changes without having to discover every hidden relationship through production failures.

Step 2: Prioritize systems based on risk and data lifetime

A complete cryptographic inventory will likely reveal more migration work than an organization can perform at once. The next step is deciding what deserves attention first.

Three categories provide a practical way to make that decision.

Consequence and confidentiality period

Start by asking what would happen if the protected information became readable. A system containing health records or government information carries an obvious confidentiality risk, while authentication secrets create a different consequence because their exposure could open access to additional systems.

The required protection period matters just as much. Information that must remain confidential for another twenty years has significant "harvest-now, decrypt-later" attack exposure. Data that loses its value within a few days creates a much shorter opportunity for an attacker; that data just won't be a big priority for them.

Systems scoring highly in both areas should move toward the front of the migration plan.

Exposure and business importance

Internet-facing systems provide more opportunities for data interception than isolated services with tightly controlled access. Public APIs and remote-access gateways are therefore natural candidates for early attention.

Business impact affects how that work should proceed, however. A customer-facing service may deserve a high priority while also requiring the most cautious rollout. A poorly tested cryptographic change can create an outage even when the security decision behind it is sound.

That combination calls for an early start and a well-controlled migration window.

Difficulty and external control

Some migration targets will, of course, take far longer than others. Modern software may support new cryptographic configurations through a simple update, while embedded devices or proprietary protocols may require a substantial redesign.

Vendor-controlled products introduce an additional dependency: migration may need to wait for a cloud provider, software vendor, or device manufacturer to add compatible support.

These systems should enter the plan early even when their immediate risk is lower. A long replacement cycle can turn an apparently distant problem into one of the first projects an organization needs to begin.

Together, these categories help teams distinguish urgent systems from long-lead-time systems. Both deserve early attention, but for very different reasons.

Step 3: Establish ownership across the organization

This is where post-quantum migration stops being a security concept and becomes an actual company project.

The technical side needs a clear owner for each migration target; switching on a new algorithm is the smallest part of that job. The owner also needs to understand what depends on the current configuration, how the change will be tested, and what happens if an important client suddenly stops connecting.

The business side has a different role. Business owners need to decide how much disruption is acceptable and when the change can realistically happen. Updating cryptography on a customer-facing payment service, for example, deserves much more careful scheduling than updating a low-impact internal tool.

Procurement deserves equal attention. Long-lived purchases such as network appliances and embedded devices could remain in service throughout much of the PQC transition. If a vendor can’t explain how its product will support new standards, the organization may be buying a future migration problem.

Without that coordination, teams can end up removing quantum-vulnerable technology with one hand and purchasing more of it with the other.

Step 4: Design for crypto agility

The good news is that post-quantum migration can leave an organization better prepared for whatever cryptographic change comes next.

Algorithms evolve. Future research may expose weaknesses, and standards will continue to mature as the whole industry gains more real-world experience with PQC.

The National Institute of Standards and Technology (NIST) defines crypto agility as the ability to replace or adapt cryptography while preserving security and ongoing operations. Its current crypto-agility guidance treats the post-quantum transition as an opportunity to make future migrations less disruptive.

In practice, crypto agility has two primary ingredients.

The first is separation: cryptographic policy shouldn’t be buried inside an application’s core business logic. When algorithms and business logic are tightly connected, every cryptographic transition becomes an expensive development project. Separating them allows an application to accept a new key format or certificate configuration without changing how the underlying business service works.

The second ingredient is control: organizations need to see which cryptography is active and change it from a manageable point. If an algorithm is deprecated, teams should be able to find the remaining dependencies and disable it without searching through the company's entire code base.

NIST’s selection of HQC shows why this flexibility matters. HQC is being standardized as an alternative based on different mathematics in case a weakness is discovered in ML-KEM (the final HQC standard is currently expected in 2027).

A durable strategy assumes that algorithms will continue to change. The infrastructure should make those changes feel routine rather than exceptional.

Step 5: Evaluate hybrid post-quantum deployment

Hybrid cryptography offers organizations a useful middle ground.

As the wording suggests, hybrid configuration combines a conventional cryptographic mechanism with a post-quantum mechanism. This preserves support for established cryptography while adding protection against future quantum attacks. With this approach, organizations can begin moving forward without immediately leaving every existing client behind.

Hybrid deployment still introduces two major risks, however.

The first is compatibility. Older clients may not understand the new handshake, and as any IT decision-maker will know, network infrastructure can create surprises of its own. A proxy that handles conventional Transport Layer Security (TLS) traffic without difficulty may struggle with unfamiliar key sizes or message formats.

The second risk is a real killer: false confidence. This one deserves particular attention.

A connection might use post-quantum key establishment while continuing to rely on a quantum-vulnerable signature for authentication. An unsupported client might also trigger a fallback to classical cryptography without making that downgrade obvious. Everything can appear to be working even though the connection has less protection than the team expects.

Performance still matters, of course, but the central test is simpler: did the production connection actually negotiate the intended protection?

All told, enabling hybrid support starts the process and verifying its real production behavior completes it.

Step 6: Pilot migration where traffic converges

This practically goes without saying, but a focused pilot is much easier to learn from than an enterprise-wide first attempt.

Quite conveniently, the infrastructure layer where traffic already converges provides arguably the best starting point. Reverse proxies and API gateways are strong examples: both can sit in front of multiple services and manage encrypted connections at a controlled boundary. Depending on the architecture, a load balancer or ingress controller may serve the same role.

This mercifully reduces the initial scope of the project. If one shared connection point can introduce protection across multiple applications, teams have a chance to really understand PQC behavior before deeper application changes begin.

A pilot needs to answer two basic questions:

1. Is the cryptography working as intended? Connections should negotiate the correct protection without an unsafe fallback.
2. Does the service continue operating normally under real traffic?

Legacy clients deserve special attention here, since current browsers and updated development tools tend to follow the "happy" path. The real compatibility surprises are more likely to come from an old mobile application or a partner integration that hasn’t changed at all in six years.

That’s exactly the type of thing a pilot should uncover. Every exception found at this stage is one less surprise waiting in a larger rollout. For larger enterprises in particular, those "surprises" pile up quickly if the pilot isn't by-the-book.

Step 7: Keep post-quantum readiness current

The first successful PQC deployment marks the beginning of the operational phase. The environment will keep moving, and internal teams will deploy new applications and renew certificates. Vendors will release updated products while retiring older ones. With all that progress, a static cryptographic inventory can become outdated surprisingly quickly.

The most important question, though, is what cryptography systems are actually using. Any given service may fully support PQC while most production clients continue negotiating a classical option.

With that in mind, visibility into real connection behavior is particularly valuable. Organizations need to clearly see which algorithms are being negotiated and where fallback still occurs, and they should also know which remaining migrations are waiting on vendor support.

With regular upkeep, the original cryptographic inventory becomes a practical way to keep risk from quietly building up again.

A managed path to post-quantum readiness with Cloudmersive Shield

Shield, Cloudmersive's fully-managed enterprise reverse-proxy server, makes post-quantum migration significantly easier by moving the first major implementation step to a managed reverse-proxy layer. Shield can sit in front of existing services, introduce post-quantum protection at a controlled traffic boundary, and allow the applications behind it to continue operating normally.

That shared layer changes the scale of the whole project. Application teams avoid taking on separate PQC implementation projects, while the organization gains one coordinated point for managing client compatibility and controlling the rollout.

The managed model also gives organizations a clear, guided way to navigate standards that are still evolving. Protection can begin at a high-value infrastructure boundary, expand through deliberate phases, and adapt as PQC requirements mature.

With Cloudmersive Shield, post-quantum migration shifts from a broadly scoped challenge to a focused infrastructure rollout with a clear starting point. Organizations can begin protecting important services sooner without waiting for every application team to develop its own post-quantum expertise.

Key takeaways

Algorithm replacement is one part of post-quantum migration. The larger effort involves understanding where cryptography appears, deciding what needs protection first, and creating a realistic way to introduce the widespread change PQ readiness requires across the environment.

Fortunately, organizations can approach that work in stages. The first priority is visibility: teams need to know where vulnerable cryptography exists and which systems protect information that will still matter years from now. From there, they can assign ownership and begin focusing on the areas where migration will have the greatest impact.

The transition also creates an opportunity to improve the environment itself. Better cryptographic visibility and more flexible infrastructure will make future changes easier, whether they’re driven by quantum computing or by an entirely different security development.

Starting early leaves room to test, learn from mistakes, and adjust & improve. That’s a far better position than allowing a future quantum breakthrough to set the migration schedule for you.

For expert guidance on planning and managing your organization’s transition to post-quantum protection with Cloudmersive Shield, contact the Cloudmersive sales team.