Crypto agility is having its moment.
Post-quantum cryptography has pushed the term into strategies, roadmaps, vendor presentations and management discussions. Organizations are told that they need cryptographic inventories, algorithm discovery, automated certificate management, abstraction layers and the capability to replace cryptography without disrupting operations.
None of this is wrong. But very little of it is new.
The need for crypto agility appeared the moment cryptography became a persistent component of information systems — an algorithm chosen once and then left running inside a protocol, a file format or a device for years.
Cryptographic algorithms age. Keys expire. Parameters become insufficient. Implementations fail. Protocols evolve. Computational capabilities increase. Cryptanalysis improves. And occasionally an entire mathematical assumption on which a cryptographic system depends becomes questionable.
Quantum computing is therefore not the origin of the crypto-agility problem. It is simply the latest and unusually large reminder that cryptography is a temporary technical mechanism attached to protection requirements that may live much longer than the mechanism itself.
That distinction matters.
Cryptography Has Always Had an Expiration Problem
No serious cryptographic engineering has ever been able to assume:
This algorithm will remain secure forever.
The IETF stated the problem plainly more than a decade ago. RFC 7696, published in 2015, tells protocol designers to assume that advances in computing or cryptanalysis will eventually make any algorithm obsolete, and therefore to build in mechanisms for migrating between algorithm suites.
And even that was hardly a new architectural insight. The mechanisms were already there:
- 1988 — the first edition of X.509 carried a
signatureAlgorithmidentifier in every certificate. - 1995 — SSL 2.0 negotiated cipher suites between client and server.
- 1999 — TLS 1.0 (RFC 2246), X.509 v3 for the Internet PKI (RFC 2459) and the Cryptographic Message Syntax (RFC 2630) all carried explicit algorithm identifiers for digest, signature and encryption operations.
- 2001 — AES replaced DES after a public competition, because DES had aged out.
These mechanisms existed for an obvious reason: cryptography changes.
So when crypto agility is presented today as a fundamentally new security capability created by the quantum era, something has gone wrong in the narrative.
PQC did not discover crypto agility.
PQC discovered how much crypto debt we have accumulated.
The Actual Problem: Binding
Consider what happens when we say:
“This data is encrypted.”
That sentence hides several different things.
There is first a protection objective: confidentiality. Then a cryptographic function is selected: encryption. Then a construction: AES-GCM. Then parameters: AES-256, nonce rules, tag length. Then an implementation: a library, a provider, an HSM, a firmware image. Then key material: key K123. Then a storage or protocol representation: a database field, a file format, a TLS connection, a backup container. And finally there is the actual object requiring protection: the data.
Every arrow represents a binding. And every binding can eventually become a migration problem.
This is where the discussion about crypto agility should start. Not with quantum computers. Not with a cryptographic inventory. Not with a shiny “crypto-agility platform.” With the bindings.
Agility Is the Inverse of Coupling
A system is difficult to migrate when cryptographic decisions have become tightly coupled to everything around them:
Application
↓
hard-coded API
↓
specific library
↓
specific algorithm
↓
specific key representation
↓
specific certificate format
↓
specific protocol
↓
specific stored object
Replacing one algorithm may therefore require changing software, APIs, key stores, HSMs, certificates, protocols, network peers, firmware, storage formats, archived data, operational procedures and external counterparties.
At that point the organization does not have a cryptographic problem. It has an architectural dependency problem involving cryptography. That is a much more useful way to understand crypto agility.
The more cryptographic mechanisms are hard-bound into applications, protocols and persistent objects, the less agile the environment becomes.
The Really Difficult Binding: The Object
Replacing the algorithm used for a new TLS session is comparatively easy. Changing the cryptography attached to an object created ten years ago is something else entirely.
Imagine a digitally signed document. The signature does not merely call a cryptographic service at runtime. A historical object has been created whose validity depends on a particular combination of hash algorithm, signature algorithm, key pair, certificate, trust chain, timestamp, encoding and validation rules.
The cryptography has become part of the object’s history.
Or consider encrypted archival data. Changing the organization’s preferred encryption algorithm does not magically transform existing ciphertext. The organization may have to:
- locate it,
- decrypt it,
- verify it,
- generate or select new key material,
- encrypt it again,
- preserve metadata,
- maintain auditability,
- ensure that the migration itself does not destroy the protection objective.
That is not an algorithm switch. It is an object transition.
This distinction becomes decisive when the lifetime of the protected information exceeds the expected lifetime of the cryptographic mechanism protecting it. Michele Mosca formalized this for the quantum case as an inequality: if the time the information must stay protected (X) plus the time needed to migrate (Y) exceeds the time until the mechanism is broken (Z), the protection has already failed. But the inequality holds for any mechanism, not only for quantum-vulnerable ones.
The industry solved this long before anyone said “PQC.” RFC 4998, the Evidence Record Syntax, was published in 2007 precisely so that a signed object could be re-anchored with fresh hashes and timestamps before its original cryptography expired. PAdES long-term validation did the same for PDF signatures in 2009. The problem was old enough to have standards.
Inventory Is Not Agility
This exposes another weakness in the current discussion.
A cryptographic inventory is useful. It tells you: where is cryptography? That is necessary. But it does not answer: what will break if I change it? Those are different questions.
Suppose an inventory tells us:
System A → RSA-2048 System B → AES-256 System C → SHA-256
Useful. But for migration we need something closer to a dependency map:
The dependency map is the binding chain from Figure 2, extended at both ends: upwards to the business requirement that justifies the protection objective, and downwards to the systems and counterparties that depend on the binding staying valid.
Business requirement
↓
protected object
↓
protection objective
↓
cryptographic service
↓
algorithm / parameters
↓
key / certificate
↓
implementation
↓
protocol / format
↓
dependent systems
↓
external counterparties
Now we can reason about change. The essential question is no longer merely “Where do we use RSA?” It becomes:
“What is bound to RSA, why is it bound to RSA, for how long must that binding remain valid, and what must happen when we remove it?”
That is the real migration question.
PQC Is an Excellent Stress Test
None of this means that the current crypto-agility work is unnecessary. Quite the opposite.
NIST’s Cybersecurity White Paper 39, finalized in December 2025, defines crypto agility as “the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations.” The same paper notes that the PQC transition has highlighted how difficult such adaptations can be. That is reasonable and useful.
The deadline is predictable. Harvest-now-decrypt-later means ciphertext captured today has a confidentiality horizon that can be estimated, rather than a vague “someday.”
The blast radius is total. Every earlier migration replaced one algorithm at a time. PQC replaces RSA, Diffie-Hellman and elliptic-curve cryptography — the entire public-key layer — at once.
But the interesting lesson is not “quantum computers created the need for crypto agility.” It is:
Quantum computing exposed how badly we implemented an old requirement.
For decades we knew algorithms would change. We nevertheless embedded them deeply into applications. We created long-lived data formats. We hard-coded assumptions into protocols. We deployed hardware with long replacement cycles. We created dependencies on vendors and counterparties. And then we acted surprised when changing the cryptography became difficult.
PQC has simply increased the blast radius.
Crypto Agility Is Not “Support More Algorithms”
There is another trap.
A system supporting ten algorithms is not necessarily more agile than one supporting two. In fact it may simply have a larger attack surface.
TLS history makes the point. Algorithm negotiation provides flexibility, but retaining obsolete algorithms for compatibility keeps weak cryptography alive long after it should have disappeared:
RFC 7696 explicitly discusses how interoperability concerns and legacy systems make disabling weak algorithms difficult. In every case above, the addition was easy. The removal took a decade.
Therefore:
More cryptographic choices ≠ more crypto agility.
Real agility requires the ability to introduce a new mechanism and remove the old one. That second half is frequently forgotten.
Perhaps the better test is:
That tells me much more about architectural agility than the number of algorithms an application supports.
The Protection Objective Should Be Stable. The Mechanism Should Not.
There is ultimately a simple architectural principle underneath all of this.
The business requirement might be: this information must remain confidential for 30 years. That is relatively stable.
The technical implementation — encrypt it with algorithm X using library Y and key-management system Z — is not.
The mistake is allowing the long-lived requirement to become unnecessarily bound to a short-lived implementation.
Confidentiality is not AES. Authenticity is not RSA. Integrity is not SHA-256. Trust is not X.509.
Those technologies are mechanisms used to achieve an objective under particular assumptions at a particular point in time. Once that distinction disappears from the architecture, crypto agility disappears with it.
Where This Sits in a Threat Taxonomy
For readers of this site, one clarification is worth making explicit: expired or broken cryptography is not a threat. It is a vulnerability condition.
Broken cryptography in TLCTC terms
A weak or aged algorithm is one instance of the generic vulnerability behind two clusters.
Crypto agility, then, is not a threat cluster and not a control against one threat. It is a control on the vulnerability side of the Bow-Tie: it keeps the generic vulnerability from silently reopening as the mechanism ages. That is the cause-oriented framing this framework argues for everywhere else, and it applies here without modification.
Maybe We Should Stop Calling It Crypto Agility
Or at least stop treating it as an isolated cryptographic discipline.
What we are really discussing is controlled rebinding of security objectives to replaceable technical mechanisms over time.
Cryptography happens to be one particularly painful case. The same architectural principle appears everywhere else: identity providers, authentication mechanisms, protocols, cloud services, APIs, software libraries, storage technology, hardware platforms.
Hard coupling creates migration debt. Cryptography merely makes that debt especially dangerous because the mechanism may protect objects whose required lifetime exceeds the lifetime of the mechanism itself.
The Quantum Era Did Not Create the Problem
So yes, organizations should prepare for PQC. They should discover cryptographic dependencies, understand algorithm use, modernize key management, introduce abstraction where it makes architectural sense, plan transitions, test interoperability, and know which data must remain protected beyond today’s cryptographic horizon.
But we should be slightly more skeptical when all of this is sold as a revolutionary new concept called crypto agility. The requirement was there for thirty years. What changed is that PQC has made ignoring it increasingly uncomfortable.
The problem is not that our cryptography suddenly needs to become agile.
The problem is that we spent decades binding long-lived security objectives and information objects to cryptographic mechanisms we always knew would eventually have to change.
That is not a quantum-computing problem.
That is architecture. And it always was.
References
- IETF, RFC 7696, Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms, BCP 201, November 2015.
- IETF, RFC 2246 (TLS 1.0), RFC 2459 (X.509 v3 Internet PKI profile), RFC 2630 (CMS), all 1999.
- IETF, RFC 4998, Evidence Record Syntax (ERS), August 2007.
- IETF, RFC 8996, Deprecating TLS 1.0 and TLS 1.1, March 2021.
- NIST, CSWP 39, Considerations for Achieving Crypto Agility: Strategies and Practices, December 2025 (update 1).
- NIST, SP 800-131A, Transitioning the Use of Cryptographic Algorithms and Key Lengths, 2011.
- NIST, FIPS 203 / 204 / 205, post-quantum standards, August 2024.
- M. Mosca, Cybersecurity in an Era with Quantum Computers: Will We Be Ready?, IEEE Security & Privacy, 2018.
- Beurdouche et al., A Messy State of the Union (FREAK), 2015; Adrian et al., Imperfect Forward Secrecy (Logjam), 2015; Bhargavan & Leurent, Sweet32, 2016; Stevens et al., SHAttered, 2017.