Part II, Practitioner · Lesson 11

Crypto-agility: build to swap

By Kyeson Blake Utley13 min read1 interactiveSome tech background

The short version

Imagine every door in a building had its lock welded on. Changing locks would mean replacing doors. Crypto-agility means bolting locks on with standard screws, keeping a list of every door, and making the holes big enough for a bigger lock. Then swapping locks is a weekend job.

You'll learn to

Define crypto-agility, following NIST's description.
Explain from history why algorithm replacement is a recurring event, not a one-off.
Identify the design practices that make algorithms swappable, and the anti-patterns that prevent it.
Recognize the security trade-offs agility introduces, such as downgrade risk.

The post-quantum migration is huge mostly because the systems weren't designed to change. Algorithm names are baked into code, keys into hardware, sizes into database schemas. This lesson is about not making that mistake again.

What crypto-agility means

NIST's white paper on the topic (CSWP 39, finalized in December 2025) describes crypto-agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructure, while preserving security and ongoing operations.

The last part matters. Agility isn't just "we could change it eventually". It's being able to change it without an outage and without a rewrite.

Algorithms retire. Plan for it.

If post-quantum migration were a once-in-history event, agility would be a nice-to-have. It isn't:

SHA-1 was the standard hash for years. The first public collision was demonstrated in February 2017, and in December 2022 NIST announced its retirement, with a phase-out deadline of 31 December 2030.
SIKE was a promising post-quantum candidate until a classical attack broke it in July 2022, in about an hour on a single core.
Rainbow, a finalist signature scheme, fell in 2022 to an attack that took "a weekend on a laptop".
Kyber to ML-KEM: even a successful algorithm changed under deployment. The final FIPS 203 version wasn't compatible with the pre-standard Kyber that Chrome had shipped, so Chrome 131 switched to a new code point and dropped the old one rather than support both.

The Chrome case is agility done right: because TLS negotiates its key exchange and Chrome could ship an update, millions of connections changed algorithm in one release. Now picture the same change in a fleet of devices that verify only one hard-coded signature algorithm.

What makes a system agile

Agility comes from a handful of concrete design choices. Each one removes a reason a change would require new code.

1. A central crypto policy

Algorithms are chosen in configuration, in one place, not scattered as constants through code. Changing the policy changes every system that reads it. Operating-system-wide crypto policies and TLS library configuration are examples.

2. An abstraction layer

Applications call a small internal interface, such as sign(data) or encrypt(data, key), backed by one well-maintained library. They never name "RSA" themselves. Swapping the implementation behind the interface updates every caller.

3. Algorithm identifiers stored with the data

Every stored signature, ciphertext and key carries a label saying which algorithm produced it. Then old and new can coexist during a migration: verify old records with the old algorithm, write new ones with the new. Without labels, you need a big-bang cutover.

4. Room to grow

Fields, buffers, packets and protocol messages are sized with headroom, or are variable-length. An ML-DSA-65 signature is 3,309 bytes; a schema with a 256-byte signature column will need redesigning, not reconfiguring.

5. An inventory

You can't swap what you can't find. The previous lesson's inventory is what turns "an algorithm is broken" from a panic into a work list.

6. Hardware that can verify more than one algorithm

Devices that can't be updated easily should ship able to verify both a classical and a post-quantum signature, or a hybrid. Software can be patched; mask ROM can't.

See the difference

Toggle the practices on and off, then hit the same hypothetical company with different events. Watch where the red comes from.

Anti-patterns to hunt for

Hard-coded algorithm names in application code, especially in many services that each made their own choice.
Fixed-size fields for keys and signatures in databases, file formats and network protocols.
Pinned keys in mobile apps and clients with no way to update the pin except a new app release.
One-algorithm hardware: secure elements, smart cards and boot ROMs that verify exactly one scheme.
Hand-rolled crypto instead of a maintained library, which means every change is a custom engineering job.
Vendor black boxes with no stated upgrade path. Agility is a procurement requirement as well as an engineering one.

