Crypto-Agility Is Designing for the Algorithm You Haven't Chosen Yet.

Post-quantum migration is usually framed as a project you will start later, once the standards have settled and a plan is drawn up. The truth is less convenient: the cost of that future migration is being fixed right now, by decisions that have nothing to do with quantum computing. An organization that abstracted its cryptography years ago will change algorithms as a configuration change. One that scattered algorithm names and key sizes through its code will touch hundreds of call sites, each a chance to introduce a bug. Same threat, same new algorithm, wildly different bill — set long before the migration formally begins.

That property has a name: crypto-agility. It is the ability to change cryptographic algorithms without re-architecting the systems that depend on them. It is not a library you install or a product you buy; it is a structural property of how your code, your protocols, and your stored data refer to the cryptography underneath them. You either built it in or you did not — and the post-quantum transition is simply the exam that reveals which.

Migration cost is set years earlier

The migration you will eventually run is not one event; it is the sum of every place in your systems that has to change, times how hard each place is to reach safely. The number of those places, and the difficulty of each, was determined by architecture decisions made long before anyone sketched a migration timeline. The agile organization treated "which algorithm" as data — a value selected at configuration time. The brittle one treated it as a fact of the source code, as fixed as the language it was written in. That difference is invisible and costs nothing right up until the day you try to change the algorithm, which is precisely the worst day to discover which kind of organization you are.

What hard-coding looks like

Hard-coding is rarely one obvious blunder. It is a hundred small, reasonable-looking choices that each assumed the current algorithm was permanent, and together they weld that assumption into the system.

• Algorithm names in the code path — a function named for its primitive, or a branch that assumes one curve, so changing the algorithm means editing logic rather than flipping a setting.
• Baked-in key and output sizes — buffers, database columns, and struct fields sized for exactly today's keys and signatures, which a larger post-quantum value silently overflows or truncates.
• Fixed identifiers and OIDs — protocol fields, certificate parsers, and message formats that accept one algorithm identifier and reject or mishandle anything they were not written to expect.
• Nowhere to put a new algorithm — formats and schemas with no field to even record that a different algorithm was used, so the new one cannot coexist with the old during the transition period.

Agility as an interface, not a library

The fix is a familiar engineering pattern rather than anything cryptographic. Put the cryptography behind an interface, and have every part of the system call through that interface, so the concrete algorithm becomes a provider you select rather than a fact you compiled in. When the next algorithm arrives you implement one more provider behind the same interface, and the thousand call sites above it never learn that anything changed. This is the provider-and-abstraction pattern, nothing exotic. The discipline is that there are no exceptions: a single direct call to a concrete primitive, tucked somewhere for performance or convenience, is exactly the call site that will break the migration and be found last.

Negotiation and versioning

Agility inside one system is not enough when two systems have to agree with each other. Protocols need to negotiate which algorithm they will use, and they need explicit, versioned fields in which to do it. A protocol that assumes both ends already know the algorithm cannot evolve without breaking one of them. The ones that migrate gracefully carry an explicit version or algorithm field, allow a set of algorithms to be offered and one to be chosen, and define clearly how peers behave when they share no preferred option. Negotiation is also an attack surface in its own right — a downgrade attack tricks two capable peers into settling on the weakest option they both still support — so the negotiation must itself be authenticated, or agility becomes a way to be talked down to a broken algorithm.

Crypto-agility is not a feature you add when the new algorithm arrives; it is the absence of a thousand assumptions you had to have declined to make years earlier.

Data-at-rest is the hard case

Agility for traffic is comparatively easy, because sessions are short and the next connection can simply use the new algorithm. Data at rest is where agility gets genuinely hard. A field encrypted years ago under the old algorithm does not re-encrypt itself the moment you ship a new provider. Someone has to walk the stored data and re-encrypt it, and that is only possible if each record was stored with metadata saying which algorithm and which key protected it. Without that metadata you cannot even tell what needs upgrading, let alone how to read it afterward. Encrypted data written with no algorithm tag is a migration you may not be able to perform at all, because the information required to perform it was never recorded in the first place.

Rehearsing the swap

Agility that has never been exercised is a theory, and theories fail on contact with a real system. The organizations that will migrate calmly are the ones that have already rotated an algorithm at least once as a deliberate drill, and in doing so found the call site they missed, the buffer that was a few bytes too small, the stored record with no algorithm tag. A rehearsal surfaces assumptions that no amount of reading the code reveals, because the code reads as if the assumptions were always true. Do the rotation before the stakes are real, on a timeline you control, so that the actual post-quantum migration is a repeat of something you have already done rather than a first attempt made under pressure and scrutiny.

Building agility in now

Agility cannot be retrofitted in a hurry once the deadline is visible; it is bought in advance, in a series of small and individually unglamorous architectural decisions. And it rests on one precondition that is easy to skip past: you cannot abstract, negotiate, or rotate cryptography you have never inventoried. Knowing where every algorithm, key, and certificate actually lives — the asset-discovery work that feels like bookkeeping — is the groundwork that makes everything else possible, and it is almost always the step that has quietly not been done.

When 6QURE reviews a system for crypto-agility, the questions are concrete and unsentimental: is there one interface the cryptography passes through, or a thousand direct calls; do the protocols carry explicit version and algorithm fields; is stored data tagged with the algorithm that protected it; has anyone ever actually rotated an algorithm from end to end and lived through what broke. The post-quantum transition is the first large-scale test of those answers, and it quietly rewards — or punishes — the architecture you chose long before you had a concrete reason to care.