What is crypto-agility?

Crypto-agility is the capacity to change your cryptographic algorithms without re-architecting the systems that use them. The algorithm becomes a setting rather than a foundation: named in configuration, negotiated at runtime, or swapped by updating a library, rather than welded into the application logic.

Why does crypto-agility matter now?

The trigger is quantum computing. A powerful enough quantum computer running Shor's algorithm breaks RSA and elliptic curve cryptography, the public-key algorithms underneath TLS, SSH, code signing, PKI and VPNs. In 2024 NIST finalized the first post-quantum standards (ML-KEM for key exchange, ML-DSA for signatures), so the migration is a live programme, not a research topic.

What is a cryptographic inventory, and why do you need one?

A cryptographic inventory is a living record of where you use public-key cryptography: which algorithms, which key lengths, protecting what data, with what lifetime. You cannot migrate what you cannot see, and most organizations cannot. It is the single most useful artefact you can commission, and it requires no new algorithm to start.

Crypto-Agility: The Migration You Can't Do at the Last Minute

Q: What is harvest now, decrypt later?

An adversary records your encrypted traffic today and decrypts it once quantum hardware matures. Any data whose value outlives the arrival of quantum computing is effectively exposed already if it crossed the wire under classical algorithms, so long-lived sensitive data such as medical records, government secrets and intellectual property should be migrated first.

Somewhere in your estate, right now, a system is encrypting data with an algorithm that has a shelf life. Not because it is broken today, but because the industry has already agreed it will be, and published what replaces it.

The only open question is how long it would take you to swap it across everything you run. If the honest answer is “we don’t know”, that is the actual problem, and it is not a cryptography problem.

What crypto-agility actually is

Every system that protects data makes a choice of algorithm: which cipher encrypts the traffic, which method signs the code, which scheme protects the keys. For decades that choice was made once, hard-coded, and forgotten, because the algorithms (RSA, elliptic curve cryptography) were not going anywhere.

Crypto-agility is designing so that choice is not permanent. The algorithm becomes a setting, not a foundation: something named in configuration, negotiated at runtime, or swapped by updating a library, rather than something welded into the application logic. An agile system can be told “stop using that algorithm, use this one instead” and comply without a rebuild. A brittle one has to be opened up, re-engineered, retested, and redeployed, one system at a time, by hand.

The distinction is invisible right up until the day you have to change, and then it is the only thing that matters.

Why algorithm migration lands on your desk

For years this was a theoretical virtue. It is now a scheduled obligation, and the schedule is not yours to set.

The trigger is quantum computing. A sufficiently powerful quantum computer, running Shor’s algorithm, breaks RSA and elliptic curve cryptography: the public-key algorithms underneath TLS, SSH, code signing, PKI, and your VPNs. Those machines do not exist at the required scale yet. That is not the reassurance it sounds like, for two reasons.

First, the replacements are already here. In 2024, NIST finalized the first post-quantum standards (ML-KEM for key exchange, ML-DSA for signatures), so “waiting for guidance” is no longer a place to hide. The migration is a live programme, not a research topic.

Second, and this is the part that reorders your timeline: harvest now, decrypt later. An adversary does not need a quantum computer today to hurt you with one tomorrow. They can record your encrypted traffic now and decrypt it the day the hardware matures. So any data whose value outlives the arrival of quantum computing is effectively exposed already, if it crossed the wire under classical algorithms. Medical records, government secrets, intellectual property, anything with a decade of sensitivity: the clock on that data started some time ago.

That collapses a comfortable “sometime next decade” into a question with a due date attached. And the length of your migration is not set by the deadline. It is set by how agile your estate already is, which was decided years before anyone sent you a memo about it.

How crypto-agility works, to the depth you need

You do not need to evaluate lattice-based cryptography. You need to understand that agility is a property of your architecture, and it lives at a few specific layers. The useful mental model is where the algorithm is named, and how many places you would have to touch to change it.

  Least agile   Algorithm hard-coded into application logic
                  -> change means re-engineering each app by hand
                          |
                          v
                Algorithm chosen in shared libraries / config
                  -> change means updating and redeploying components
                          |
                          v
  Most agile    Algorithm negotiated at runtime + a crypto inventory
                  -> change means flipping a setting, estate-wide,
                     because you know every place it is used

Two things move you down that ladder toward agility. The first is abstraction: systems that call a shared cryptographic service or library, rather than each implementing their own, have one place to change instead of hundreds. The second, and the one that is pure governance rather than code, is a cryptographic inventory: a living record of where you use public-key cryptography, which algorithms, which key lengths, protecting what, with what data lifetime. You cannot migrate what you cannot see, and most organizations cannot see it. That inventory is the single most useful artefact you can commission, and it does not require a single new algorithm to start.

Where crypto-agility goes wrong

The failures here are quiet, because nothing breaks until you try to move.

You have no inventory, so you cannot even scope the work. The migration stalls before it starts, because no one can say where the cryptography is. This is the default state, and the most expensive one to discover late.
The dependency is buried where you cannot reach it. Algorithms baked into firmware, hardware security modules, embedded devices, or a vendor’s product are not yours to change on a config line. Long-lived hardware bought today can outlast the algorithms it ships with.
You inherited someone else’s brittleness. Your suppliers have the same problem, and their timeline becomes yours. If a critical vendor cannot move, neither can the service you built on them.
You treated it as a one-time project, not a capability. Crypto-agility is not “the post-quantum migration”. It is the ability to do the next migration, and the one after that, without this scramble. Standards change again; the point is to be able to keep up.
You started too late on your longest-lived data. Because of harvest-now- decrypt-later, the data you should protect first is the data that stays sensitive longest, not the data that is easiest to reach.

Questions to ask about crypto-agility

You will not choose the algorithms. You will decide whether the organization can change them at all. A handful of questions surface that faster than any audit:

Do we have a cryptographic inventory: where we use public-key cryptography, which algorithms, protecting what, and for how long that data stays sensitive?
If we were told to stop using a specific algorithm across the estate, how long would it take, and how do we know?
Which of our systems have cryptography we cannot change ourselves, because it lives in hardware, firmware, or a vendor’s product?
Are our critical suppliers on a post-quantum path, and is that commitment written into contracts, or merely assumed?
Which of our data has a sensitivity lifetime long enough that it is already at risk from harvest-now-decrypt-later, and is that data first in the queue?

If those answers exist, you have a programme. If they get blank looks, you do not have a cryptography gap, you have a visibility gap, and that is the one to close first.

The day you are forced to change an algorithm, agility is no longer something you can build. It is only something you already have, or already wish you did.