up:: Migration Architecture MOC

Crypto-Agility

Crypto-agility is the architectural property that lets a system change, upgrade, or replace its cryptographic algorithms without a redesign or a code rewrite. An agile system treats the choice of algorithm as a configuration decision rather than a baked-in assumption, so swapping one primitive for another is a settings change instead of an engineering project. In the post-quantum transition this stops being a nice-to-have. It is the structural prerequisite that makes migration possible at scale, which is why CISOs insist on it: they want to change algorithms once, cleanly, and never run this migration again from scratch in five years.

The short version:

• Crypto-agility separates what algorithm to use from how to use it, so the choice lives in configuration, a policy file, or a central service rather than scattered across application code.
• With it, replacing a quantum-vulnerable algorithm is a central change that propagates everywhere. Without it, every application that touches cryptography has to be found, opened, and rewritten one at a time.
• It is a migration enabler, not a security control. It gives you the ability to change the algorithm; it does not make the new algorithm secure. Governance has to ride alongside it.
• There are two tiers to it: algorithm agility (swap the primitive) and architectural agility (change the trust model and key-distribution design). Most vendors mean the first when they say “crypto-agile”; the second is where deployments quietly stay brittle.
• Agility is Phase 1 work. Assessing and remediating it comes before algorithm replacement, because whether a system has it decides the cost and timeline of everything downstream.

Think of it like the electrical system in a house. A house wired to a standard outlet lets you unplug an old appliance and plug in a new one whenever a better model comes out. A house where every appliance is soldered directly into the wall behind the drywall forces you to open the walls and call an electrician every time something needs to change. Cryptographically, most legacy systems are soldered in. Agility is the outlet: the new algorithm plugs into the same socket the old one used.

What is crypto-agility?

Crypto-agility is an architectural design property, not a specific product or technology. Every algorithm eventually fails, through cryptanalysis, through raw computational advances, or, in the current case, through a new computational model that quantum computers make real. Systems that hardcode their algorithm choices have to be fully redesigned when that day comes. That is exactly how organizations end up running SHA-1 or DES for years past their deprecation dates: changing the algorithm was simply too expensive, so nobody did.

Agility solves this by centralizing the decision. When algorithm selection lives in one abstraction layer, library, or service, a single change reaches everywhere at once. When it is spread across thousands of individual implementations, each one has to be located and changed independently. The property spans every layer where cryptography is used: TLS and other network protocols, PKI, application-layer signing, key management, and firmware.

The governing guidance treats it the same way. NIST IR 8547 frames agility as a prerequisite for the transition, NSA CNSA 2.0 sets migration expectations that assume it, and NIST SP 800-175B situates it within general cryptographic-standards guidance.

Source: NIST IR 8547, Transition to Post-Quantum Cryptography Standards; CNSA 2.0.

A note on precision

“Crypto-agility” is used loosely in vendor marketing. The useful definition is operational, not aspirational: can you actually change the algorithm a running system uses, centrally, without touching every application that depends on it? If the honest answer is “we would have to reopen the code,” the system is not agile, whatever the datasheet says.

Why does it matter for the quantum transition?

Every organization is going to replace its quantum-vulnerable algorithms. The only question is whether that replacement means touching every application that uses cryptography, which is a massive and error-prone undertaking, or whether it can happen centrally through an abstraction layer. Agility is what decides which of those two migrations you get.

Without it, the harvest-now-decrypt-later problem compounds. The organization’s already-collected ciphertext is exposed, and the organization cannot migrate fast enough to close the window before a cryptographically relevant quantum computer arrives. Mosca’s Theorem frames this as a race: migration has to finish before the threat lands. That model assumes migration takes some number of years. For a non-agile estate, that number is measured in decades rather than years, because the work is redevelopment rather than reconfiguration. Building agility first is what compresses the timeline for everything that follows, which is why it earns its place ahead of the algorithm swaps themselves.

Historical parallel

When Mary, Queen of Scots corresponded from captivity during the 1586 Babington Plot, she trusted a nomenclator cipher that Francis Walsingham’s cryptanalyst, Thomas Phelippes, had already solved. Every “secret” message was being read as she wrote it, and the decrypted letters became the evidence that convicted her; she was executed in February 1587. The failure was that she had no way to recognize the cipher was broken and no way to change it. That is the crypto-agility lesson in its oldest form: a system that cannot retire a compromised algorithm keeps trusting it long past the point of safety.