Agility already built into protocols you use

You don't have to invent agility from scratch. Many standard protocols were designed with it, and the post-quantum migration uses those hooks:

TLS negotiates its key exchange per connection. That's how browsers and servers moved to X25519MLKEM768 without anyone changing a web page.
SSH negotiates key-exchange methods too. OpenSSH changed its default to a hybrid in 9.0 (2022) and to an ML-KEM hybrid in 10.0 (April 2025), and clients and servers that support different sets still find a common one.
X.509 certificates label the algorithm of every key and signature with an identifier, so a certificate format can carry new algorithms once identifiers are defined, as RFC 9881 did for ML-DSA.

The hard cases are the places where someone bypassed these mechanisms: a custom protocol with a fixed message format, an application that pins one algorithm, a device that checks exactly one kind of signature.

A quick agility self-assessment

For any system, ask:

If we had to change this algorithm next quarter, would it be a configuration change, a code release or a redesign?
Who would we need to ask: our own team, a vendor, or a customer who'd have to update?
Does stored data say which algorithm protected it?
Would a 3 KB signature or a 1.5 KB public key fit everywhere this data goes?
Could we roll back if the new algorithm misbehaved?

Systems that answer "configuration, our team, yes, yes, yes" are agile. Everything else goes on the improvement list.

Agility has a security cost, too

Supporting several algorithms means more code, more configuration and more combinations to test. Negotiation also opens the door to downgrade attacks, where an attacker tricks two parties into choosing the weakest option they both support. Agile systems therefore need:

policies that remove old algorithms on schedule, not just add new ones;
protocols that protect the negotiation itself (TLS 1.3 signs the handshake transcript for this reason);
monitoring that shows which algorithms are actually being negotiated, so stragglers are visible.

Hybrid modes are a special kind of agility. They let you add a post-quantum algorithm without trusting it alone, and later drop the classical half with a policy change.

Go deeper: how a hybrid becomes a clean exit

In a hybrid key exchange, both shared secrets feed the key derivation, so the session is safe if either algorithm holds. That gives a three-step path. First, add the post-quantum algorithm alongside the classical one, trusting neither alone. Second, run both for as long as it takes to build confidence in the new algorithm and its implementations. Third, once policy allows, retire the classical half, which in a well-built system is a configuration change rather than a protocol redesign. The same pattern applies to signatures through dual signing or composite certificates, at a higher cost in bytes.

Making it real

Agility is easiest to build into new things. A pragmatic program:

Set a standard for new systems: approved algorithms come from central policy, crypto goes through the shared library, stored artifacts carry algorithm IDs, and fields are variable-length.
Write it into procurement: ask vendors which algorithms they use, how they're configured, and when they'll support ML-KEM and ML-DSA.
Retrofit opportunistically: when a system is touched for post-quantum work anyway, fix its agility at the same time, so the next migration is cheaper.
Rehearse: pick a non-critical system and actually swap an algorithm end to end. The surprises you find are the ones that would have hurt in production.

Summary

Crypto-agility is the ability to replace algorithms across software, hardware and protocols while preserving security and operations (NIST CSWP 39).
Algorithm retirement is recurring: SHA-1, SIKE, Rainbow and even Kyber-to-ML-KEM all forced changes.
Key practices: central policy, an abstraction layer, algorithm IDs with stored data, room for bigger sizes, an inventory, dual-capable hardware.
Anti-patterns include hard-coded algorithms, fixed-size fields, pinned keys and one-algorithm hardware.
Agility adds downgrade risk, so remove old algorithms on schedule and protect negotiation.

Questions

Get five of six right to mark the lesson complete. They also feed the final exam.

Sources

Drawn byKyeson Blake Utley

CourseQuantum Defense

Sheet11 of 18

PartII · Practitioner

Rev.18 Oct 2026

Sources7 cited

Found an error?Send a correction