New Algorithms, Old Infrastructure: Why Post-Quantum Migration Takes Years

Part 1 concluded that the threat is future but the migration is present, and we promised to explain why that migration is so difficult.

At first glance, post-quantum migration looks like an algorithm upgrade, where you replace the vulnerable cryptography, update the libraries, renew the certificates, and move on. But cryptography is rarely an isolated component, because it is embedded in systems, processes, products, and trust relationships.

Take a customer portal: updating its public-facing connection is one change, but updating the certificates, devices, applications, suppliers, and partner integrations that keep it running is a much larger undertaking. Beyond choosing new algorithms, organizations have to find where public-key cryptography is used, work out which systems depend on it, and coordinate changes without disrupting the services people rely on every day.

Public-key cryptography worked so well that it became invisible within our infrastructure. That success is now the migration problem.

How Public-Key Cryptography Ended Up Everywhere

In 1976, Whitfield Diffie and Martin Hellman published the work that introduced public-key cryptography. For years, it remained largely a research technology. The internet then gave it an enormous practical purpose, allowing parties that had never met to establish protected communications and verify identities. As online commerce expanded, cryptography became part of the infrastructure that made it possible.

Bart Preneel estimates that tens of billions of libraries and applications, running on billions of devices, now rely on public-key cryptography, although this is an indication of scale rather than a count [1].

That footprint built up through countless ordinary decisions: organizations bought applications, connected services, installed equipment, and adopted cloud platforms, and cryptography arrived with all of them, often as a default dependency. Over time it became embedded in systems whose owners rarely had to think about the underlying algorithms.

Where It Actually Lives

We rely on cryptography for much more than secure web browsing. It protects VPN and SSH connections, verifies the software updates our devices install, supports secure card payments, and lets cloud services and other systems prove their identity through certificates.

Preneel’s washing-machine example brings this closer to home. It is now hard to buy one without an app, and switching the app off costs you functions, so the machine ends up on the internet [2]. Behind that convenience sit a manufacturer’s cloud service, device identities, and software updates, each of which may introduce cryptographic dependencies. Multiply that pattern across industrial sensors, vehicles, medical equipment, and smart meters, and the scope of migration becomes clearer.

A server administrator may be able to update a library this week, but a device already installed in a customer’s home or factory may have a much narrower update path. PQC migration is therefore a product, supplier, and embedded-systems problem as well as a data-center problem.

No One Owns the Whole Picture

Ask an organization where it uses RSA, Diffie-Hellman, or elliptic-curve cryptography, and the answer usually depends on who you ask.

Security teams may know the public-facing certificates, while infrastructure teams manage VPNs and internal certificate services. Application teams inherit cryptography through libraries, cloud teams configure managed services, and product engineers depend on firmware supplied by other companies. Procurement, meanwhile, negotiates the contracts that determine whether updates will arrive, and each of these groups sees only part of the picture.

An application may rely on a library that implements a protocol using certificates issued through a public key infrastructure. Private keys may sit inside a hardware security module (HSM), whose capabilities depend on firmware, interfaces, and certification.

“We don’t implement cryptography ourselves” may be true, but the application still depends on it. “The supplier handles that” may also be true, but the organization still needs to know what the supplier can deliver. An algorithm change can therefore turn into an operating-system upgrade, an appliance replacement, or a contract negotiation, and no single team can complete all of that alone.

Lesson One: TLS

The history of secure web connections offers a useful example of how long cryptographic transitions can take.

TLS 1.1 was standardized in 2006 and TLS 1.2 in 2008. Publication made those protocols available to implementers, but it could not update every browser, server, operating system, or network appliance that would need to use them [3, 4].

Retiring an old protocol is a separate challenge. The POODLE attack, disclosed in October 2014, exposed a serious weakness in SSL 3.0. In response, Mozilla announced plans to disable the protocol by default in Firefox, and the IETF formally deprecated it in June 2015 [5, 6]. Those events are different milestones: identifying a vulnerability, changing products, and formally withdrawing a protocol, and none of them establishes when every dependent system stopped using it. By Preneel’s reading of SSL Labs data on the top 150,000 websites, it took roughly a decade before most of them dropped SSL 3.0, and these are the fast upgraders rather than the long tail [2].

A service owner may know that an old protocol should go and still have to discover which customers, devices, or integrations would lose access when it is disabled. Supporting a replacement and removing the old option are separate tasks, and the second one requires visibility into systems outside the operator’s immediate control.

Standardized does not mean deployed.

Lesson Two: Telecom Standards

The challenge can begin before a security improvement even reaches a standard. Mobile network security specifications are developed across 3GPP, ETSI, and GSMA, and updating cryptographic profiles can take years because equipment from different releases must keep working together [7].

In 2020, while working at an equipment vendor, my team started a discussion on introducing 256-bit algorithms for mobile networks. We sought support from other large companies, including through letters to other standards bodies and working groups. We did not succeed that year, largely because of implementation costs. The topic returned later: during Release 18, ETSI SAGE specified 256-bit algorithms for the radio interface, and the MILENAGE-256 specification was published as part of Release 19 [8, 9].

A security improvement can be technically sound and still wait years for the ecosystem to agree that it is worth the cost.

Lesson Three: EMV and the Long Tail

Payments make the coordination problem tangible, even in an industry with strong incentives and established standards.

