Preparing
Crypto agility
Why the durable goal is a system that can change its cryptography without a rewrite, not a single algorithm swap.
6 min read
What you'll be able to do
- Define crypto agility, and explain why it is a more durable goal than any single algorithm swap.
- List concrete practices that make a system crypto-agile.
- Explain why HQC's existence as a backup, and FN-DSA's drafted status, are themselves arguments for agility.
Crypto agility is the ability to change which cryptographic algorithms a system uses, for key exchange, signatures, or ciphers, without a redesign. It matters independently of the quantum transition: algorithms have been retired before (MD5, SHA-1, RC4) and will be again. The post-quantum shift is simply the largest such event cryptography has faced at once.
The standards themselves argue for agility. NIST maintains a backup KEM (HQC) built on different math specifically in case ML-KEM's assumptions weaken, and a second signature family (FN-DSA) is still being finalized. A system hard-coded to one algorithm identifier cannot absorb either development without engineering work; a crypto-agile one absorbs it as a configuration change.
- Negotiate algorithms rather than hard-coding them — TLS already does this well.
- Keep cryptographic operations behind an interface, not inlined at every call site, so an implementation can change in one place.
- Track where every key, certificate, and algorithm identifier lives, so a swap has a known blast radius.
- Prefer libraries and protocol versions that already support the NIST PQC standards, so a policy change does not wait on a vendor release.
- Test the fallback path, not only the primary one — an agile system that has never exercised its second algorithm is agile in theory only.
| Without crypto agility | With crypto agility |
|---|---|
| An algorithm swap touches every call site that hard-codes it | An algorithm swap is a configuration or policy change |
| A newly drafted standard, such as FN-DSA, requires a new project to adopt | A newly drafted standard can be evaluated through the same interface already in place |
| An exception to a deprecation deadline is either permanent or blocks the whole program | An exception can be time-bounded and revisited |
None of this replaces doing the migration. Agility changes how much a future change costs; it does not remove the work of the current one, the subject of the next lesson.
Marking a lesson complete only updates this browser.