Preparing
Crypto agility
Why the durable goal is a system that can change its cryptography without a rewrite, not a single algorithm swap.
7 min read · 7 min 48 sec film
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 backup role and FN-DSA's unfinished status are arguments for agility.
Lesson film
Watch: Crypto agility
This is not the last algorithm change your systems will see — so the durable goal is a system that can change, not a system that has changed.
7 min 48 sec · 10 scenes
7 min 48 sec, narrated by your browser's voice. Captions and a full transcript are below — nothing here needs sound.
Module three is about doing this, and it opens with a question that reframes the whole programme.
With the player focused: Space plays or pauses, ← → seek ten seconds, Home restarts, M toggles narration.
Full transcript
1. Not the last time
2. This has happened before
3. What agility is
4. The same code, both ways
5. What makes a system agile
6. The standards agree
7. Without and with
8. Exceptions that expire
9. What agility is not
10. Takeaway
The written lesson
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 evolving standards landscape argues for agility. NIST selected HQC as a backup KEM built on different math, and FN-DSA is under development. An architecture that isolates cryptographic choices reduces the application changes needed later, but new keys, formats, peers, HSM support, validation, and operations can still require substantial work.
- 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 has a known interface and a tested plan for protocol, key, peer, and policy changes |
| A future standard, such as FN-DSA, requires a new project to adopt | A future standard can be evaluated through existing interfaces, subject to format and peer tests |
| 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.
Imagine replacing a KEM in a service whose peers, HSM, certificate parser, and archived key files all expect one format. An interface can isolate application call sites, but the peer protocol, key lifecycle, compatibility tests, and staged rollout still require work. A configuration flag is useful only when the underlying components already support the new choice.
Primary reading and claim sources
Publication status checked on the date shown. Draft guidance can change.
- CSWP 39-upd1: Considerations for Achieving Crypto AgilityNIST · Updated guidance; supersedes CSWP 39 · checked 2026-09-26
- TR 104 016: A Repeatable Framework for Quantum-Safe MigrationsETSI · Published technical report · checked 2026-09-26
Marking a lesson complete only updates this browser.