According to Preneel, the payment industry decided in 2008 to move EMV card cryptography from RSA to elliptic curves, with a plan that would take about 20 years. It abandoned that plan after a number of years and has since restarted [2]. The public record confirms a significant milestone, as EMVCo published ECC support for its contact chip specification in October 2021, allowing RSA and ECC to coexist [10]. ECC is not quantum-resistant, but the example shows how difficult even a transition between well-established algorithms can be.

Preneel points to the scale involved, with six or seven billion cards but more than 100 million terminals [2]. Cards can be reissued on a regular cycle, while terminals run on different schedules and involve different organizations. A new card cannot complete the transition if the places where it is used cannot support it.

Together, TLS, telecommunications standardization, and EMV show why cryptographic transitions can take so long: the challenges may begin during standardization, continue through product development, and persist during deployment as organizations try to stay compatible with older systems. Large platforms can move quickly within environments they control, but older clients, smaller suppliers, and embedded devices follow different schedules, and those remaining dependencies can determine how long legacy support stays in place.

Standardization Is a Milestone, Not a Finish Line

NIST’s publication of ML-KEM, ML-DSA, and SLH-DSA in August 2024 provided finalized standards for key establishment and digital signatures [11], which was a major step toward deployment, but it did not automatically update libraries, HSM firmware, certificate services, VPNs, or supplier contracts.

For customers, “we support PQC” is the beginning of a conversation, since it might describe an experimental implementation, an early-access feature, or a production capability available only in particular configurations. The useful questions are more specific:

• Which product version supports it, and is it generally available?
• Does support cover key establishment, signatures, or both?
• Does it work with our HSM and connected systems?
• What validation or certification applies?
• Can we safely retire the old mechanism?

A feature can exist in a supplier’s portfolio and still be unavailable in the product version or HSM configuration your organization actually runs.

The Hidden Places

Some dependencies become visible only when something needs to be trusted: a certificate authenticates a service, firmware verifies the next stage of a device’s boot process, and digital signatures help devices and applications decide whether software should be accepted as authentic.

For confidentiality, Harvest-Now, Decrypt-Later creates urgency because intercepted data may retain its value for years. Signatures raise a different question: how will a system establish authenticity when its existing verification mechanism is no longer trustworthy? An old signature does not automatically become invalid when cryptographic capabilities change; the concern is whether future attackers could forge material that a still-operating system would accept.

For long-lived equipment, the mechanism needed to deliver a secure upgrade may itself need upgrading. Preneel identifies secure boot and update signatures among the hardest migration areas [2]. Signing systems therefore often require migration planning separate from encryption systems.

Where to Start

Return to the customer portal, whose connections are only the visible entry points into a larger collection of certificates, libraries, devices, partners, and suppliers. Public-key cryptography became difficult to see because these components made it so convenient to use, and migration now requires organizations to understand what has accumulated before they can change it safely.

A useful first step is to choose one important business service, trace its cryptographic dependencies, and find the component that would be hardest to replace, because that component may reveal more about the migration timeline than the choice of algorithm.

Part 3 will explore how to build that visibility: finding where cryptography lives and connecting it to the services that depend on it.

Sources & Further Reading

1. Preneel, B. (2026, June 1). Post-quantum cryptography (PQC): The risk of being late [Conference presentation slides]. SecAppDev 2026. https://handouts.secappdev.org/handouts/2026/bartpreneel_post-quantum-cryptography-pqc-the-risk-of-being-late.pdf
2. Preneel, B. (2026, October 12). The quantum threat: Why act now? [Video]. YouTube. https://www.youtube.com/watch?v=Gg8hODiE4FA
3. Dierks, T., & Rescorla, E. (2006). The Transport Layer Security (TLS) protocol version 1.1 (RFC 4346). RFC Editor. https://doi.org/10.17487/RFC4346
4. Dierks, T., & Rescorla, E. (2008). The Transport Layer Security (TLS) protocol version 1.2 (RFC 5246). RFC Editor. https://doi.org/10.17487/RFC5246
5. Mozilla Security. (2014, October 14). The POODLE attack and the end of SSL 3.0. Mozilla Security Blog. https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
6. Barnes, R., Thomson, M., Pironti, A., & Langley, A. (2015). Deprecating Secure Sockets Layer version 3.0 (RFC 7568). RFC Editor. https://doi.org/10.17487/RFC7568
7. Preuß Mattsson, J., Comak, P., & Karakoç, F. (2021, June 29). The evolution of cryptography in mobile networks and how to secure them in the future [Blog post]. Ericsson. https://www.ericsson.com/en/blog/2021/6/evolution-of-cryptographic-algorithms
8. Jost, C. (2024, April 18). 3GPP Rel-18 security – the overview [Blog post]. Ericsson. https://www.ericsson.com/en/blog/2024/4/3gpp-release-18-security-overview
9. 3rd Generation Partnership Project. (2026, January). Specification of the MILENAGE-256 algorithm set. Document 1: General (3GPP TS 35.234, version 19.0.0; ETSI TS 135 234). ETSI. https://etsi.org/deliver/etsi_ts/135200_135299/135234/19.00.00_60/ts_135234v190000p.pdf
10. EMVCo. (2021, October 28). EMV® chip specifications to support elliptic curve cryptography [FAQ]. https://www.emvco.com/news-publications/emv-chip-specifications-to-support-elliptic-curve-cryptography/
11. National Institute of Standards and Technology. (2024, August 13). NIST releases first 3 finalized post-quantum encryption standards [News release]. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards