Crypto-agility: designing so the next algorithm change isn't a rewrite
The real cost of PQC migration is finding and changing hard-coded cryptography. Crypto-agility is the architecture that makes algorithm changes configuration, not surgery — and it pays off again with every future transition.
Agility is what makes the second migration cheap
Crypto-agility is the property that a system can change cryptographic algorithms without re-architecting. You get it by abstracting crypto behind a provider interface, negotiating algorithms rather than hard-coding them, tagging stored data and messages with algorithm identifiers, and centralizing crypto policy. It costs something to build, but it turns every future transition — including the ones after PQC — from a code project into a configuration change.
Ask why PQC migration is expensive and the answer is rarely the new algorithm — ML-KEM is a library call. The cost is that RSA and ECC are welded into thousands of call sites, file formats, and protocols that assumed the algorithm would never change. Crypto-agility is the discipline of not making that assumption. Build it once and the current migration gets cheaper; keep it and every future migration gets cheaper still.
The four pillars
- **Abstraction** — call crypto through a provider/interface, never a concrete algorithm. Application code asks to "encrypt" or "sign"; the provider decides how.
- **Negotiation** — where two parties interact, negotiate the algorithm at runtime (as TLS does with named groups) instead of assuming a fixed one.
- **Algorithm identifiers on data** — every ciphertext, signature, key, and token carries a machine-readable tag saying which algorithm and parameters produced it, so a reader knows how to process it.
- **Centralized policy** — which algorithms are allowed, preferred, or deprecated lives in one place you can change, not scattered across services.
Why algorithm identifiers are non-negotiable
Stored ciphertext and long-lived signatures outlive the code that made them. If a database column of encrypted values has no per-record algorithm tag, you cannot roll forward: you have no safe way to tell which rows are old-algorithm and which are new during a gradual re-encryption. Tag at write time — algorithm, parameters, key identifier — and readers become polymorphic: they dispatch on the tag and can decrypt old and new side by side. This is what makes a zero-downtime data-at-rest migration possible at all.
Agility is not the same as a plugin marketplace
Crypto-agility does not mean supporting every algorithm anyone might want, or letting operators pick freely. That expands attack surface and creates downgrade risk. The goal is the ability to change the small set of algorithms you sanction, under central policy, without touching application code. Constrain the allowed set tightly; make changing that set easy.
Guard against downgrade and negotiation attacks
Negotiation is powerful and dangerous: if an attacker can force both sides down to the weakest mutually supported algorithm, agility becomes a liability. Set a policy floor that rejects algorithms below a minimum strength, prefer the strongest common option, and — during hybrid deployments — ensure the classical and PQC components are bound together so an attacker cannot strip the PQC half and leave only the breakable classical exchange.
Retrofit versus rebuild
Most estates cannot rebuild for agility all at once. Retrofit pragmatically: wrap the worst-hard-coded call sites behind a thin provider first, add algorithm tags to new writes while leaving old data readable, and centralize policy for the systems you touch during this migration. You do not need a perfectly agile estate to migrate to PQC — you need enough agility at the systems in your current waves, plus a standard to apply to everything you build next.
Crypto-agility readiness check
For a system to count as crypto-agile: application code contains no hard-coded algorithm names; every stored ciphertext and signature carries an algorithm identifier; the allowed-algorithm set is defined in one policy location; readers can process both current and previous algorithms during a transition; and a negotiation floor rejects downgrades below the sanctioned minimum. Score each system against these five; the gaps are your agility backlog.