Source: Simon Singh, The Code Book.

What does agile cryptography look like in practice?

Agility is achieved through a handful of related patterns, and most real deployments combine several of them. The common thread is that application code stops naming a specific algorithm and instead asks for a cryptographic operation, leaving the choice of algorithm to a layer that can be changed centrally.

Pattern	How it works	Where it fits best
Abstraction API layer	Applications call generic operations (sign(message), encrypt(data)) instead of a specific primitive (RSA_sign(message, 2048)). A central module resolves the actual algorithm from policy at runtime.	In-house applications whose source you control.
Crypto-as-a-service	A dedicated internal service, KMS, or HSM-backed API performs all cryptographic operations. Applications are algorithm-unaware; upgrades happen at the service.	Large estates with many applications; the most scalable pattern.
Provider / plugin architecture	New algorithm implementations load into an existing framework (Java’s JCA/JSSE, PKCS via HSMs, OpenSSL providers) without recompiling the application.	Ecosystems that already have a provider model.
Protocol negotiation	The protocol negotiates the algorithm at connection time; server and library configuration decide what is allowed.	Network protocols (TLS, IPsec, SSH), where agility is often already built in.

The provider pattern shows how light the change can be when the architecture supports it. In a 2026 banking proof-of-concept, moving a Java API gateway to hybrid post-quantum TLS required registering the BouncyCastle post-quantum provider at application startup and nothing else. Once the provider was in place, a TLS configuration naming the X25519MLKEM768 hybrid key-exchange group was handled transparently inside the provider stack, and the application’s own code saw an unchanged TLS interface. The team swapped the provider, not the application.

Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).

That same work points to a deeper habit: agility in a TLS estate is a continuous discovery-and-assessment loop, not a one-time project. The pipeline that builds the initial cryptographic inventory (extract each termination point’s configuration, classify every cipher suite by quantum risk, prioritize by exposure, deploy the hybrid configuration, then re-check) becomes the ongoing monitoring layer afterward. You keep re-parsing to confirm vulnerable primitives stay gone and to catch regressions.

Source: Balaji et al., arXiv:2605.17955 (2026).

Algorithm agility vs architectural agility

A distinction the agility conversation usually skips: replacing a primitive and evolving the surrounding architecture are two different capabilities, and a system can have the first without the second. A published 2026 review of quantum-resistant networks draws the line explicitly.

	Algorithm agility	Architectural agility
What changes	The cryptographic primitive itself.	The trust model, key-distribution architecture, and lifecycle posture.
Example moves	Swap ML-KEM for HQC; rotate SHA-256 to SHA-3; move from RSA to ML-DSA.	Move from centralized PKI to distributed or threshold key distribution; shift from long-lived certificates to short-lived credentials; add a recovery mechanism for a compromised certificate authority.
Difficulty	Well-understood, protocol-feature level, standards-driven.	Significantly harder, rarely advertised, the real differentiator between quantum-ready and quantum-brittle.

The review states it plainly: “Cryptographic agility in PQ networks should be treated as a design objective, not simply as a protocol feature. Organizations should distinguish between algorithm agility (the ability to replace cryptographic primitives) and architectural agility (the ability to evolve trust models, key-distribution architectures, and lifecycle controls). Networks that lack these properties may remain brittle even after adopting PQ algorithms.”

Source: Bertino et al., “Quantum-Resistant Networks,” arXiv:2605.04129 (2026), §10.2.

The implication for a roadmap is that algorithm-only agility is a partial achievement. A deployment that can swap ML-KEM for another KEM but cannot move off a centralized PKI when its trust model needs to change still faces a multi-year redesign the moment the threat picture shifts. Worth asking of any estate:

1. Can it migrate from centralized to distributed trust without redesigning the application layer?
2. Can it shift from long-lived certificates (years) to short-lived credentials (hours) without breaking authentication?
3. Can it introduce a recovery mechanism for the certificate authority or key-distribution service without re-platforming?
4. Are the trust boundaries between architectural layers documented, so one layer can change without cascading risk into the others?

A “no” on any of these is a real gap, separate from and usually larger than the algorithm-swap question.

How fast do you need to be able to change algorithms?

