Crypto-Agility

Why the last migration took a decade

The last time the world moved algorithms at scale — the old SHA-1 hash to SHA-2 — it took the better part of a decade and was painful. Why so slow? Cryptography had been baked deep into systems: algorithm names hard-coded into application logic, key sizes assumed in schemas and protocols, no clean seam to reach in and swap. Every change meant hunting through code, rebuilding, and re-testing thousands of places by hand.

What crypto-agility means

Crypto-agility is the discipline of never letting that happen again: designing so the choice of algorithm is a configuration setting, not a hard-coded fact. The rest of the application asks “encrypt this” or “sign this” without caring which algorithm does the work.

The patterns that make systems agile

# callers only ever see this:
token = crypto.sign(payload)          # not rsa_sign(...) or mldsa_sign(...)

# one place decides the algorithm, from config:
class CryptoProvider:
    def sign(self, data):
        algo = config.get("sig_algorithm")   # "ml-dsa-65" | "rsa-2048" | "hybrid"
        return _registry[algo].sign(data)

The question to keep asking

When you design or assess a system, don’t only ask “is this algorithm quantum-safe today?” Ask: “how quickly could we change this algorithm if we had to?” If the honest answer is months or years, that rigidity is the real vulnerability.

A rough self-scoring rubric:

Score each critical system honestly. The red rows are where migration will hurt — and therefore where crypto-agility work pays back first.

Why it pays off beyond quantum

PQC is young; one of today’s algorithms may later need adjusting, or a better one may arrive. A crypto-agile organisation absorbs that with a config change and redeploy. A rigid one faces another decade-long hand-cranked migration every time.

Crypto-agility

The ability to change cryptographic algorithms quickly, ideally by configuration.

Abstraction layer

A single interface (encrypt/sign/verify) behind which the algorithm lives.

Hybrid-ready

Able to run classical + PQC together and adjust the mix without rebuilds.

Certificate lifecycle automation

Automated issuance/rotation so algorithm changes are routine.

SHA-1 / SHA-2

Successive versions of the Secure Hash Algorithm; the SHA-1→SHA-2 move is the decade-long migration this article learns from.

PQC (Post-Quantum Cryptography)

The quantum-resistant algorithms whose larger keys/signatures agile systems must accommodate.

RSA / ECC

The classical algorithms — RSA (Rivest–Shamir–Adleman) and ECC (Elliptic-Curve Cryptography) — whose fixed sizes are often baked into buffers and schemas.

ML-KEM

Module-Lattice Key-Encapsulation Mechanism — deploying it is a milestone, not the end of agility work.

SAST (Static Application Security Testing)

Automated source analysis that helps surface hard-coded algorithms and sizes.

What to carry forward

• The goal is agility, not any single algorithm.
• Rigidity (hard-coded algorithms/sizes) is why the last migration took a decade.
• Agile patterns: abstraction layer, config-driven, no fixed sizes, automated cert lifecycle, living CBOM, hybrid-ready.
• Keep asking “how fast could we change this?” — slowness is the vulnerability.

Next: Risk & Data Classification → — deciding what to migrate first.

⚡ AI-first? Crypto-agility is the same discipline as model-agility — see Quantum-Safe AI.

Understand it in your own words

Paste into any AI assistant to check yourself:

I'm learning crypto-agility. Quiz me one question at a time, correcting me
gently:

1. Why is agility — not a specific algorithm — the real goal of quantum
   readiness?
2. Why did the SHA-1 to SHA-2 migration take about a decade?
3. Name four patterns that make a system crypto-agile.
4. What single question should I ask when assessing a system's crypto?
5. Why does crypto-agility pay off even beyond the quantum transition?