The Migration Is Bigger Than the Algorithm
Post-quantum migration is the effort to move Internet-facing and enterprise cryptographic systems away from public-key algorithms that a sufficiently capable quantum computer could compromise. The question for this series is not simply which algorithm replaces RSA or elliptic-curve cryptography. It is how protocols, certificates, applications, devices, suppliers, and operating decisions can change together without losing security or interrupting the services that depend on them. This opening establishes that systems view so you can judge a migration by the path it protects and the evidence behind it, not by a single feature label.
The object being changed is a connected system
Cryptography is easy to picture as a mathematical component: an algorithm receives data and keys, then produces encryption, a signature, or a shared secret. In a deployed system, however, that component is surrounded by assumptions. A communication protocol must tell two parties which algorithms they can use. An application must call a library or provider through an interface. A certificate must bind an identity to a public key, and relying parties must trust the authority that issued it. A device may store a key in a hardware module whose functions cannot be changed after manufacture. An organization must decide which choices are permitted and how quickly a vulnerable one must be retired.
Those relationships are why the National Institute of Standards and Technology defines crypto agility as the capability to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. The definition has a practical consequence: agility is not synonymous with having several algorithms available. A system also needs a safe way to select among them, update the implementation, prevent vulnerable choices, and keep communicating with systems that are at a different point in the transition.
This distinction matters because the primary subject is not cryptography in the abstract. It is the migration of real systems that use cryptography. An algorithm can be mathematically appropriate and still be unusable in a protocol that cannot identify it, in a certificate system that cannot validate it, or in a device whose memory and firmware were designed around smaller keys. Conversely, a system can advertise a new algorithm while a client, proxy, trust store, or legacy component continues to use the old one.
Consider what happens when a user connects to a service. The service may offer a modern protocol, but the client's browser and operating system determine which choices it can advertise. The server selects a mutually supported path. A certificate then has to identify the service through a trust chain that the client accepts, while the underlying library, hardware key store, and policy determine how the cryptographic operations are performed. The application receives the result as a secure connection, not as a lesson in algorithms. That apparent simplicity is valuable to the user, but it can conceal several independent migration dependencies for the people who operate the system.
The same pattern appears outside web traffic. A signed software update, an encrypted archive, or a device-to-device link carries assumptions about key sizes, certificate lifetimes, firmware, storage, and the parties that must continue to verify the result. Changing one algorithm may therefore alter an interface or a data format that another team, supplier, or older device still relies on. The migration problem is not that the mathematics is unimportant. It is that the mathematics is embedded in contracts between components, and those contracts must change without leaving an unprotected gap.
The arrows in this model are dependencies, not a claim that every migration follows one identical sequence. They show where a decision made at one layer can constrain the next. A protocol may support a new key-establishment method, but the application still depends on a library that cannot expose it. A library may expose it, but a certificate authority or trust store may not be ready. A service may complete the change, but a device that connects to it may still negotiate a classical path for compatibility. Crypto agility is the capability to manage those boundaries deliberately.
Why a stronger algorithm is not enough
There are two sides to a secure transition. The first is adoption: making a stronger option available and getting it into active use. The second is retirement: preventing a vulnerable option from remaining available indefinitely. If an old algorithm is removed before peers are ready, interoperability can fail. If it is retained without a controlled end point, a system can continue to expose the very weakness the migration was meant to remove. The program must therefore coordinate technical change with deployment knowledge, policy, and timing.
History shows how long that coordination can take. NIST describes the movement from DES to Triple DES and then to AES; Triple DES continued in some applications until it was disallowed in 2024. The complete transition from Triple DES to AES took 23 years. That history is not a timetable for post-quantum cryptography, but it is a warning about the lifetime of deployed assumptions. Products, certificates, devices, and partner connections often remain in service long after the design decision that created them.
The post-quantum transition is broader because it is not merely the replacement of one aging cipher. NIST describes all public-key algorithms as needing replacement in response to the threat of a future cryptographically relevant quantum computer. Public-key cryptography supports key establishment and authentication throughout communications and digital devices. Replacing those roles can affect how endpoints negotiate, how identities are certified, how keys are stored, and how old data and signed objects remain usable.
The risk also has more than one time horizon. A future quantum computer could threaten the mathematical assumptions behind widely deployed RSA and elliptic-curve mechanisms. In the meantime, an attacker may capture encrypted traffic whose value lasts longer than the current connection. Under the harvest-now-decrypt-later model, the attacker does not need to decrypt that traffic today; they can store it for a future capability. Authentication creates a different concern: if classical signatures become forgeable, an attacker could impersonate a service or certificate authority even if a particular session used a stronger key-establishment method.
PQC also changes the physical shape of the system. New public keys, signatures, and ciphertexts can be much larger than their classical counterparts. That affects certificates, handshake messages, network framing, storage, memory, and the time required to transmit or process cryptographic material. A transition can therefore fail through a buffer limit, a device capacity constraint, or an update path that was never designed to carry the new parameters. Choosing a stronger algorithm is necessary, but it does not answer whether the surrounding system can represent, transport, validate, store, and update it.
The transition also has to preserve two kinds of continuity at once. A service must continue to communicate with peers that have not upgraded, yet it must not preserve an old option so broadly that the option becomes the easiest path to select. A certificate authority may issue a new kind of credential while older certificates remain in circulation. A library may support both choices while an administrator's policy allows only one for new encryption but still permits the old one for decrypting stored data. These are not contradictions to be hidden; they are states that need an explicit policy, an owner, and a way to tell when the state can end.
That is the systems tension at the heart of post-quantum migration. Compatibility protects availability in the short term, while retirement protects security over the longer term. The safe balance depends on the data's lifetime, the exposure of the endpoint, the ability to update peers, and the cost of replacing a constrained device. No single algorithm decision can settle all four questions.
A better question for migration
The useful question is not “Has the organization adopted PQC?” It is “Can this protected path move to a stronger cryptographic configuration, prove that the configuration was actually used, and retire vulnerable alternatives without breaking the service?” That question keeps the system in view while still allowing precise technical decisions.
At the protocol boundary, the parties must identify compatible choices and protect the negotiation from downgrade. At the trust boundary, certificates, roots, and relying parties must be able to authenticate the result. At the implementation boundary, applications, libraries, kernels, firmware, and hardware must expose a safe update path. At the organizational boundary, someone must know where cryptography is used, which data matters most, which suppliers control a dependency, and what policy should happen when an algorithm is no longer acceptable.
These boundaries also define what a credible readiness statement must contain. “The new algorithm is supported” describes a capability. It does not establish that a particular client and server negotiated it, that the identity was authenticated with a compatible trust path, or that the old path can be withdrawn without breaking a dependent service. “The migration is complete” is stronger still: it requires evidence about deployed behavior, not only a package version or a configuration file. The difference between those statements is the difference between knowing that a component can change and knowing that a protected business path has changed safely.
For that reason, a migration program should be able to connect a cryptographic use to the data and service it protects, the people and suppliers who control it, and the test that will demonstrate a successful transition. This does not require pretending that every uncertainty can be removed in advance. It requires making uncertainty visible, deciding which residual risk is acceptable, and arranging the next observation or control before the old choice becomes an emergency.
This is why crypto agility should be understood as controlled change rather than unlimited flexibility. More options can make a protocol harder to analyze and an implementation harder to test. A gateway may shield a legacy system from direct modification, but it does not erase the legacy system's residual risk. A cloud service may provide an updateable cryptographic layer, but responsibility for applications, configurations, and data still has to be assigned. A hybrid mechanism may preserve security during uncertainty, but it can add certificate, validation, and eventual-retirement work.
The rest of the series follows these dependencies. It first examines why transition time, quantum risk, and resource growth make early preparation rational. It then opens the handshake to show how negotiation and hybrid designs work, tests the difference between partial and end-to-end readiness, and moves down through APIs, kernels, hardware, cloud services, and legacy boundaries. Finally, it treats inventory, policy, suppliers, evidence, and maturity as part of the same technical problem. The aim is not to produce a longer list of algorithms. It is to make the system's change surfaces visible enough to govern.
The first implication is already clear: the product that begins a migration may not be the system that finishes it. To understand why, the next step is to look at the long life of cryptographic transitions and the pressures that make delay expensive.