Agility is about whether you can change an algorithm and about how quickly you can do it. An estate that can technically reconfigure a primitive but takes 18 months to do it in production is barely more agile than one that cannot change at all, because the exposure window stays open the whole time. The practical target is that a primitive can be retired and replaced on a timeline short enough to matter when a weakness is disclosed, not on the pace of a hardware refresh cycle. A useful way to think about it: if a serious flaw in your primary algorithm were announced tomorrow, how long until every system that depends on it is running something else? For most enterprises today the honest answer is uncomfortably long, and shrinking it is the point of building agility before the migration, not during it.

Does crypto-agility apply to symmetric algorithms too?

Historically the agility conversation focused on asymmetric primitives, the RSA-to-ML-KEM and ECDSA-to-ML-DSA swaps, because those are what a quantum computer breaks outright. That scope has widened. An April 2026 hardware demonstration extended a known quantum attack to a class of symmetric constructions, which means a modern agility expectation now includes being able to replace vulnerable symmetric primitives without touching every application, the same standard already applied to the asymmetric side.

Source: Köhler et al., arXiv:2604.25509 (2026).

The place this bites hardest is firmware. Deployments that hardcode a symmetric primitive into IoT or operational-technology firmware are structurally non-agile on the symmetric side, with the same multi-year replacement windows that hardcoded asymmetric crypto creates. New deployments should make symmetric primitive selection configurable from the start, for the same reason they make the asymmetric side configurable: so the next change is a setting, not a field replacement.

What crypto-agility does and does not guarantee

Agility is a migration enabler, not a security mechanism. It does not itself provide confidentiality, integrity, or authentication. It provides the ability to change the mechanisms that do.

• What it gives you: a system that can respond to algorithm compromise or deprecation in a controlled, rapid, central way, instead of a multi-year redevelopment.
• What it does not give you: any guarantee that the new algorithm is a good one. An agile system will happily deploy a weak algorithm as easily as a strong one, which is why policy and governance have to travel with it.
• A trap to close: systems that negotiate algorithms have to defend against downgrade attacks, where an adversary forces the negotiation down to a weaker set. Properly built agility includes a minimum-floor policy that blocks negotiation below an acceptable security level.

There is also a cost to the abstraction itself. A crypto-abstraction layer is code that everything depends on, so it has to be well-audited; a bug there is a bug everywhere. And agility creates a governance dependency: an algorithm that can be changed has to be governed so that it is changed, correctly and on time. Agility without a migration plan is still an exposed system.

What does crypto-agility mean for your inventory and roadmap?

Crypto-agility is a property of a system rather than a cryptographic artifact, so it does not show up as a line item in a cryptographic bill of materials. It changes how much that inventory is worth, though. During discovery, the question is whether each system configures its algorithms centrally or has them scattered and hardcoded. Evidence looks like code reviews or static analysis showing an abstraction layer, service logs showing algorithm parameters passed as configuration, or negotiation logs showing real flexibility.

The finding that matters most is the absence of agility. A system that cannot change its algorithms centrally has a fundamentally different migration cost and timeline than one that can, and that fact alone should raise its priority in the plan. On the roadmap, agility assessment comes first: identify the non-agile systems, remediate the architecture where it is feasible, and only then attempt the algorithm replacement, because for those systems the replacement is not possible at reasonable cost until the architecture changes.

Vendor-controlled surfaces deserve their own line of questioning here. Where cryptography lives inside a product you do not control (vendor-controlled crypto surfaces), agility depends entirely on the vendor’s willingness to ship a post-quantum-capable upgrade, and a vendor that hardcodes its algorithms is quietly deciding that your next migration will be a construction project rather than a configuration change. That is the part that rarely surfaces in a procurement conversation, and it belongs in the contract before the migration, not after.

Common misconceptions

• “We use TLS, so we’re fine.” Using a protocol that supports negotiation is not the same as being able to change cipher suites centrally across the estate. The real diagnostic is whether you can change the negotiated algorithms without opening 200 application configurations by hand.
• “Crypto-agility is the migration.” It is the thing that makes the migration feasible, not the migration itself. An agile system with no plan and no execution is still running vulnerable algorithms.
• “Agility means the abstraction handles security for us.” Agility only enables the swap. The strength of what you swap to, and the discipline to actually swap, are separate and still your responsibility.
• “We can add it later.” Retrofitting agility into a hardcoded system is most of the cost the migration was trying to avoid. It is cheapest by far to build in at greenfield or major-rewrite time, and every system with a long operational lifespan should have it from the start.

---

Everything here is the map, given freely. When your team needs its own estate assessed for agility and sequenced into a real migration plan, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.