Crypto-Agility: Why It Matters More Than Picking the Right Algorithm

Every discussion about post-quantum migration eventually turns into an argument about which algorithm to pick. It is the wrong argument, or at least the second most important one. The organisations that will get through this transition without pain are not the ones that choose correctly in 2026. They are the ones that can choose again in 2031 without rewriting anything.

That property has a name: crypto-agility. It is the ability to change cryptographic primitives as a configuration decision rather than an engineering project.

Why the algorithm choice is not the durable decision

Consider the recent history. SHA-1 was recommended, then discouraged, then broken in practice. MD5 followed the same arc earlier. Dual_EC_DRBG was standardised and later withdrawn amid serious concerns about its construction. RSA-1024 was fine until it was not. In each case the algorithm was reasonable when adopted and a liability later.

Post-quantum algorithms are younger than any of those were at adoption. Lattice-based cryptography has been studied for decades, but ML-KEM and ML-DSA as deployed constructions have far less adversarial attention than RSA accumulated over forty years. That is not an argument against using them — the alternative is staying on cryptography we know quantum computers break. It is an argument for assuming you will change again.

NIST’s own behaviour signals this. FIPS 205 exists specifically as a hedge against a structural break in lattice-based schemes, and NIST has continued evaluating additional signature designs to widen the mathematical base. The standards body is not betting on one family. Neither should your architecture.

What crypto-agility actually requires

The phrase gets used loosely, usually to mean “we could change it if we had to.” Everything can be changed if you are willing to spend enough. Agility means the cost is low enough that you will actually do it before you are forced to.

Cryptography behind an interface, never inline

The most common failure is calling a specific primitive directly from application code, scattered across a codebase. If rsa_sign() appears in two hundred files, changing algorithms is a two hundred file change with two hundred chances to get it wrong.

The fix is ordinary software design: application code calls sign() and verify(), and a single layer decides what those mean. Nothing above that layer knows or cares which algorithm is in use. This is not sophisticated, but it is rare, because cryptography tends to get written once by whoever was available and then never revisited.

Algorithm identifiers in your data formats

Anything you store or transmit that is signed or encrypted needs to carry a machine-readable statement of how. If a stored record does not say which algorithm produced its signature, you cannot verify old records after a migration without guessing, and you cannot ever safely retire the old code path.

The corollary is that you need to plan for verifying with an algorithm you no longer use for signing. Migration is never atomic. There will be years during which you must validate old signatures while producing new ones, and formats that cannot express that will force you into either an impossible cutover or an indefinite dual-stack.

Negotiation rather than assumption

Protocols that hardcode a cipher suite cannot evolve. TLS gets this right — endpoints negotiate, and adding a new suite does not break old clients. A great deal of internal and machine-to-machine communication gets it wrong, assuming both ends will always agree because they were deployed together. They will not always be deployed together.

Key sizes that are not baked into structures

Fixed-width fields sized for a 64-byte ECDSA signature cannot hold a 3,000-byte ML-DSA signature. Database columns, protocol frames, embedded storage layouts, and certificate handling all tend to carry assumptions about size that nobody documented because they were true for twenty years. These assumptions surface late and expensively.

Hybrid schemes as agility in practice

Hybrid key exchange — running a classical algorithm and a post-quantum one together, deriving a secret secure unless both fail — is the clearest working example of the principle.

It hedges in both directions. If ML-KEM turns out to have a weakness, the elliptic curve component still protects you. If a quantum computer arrives, the post-quantum component does. You do not have to be confident about either to deploy it, which is precisely why it is the right default during a transition.

It also demonstrates the architectural point: a system that can run two key exchange algorithms simultaneously is, by construction, a system that can swap either one.

Where this is hardest

Crypto-agility is straightforward in a modern web application and extremely difficult in three places.

Embedded and industrial systems often have cryptography in firmware, constrained memory that cannot hold multiple implementations, and deployment lifetimes measured in decades. A device shipped in 2026 with a fifteen-year life will outlive the deadline, and many cannot be updated in the field at all.

Blockchains have an unusually hard version of the problem. Consensus rules are agreed by a distributed network with no central authority to mandate an upgrade, signatures are stored permanently, and old ones must remain verifiable forever. Changing the signature scheme of a live chain requires coordinated agreement among parties with divergent incentives — which is a governance problem wearing a cryptography costume.

Long-lived documents signed today may need verification in thirty years, long after the signing algorithm is disallowed. This requires either preserving the ability to verify deprecated algorithms indefinitely, or re-signing archives periodically with current ones. Both are ongoing obligations that most document management systems were never designed to carry.

The practical test

There is a simple question that reveals whether an organisation is genuinely agile: how long would it take you to change your signature algorithm across the estate, starting today?

If the answer is measured in weeks, the architecture is sound. If it is measured in years, the post-quantum migration is not a one-time project you will complete and forget. It is the first of several, and the work worth doing now is the work that makes the next one cheaper.

Pick good algorithms. Then build as if you will replace them.