Crypto-agility is the ability to change cryptographic algorithms without redesigning the systems that depend on them.
It is the capability the post-quantum transition is really testing. The specific algorithms will change again — ML-KEM is not the last word, and parameter sizes will move — so the organisations that cope well are those that can swap primitives, not those that happened to pick correctly this time.
What makes a system inagile
- Algorithms hard-coded rather than negotiated or configured
- Key sizes baked into database columns, protocols, or file formats
- Certificate handling that assumes a specific signature algorithm
- Vendor appliances whose cryptography cannot be configured at all
- No inventory, so nobody knows what would need to change
The last is the most common and the most limiting. You cannot replace what you have not found.
Why post-quantum makes it acute
Post-quantum algorithms break assumptions that held for decades. ML-KEM keys are over thirty times larger than X25519 keys. Signature sizes grow substantially. Code that assumed a public key fits a particular field, or that a handshake fits in one packet, now fails — and fails in ways that look like network problems rather than cryptographic ones.
It is measurable
A useful test: how long would it take to change the key exchange on every internet-facing service you operate?
If the answer is days, you are agile. If it is "we would have to find them first", that is the actual project, and it is the one to start now — because NIST's timeline counts down whether or not the inventory exists.