What is crypto-agility?
Crypto-agility is the ability to select, deploy, replace and retire cryptographic algorithms, keys and settings safely, across systems, suppliers and partners, without re-engineering the systems themselves. An agile system can move to a new algorithm through configuration, a supplier update or a policy change. A system that isn't agile needs a rebuild, a new product or a long project every time.
A simple test
Ask of any system: if we had to replace the algorithm it uses next quarter, how would we do it? If the honest answer is "change a setting and test it", the system is agile. If the answer is "the algorithm is hard-coded, so we'd need a new release", or "only the supplier can change it, and they have no plan", it isn't.
Why it matters now
The move to post-quantum cryptography won't be the last change. New algorithms are younger than the ones they replace, and some candidates have failed during public review: in 2022, researchers showed that the Rainbow signature scheme could be broken in a weekend on a laptop, and a separate attack broke the SIKE key-exchange scheme. Neither had been chosen as a final standard, but they show why NIST also selected a backup key-agreement algorithm, HQC, for standardisation in 2025. The lesson isn't only that algorithms can fail. It's that a programme must be able to respond to cryptographic change without redesigning its whole estate.
Crypto-agility pays off whatever happens with quantum computing. That makes it one of the most durable investments in a post-quantum programme.
What it takes in practice
Being able to change a setting is only part of it. NIST's guidance on crypto agility, CSWP 39, treats it as a property of whole systems and organisations. In practice it needs:
- An inventory of where cryptography is used, often recorded as a cryptographic bill of materials.
- No hard-coding of algorithms in new systems, and shared cryptography services instead of each team rolling its own.
- Certificate automation, so thousands of certificates can be replaced without manual effort.
- Interoperability with partners, so both ends of a connection can negotiate the new algorithm.
- Supplier commitments in contracts, because much cryptography sits inside products a bank can't change itself.
- Testing and rollback, so a change can be tried safely and undone if it breaks something.
Crypto-agility in a bank
Banks have learned this the hard way. Retiring the old DES encryption standard, and later SHA-1 certificates, took years partly because algorithms were baked into systems that were never designed to change. Payment systems are especially sensitive: messages have fixed formats, hardware security modules and card chips are replaced on long cycles, and both ends of every connection have to move together. The banking guide's chapter on crypto-agility covers how to build and fund it.
Common confusions
- "Agility means supporting every algorithm." No. It means being able to switch to approved ones quickly and safely, and to switch off old ones.
- "Hybrid mode makes us agile." Hybrid key agreement is a sensible transition step, but it doesn't make the next change easier on its own.
- "It's a purely technical project." Contracts, ownership and testing matter as much as code.
Sources and further reading
Tags show what kind of source each one is (how sources are used). Checked against these sources on 12 October 2026. Spotted an error? Email hello@plainquantum.com and it will be corrected, with a note.
- Government guidanceConsiderations for Achieving Cryptographic Agility (CSWP 39)NIST
- Peer-reviewed paperBreaking Rainbow takes a weekend on a laptopWard Beullens, CRYPTO, 2022
- Peer-reviewed paperAn efficient key recovery attack on SIDH (the SIKE break)Wouter Castryck and Thomas Decru, EUROCRYPT, 2023
- StandardNIST selects HQC as fifth algorithm for post-quantum encryptionNIST, 2025