Crypto-Agility Is Not the Goal. Why Crypto-Agility Requires All Three Legs

Crypto-Agility Is Not a Product

The post-quantum conversation has a vocabulary problem, and the vocabulary problem is producing a strategy problem.

For two years the industry has rallied around "crypto-agility" as the answer to the quantum threat. Vendors sell it. Boards ask for it. Migration roadmaps are built around it. The implicit promise is seductive: build the capability to swap algorithms quickly, and you are protected against whatever cryptanalysis (quantum or classical) eventually arrives.

It is a comforting story. It is also incomplete in a way that will cost organisations dearly.

Crypto-agility, as commonly sold, is the ability to replace a cryptographic algorithm without re-architecting the systems that depend on it. Useful. Necessary. But on its own it solves a problem that has almost never been the one that actually broke things. The history of cryptographic failure is not a history of broken mathematics. It is a history of operational failure: organisations that could not move, could not see what they had, and could not maintain trust while the ground shifted beneath them.

So let me put the argument plainly, because the rest of this piece defends it.

Crypto-agility is not a foundation. It is a platform that rests on three foundations: entropy, interoperability and visibility. Entropy supplies the raw material that makes the mathematics sound. Interoperability ensures that trust holds across every system in the chain, not just the one you upgraded. Visibility, expressed as a cryptographic bill of materials, gives you the ability to see, govern and act on the estate. Remove any one of those pillars and agility does not degrade gracefully. It fails. In several cases it fails worse than the static system it replaced.

Beneath it all sits trust continuity: the base on which the pillars stand and the objective the entire structure exists to serve. The goal was never to swap algorithms. The goal was, and remains, to preserve trust while cryptography changes.

This is not an engineering nuance. It is a governance position. And it is the difference between organisations that will navigate the post-quantum transition and those that will discover, mid-migration, that they bought a platform with nothing underneath it.

The chain is the unit of trust, not the node.

What the industry gets wrong

The dominant framing treats agility as a standalone product. Procure the agile crypto layer, integrate it, tick the box. The framing is wrong because it misdiagnoses what fails.

Look at the record. Not the theoretical record; the actual one.

DES was not broken by a mathematical surprise. Its 56-bit key length was understood to be inadequate from the late 1970s, and the EFF demonstrated a sub-three-day brute-force in 1998 with purpose-built hardware costing under $250,000. The failure was institutional inertia: a standard that outlived its security margin because nobody owned the lifecycle.

SHA-1 collisions were predicted years before SHAttered demonstrated one in 2017. NIST formally deprecated SHA-1 for digital signatures in 2011. Yet SHA-1 lingered in certificate chains, code-signing pipelines, and Git internals for years afterward. Not because anyone disputed the maths, but because nobody could enumerate where it lived, let alone replace it cleanly.

DigiNotar in 2011 was not a cryptographic failure at all. The algorithms were sound. A certificate authority was compromised operationally, fraudulent certificates for high-value domains were issued, and the trust model collapsed, taking the company with it inside months.

Heartbleed in 2014 was a buffer over-read in OpenSSL's implementation of the TLS heartbeat extension. The cryptography was fine. The memory handling was not. A single missing bounds check exposed private keys across a meaningful fraction of the internet.

Symantec's certificate authority business was distrusted by the major browsers between 2017 and 2018. Not because RSA or ECC broke, but because the issuance process, the operational controls and the governance failed repeatedly. Google and Mozilla forced a distrust timeline. One of the largest CAs on earth was unwound by operational failure, not cryptanalysis.

The pattern is not subtle. Cryptography rarely fails in the field because the underlying mathematics was defeated by an adversary. It fails because organisations cannot manage the lifecycle, cannot maintain trust during transition, cannot see their own estate, and cannot generate the raw material that makes the maths sound in the first place.

Crypto-agility addresses the ability to change cryptography. It does not address the foundations that determine whether the change is sound, visible or trustworthy. And selling agility as sufficient is how the industry talks itself into a false sense of readiness.

The three pillars

Strip the marketing away and three things hold the agility platform up. Each is load-bearing. Each is routinely under-governed. Remove any one and the platform comes down.

Pillar one: entropy

Every key, every nonce, every session secret begins as randomness. If the randomness is weak, the platform above it is weak, regardless of algorithm strength, key length, or how quickly you can swap components.

This is not abstract. The 2008 Debian OpenSSL defect, in which a packaging change crippled the entropy source, rendered a vast number of keys predictable for nearly two years. The 2012 "Mining Your Ps and Qs" study found tens of thousands of TLS and SSH hosts sharing or factorable keys because of insufficient entropy at generation time, frequently on embedded and headless devices that booted into low-entropy states. The Dual_EC_DRBG affair demonstrated that a deliberately weakened random source can compromise an entire ecosystem while every algorithm above it remains nominally compliant.

Now layer the post-quantum reality onto this. Lattice-based schemes (ML-KEM and ML-DSA, the algorithms NIST standardised in FIPS 203, 204 and 205) consume substantially more randomness than the classical primitives they replace. Larger keys, larger signatures, sampling operations that draw on the random source far more heavily. The migration that the industry is planning increases entropy demand precisely when most organisations have never measured their entropy supply.

Here is the consequence that should focus the mind: agility on top of weak entropy does not make you safer. It makes you worse off. You have built a platform that generates weak keys faster and rotates them (replacing one predictable secret with another) on a confident schedule. Speed applied to a broken pillar is not resilience. It is accelerated compromise with better reporting.

Most organisations cannot tell you the quality of their entropy sources, cannot audit them, and have no continuous assurance that a virtualised or containerised workload is not booting into an entropy-starved state. That is the first pillar. It is usually invisible.

Article content

Pillar two: interoperability

A cryptographic operation does not happen in one place. A single authenticated transaction traverses a long chain of independent systems, each with its own cryptographic posture, its own libraries, its own assumptions.

Consider an ordinary multinational payment. The request originates on a mobile OS with its own keystore and TLS stack. It crosses a mobile network and a telecom edge. It hits a CDN, then a load balancer, then a web application firewall. It passes through an API gateway, an identity provider performing token issuance and validation, a chain of certificate validations, a hardware security module signing or unwrapping keys, and finally a payment processor with its own cryptographic requirements and its own regulator. Fifteen or more layers. Each independently maintained, frequently by different vendors, often under different jurisdictions.

Now add the geopolitical constraint. The mobile OS vendor uses NIST algorithms for US markets and SM2/SM3 for Chinese markets. The telecom carrier in mainland Asia mandates SM4 under Chinese law. The CDN operates regionally and enforces different cryptographic policies in different zones. The API gateway supports NIST, ETSI, and SM specifications depending on which region the request touches. The identity provider is EU-based and complies with ANSSI hybrid requirements. The HSM is validated to FIPS 140-3. Data residency requirements mean some transactions pass through equipment validated to China's own standards. The payment processor operates globally, but regional compliance means cryptographic validation paths diverge.

Trust holds only if these layers agree. The moment two systems in that chain hold incompatible cryptographic states (one negotiating SM2 key exchange as mandated by Chinese jurisdiction, the next understanding only NIST algorithms as required by US jurisdiction), the transaction either fails closed or falls back to the weakest algorithm both understand. In a geopolitically fragmented environment, that fallback is often classical cryptography. Classical cryptography defeats the entire purpose of the migration. Downgrade is not a theoretical worry; it is the documented mechanism behind FREAK, Logjam and the long tail of protocol-downgrade attacks. In a sovereign divergence scenario, downgrade becomes the default fallback when jurisdictional requirements are incompatible.

Entropy quality enters here too, and this is the part most architects miss. If two systems in the chain draw on random sources of materially different quality, the trust they establish is only as strong as the weaker source, regardless of which algorithms they negotiated. But here is the additional constraint: if the two systems are required by their respective regulators to use incompatible algorithms, entropy quality mismatch becomes secondary to the fact that they cannot negotiate a shared trust state at all. Interoperability is not merely protocol compatibility. It is the alignment of cryptographic quality across every system that participates in establishing trust. When geopolitical requirements mandate incompatible algorithms, interoperability becomes impossible to achieve without either breaking regulatory compliance or falling back to algorithms both jurisdictions deprecate.

This is why agility deployed on a single node is an isolated capability. At enterprise scale, an isolated capability is close to irrelevant. The ability to upgrade one system's algorithm means nothing if the fourteen systems around it cannot speak the new language, or cannot match its entropy quality, or were never even inventoried. You have made one node agile inside a chain that has not moved. The chain is the unit of trust, not the node.

The hybrid transition period makes this acute. For years, classical and post-quantum cryptography will coexist (hybrid key exchanges, dual signatures, mixed estates). During that window the estate holds fragmented trust states by design. Some paths are quantum-resistant; some are not; some negotiate one thing and fall back to another. Trust-state fragmentation is the defining operational risk of the migration, and it is invisible unless you are deliberately engineering for it. This is where CBOM and crypto chaos engineering (deliberately injecting cryptographic faults and downgrade conditions to see how the chain actually behaves) stop being nice-to-haves and become controls.

Article content

Pillar three: visibility

The third pillar is the unglamorous one: the organisational ability to see the cryptographic estate, govern it, and act on it. You cannot manage what you cannot inventory. You cannot rotate what you cannot locate. You cannot prove resilience you cannot measure.

This is the role of a Cryptographic Bill of Materials. A CBOM is the cryptographic analogue of the software bill of materials that regulators now expect: an enumerated, machine-readable inventory of every algorithm, key, certificate, protocol version and cryptographic dependency across the estate, including the ones buried in third-party components and embedded firmware. Without it, agility is a platform you cannot aim. You can swap an algorithm quickly, but you do not know how many places use it, which dependencies break when you do, or whether a critical path still relies on something you deprecated two years ago.

Entropy without interoperability without visibility means the platform above is unsupported. You are operating a system you cannot observe and changing components you cannot fully locate. That is not a migration strategy. It is hope with a budget line.

Why the pillars are inseparable

It is tempting to treat these as three workstreams (entropy here, interoperability there, an inventory project somewhere else). That decomposition is exactly the error. The pillars are not additive. They are interdependent, and the failure modes only appear at the joints.

Weak entropy undermines the platform from below. Weak interoperability fragments it across the chain. Weak visibility means you cannot see either failure until it surfaces as an incident.

Remove the entropy pillar and the agility platform accelerates compromise: faster generation and rotation of predictable keys, which is strictly worse than a static system, because you have added confidence and velocity to a broken foundation.

Remove the interoperability pillar and agility becomes an island: a single node that can change inside a chain that cannot. Trust continuity breaks at the first boundary the upgraded node cannot cross.

Remove the visibility pillar and you cannot govern the platform at all: you cannot see which algorithms are deployed, cannot locate what needs rotating, cannot prove compliance, cannot detect downgrade. Agility becomes a claim you cannot substantiate.

And beneath all three, trust continuity is the base. It is what the pillars exist to preserve and what the agility platform exists to maintain through change. An organisation that loses trust continuity during migration has not failed at cryptography. It has failed at the reason cryptography exists.

This is why I describe the pillars as load-bearing rather than important. Important things can be sequenced and traded off. Load-bearing things cannot be removed without the structure coming down. The three hold the platform up. They have to be governed as one system: not three programmes with three owners and three budgets that meet at a steering committee.

The operating environment makes this harder, not simpler

None of this happens in a controlled lab. It happens in an environment that is fragmenting under regulatory and geopolitical pressure, which raises the cost of getting the pillars wrong.

This is not theoretical. Cryptographic sovereignty is fragmenting, and the divergence is structural, not cosmetic.

The United States has set a binding trajectory through NSA's CNSA 2.0, mandating ML-KEM, ML-DSA and SLH-DSA for classified and defence systems with explicit milestones through 2035. NIST has standardised these as FIPS 203, 204 and 205. The timeline is non-negotiable.

The European Union is moving to ETSI specifications aligned with ENISA and NIS2 enforcement. Germany's BSI mandates hybrid constructions during transition. France's ANSSI maintains independent validation requirements. The EU position is not a slower adoption of US standards. It is a distinct regulatory regime with incompatible requirements.

China's Cryptography Law mandates SM2, SM3 and SM4 across telecommunications, finance and critical infrastructure. These are not optional. They are statutory requirements. China is not adopting NIST algorithms. It is advancing a parallel cryptographic regime.

A multinational organisation operating across these jurisdictions faces a geopolitical constraint, not a migration problem. It must simultaneously support NIST algorithms in US operations, SM2/SM3/SM4 in China, and ETSI specifications in Europe. These are incompatible mandates operating on different timelines under different regulators with different enforcement teeth.

This is the operating environment. Not a global standard with regional variants. A fragmented cryptographic landscape in which no organisation can claim alignment to a single sovereign regime. The assumption that organisations are migrating from one stable cryptographic state to another has not been realistic for years. Permanent cryptographic heterogeneity, with different jurisdictional requirements coexisting indefinitely, is now the baseline.

Layer on the operational-resilience regulations that now carry real consequences. DORA is in force across EU financial entities, with explicit requirements on ICT risk, third-party dependency management and resilience testing. NIS2 has widened the scope of mandatory cybersecurity obligations across critical sectors. These regimes do not ask whether your algorithms are fashionable. They ask whether you can demonstrate control of your estate, your dependencies and your ability to maintain service through disruption. That is a question about the three pillars and the platform they support, not about the platform alone.

And the supply chain constrains what any single organisation can do. You do not control the cryptographic posture of your CDN, your identity provider, your HSM vendor or the embedded crypto in devices you bought and cannot easily patch. The history makes the point: PCI DSS mandated the migration away from early TLS, requiring SSL and TLS 1.0 to be retired by June 2018. The long, painful tail of that deadline, years in the making, is a preview of how slowly a heterogeneous supply chain actually moves. The post-quantum migration is larger in every dimension. Anyone planning it as a clean internal upgrade has not priced in the chain.

Article content

The governance position

Here is where I will be blunt, because the audience for this piece is not the engineering team.

This is not, at root, an engineering-optimisation problem. It is a fiduciary, resilience and geopolitical problem that happens to have cryptography at its centre. The board-level question is not "have we adopted post-quantum algorithms." It is: can we maintain trust continuity across our estate while the cryptographic ground shifts under competing regulatory obligations, across sovereign divergence, and through a multi-year hybrid period in which our trust states are fragmented by design and geopolitical requirement.

That reframing matters because it changes who owns the problem and how it is measured. Engineering optimisation asks: is this fast, is this efficient, is this standards-compliant. Governance asks: can we see it, can we prove it, can we sustain it across jurisdictional boundaries, can we navigate competing sovereign requirements without breaking compliance, and can we answer for it when a regulator or a board risk committee demands evidence. Those are different questions with different success criteria. The second set is the one that determines whether the organisation is actually resilient.

Provenance, lifecycle, risk and jurisdictional mapping are the governing concepts. Provenance means knowing where every cryptographic dependency came from, what it relies on, and which sovereign regime imposes requirements on it. Lifecycle means owning the full arc from key generation through rotation to retirement, including the entropy at the start and the deprecation at the end, while maintaining compliance across jurisdictions with different timelines. Jurisdictional mapping means understanding which cryptographic regimes operate in which parts of the organisation and whether those regimes are compatible with each other. Risk means expressing the cryptographic posture of the estate in terms a risk committee can act on, including the risk that competing sovereigns may impose incompatible requirements simultaneously. An organisation that can do these four things is governing a system across geopolitical constraint. An organisation that has bought an agility product and deployed it without accounting for sovereign divergence is holding a platform with no pillars beneath it and no base beneath them.

What organisations must actually do

This is the part that turns the argument into an operating plan. None of it is exotic. All of it is currently rare.

Inventory before you act. Build the CBOM first. You cannot govern, migrate, or prioritise an estate you have not enumerated. Make it machine-readable, keep it current, and extend it into third-party and embedded components. Critically, annotate which jurisdictional cryptographic regimes apply to each component. A system in China has different requirements than a system in the US. A transaction that crosses both has conflicting requirements. Treat the absence of a CBOM as the first finding, not a precondition you assume is met. This is the visibility pillar. Without it, the other two are ungovernable and the platform above them is blind.

Map the jurisdictional cryptographic landscape. Document which cryptographic regimes apply in which operating regions. NIST algorithms for US operations. SM2/SM3/SM4 for China. GOST for Russia. ETSI and ANSSI guidance for Europe. CRYPTREC for Japan. KCMVP for South Korea. Identify where these requirements are compatible and where they are not. Identify which transactions cross jurisdictional boundaries and which cryptographic fallback paths exist if primary algorithms diverge. This is not an engineering exercise. It is a strategic mapping of where interoperability becomes impossible.

Measure entropy as a first-class control. Audit your random sources. Establish continuous assurance that workloads (particularly virtualised, containerised and embedded ones) are not booting or operating in entropy-starved states. Validate against recognised criteria rather than vendor assertion. Recognise that different jurisdictions may have different entropy validation requirements. China may require specific QRNG sources. The EU may require specific DRBG parameters. The US may have its own validation regime. Do this before you increase entropy demand by adopting lattice-based schemes. Not after.

Engineer for the hybrid period deliberately. Accept that fragmented trust states are the reality for years, and instrument for them. Map every path that can downgrade. Apply crypto chaos engineering (deliberately injecting cryptographic faults, mismatches and downgrade conditions in controlled conditions) to learn how the chain behaves under stress before an adversary teaches you. Add jurisdictional stress testing: simulate what happens when a transaction requires SM2 in one region and NIST in another, with no shared algorithm available except deprecated classical cryptography. Treat downgrade-by-default as a defect to be hunted, not an acceptable fallback. Treat jurisdictional incompatibility as a crisis to be engineered out, not a business constraint to be accepted.

Govern interoperability as a chain property. Inventory the full cryptographic path of your critical transactions and the jurisdictions each layer touches. Identify where entropy quality and algorithm support diverge across that path. Identify where jurisdictional requirements become incompatible and no shared algorithm exists. Hold vendors to a posture, not a checkbox, and write cryptographic-resilience obligations into the contracts where the supply chain controls what you cannot. Include explicit provisions for jurisdictional divergence: what happens when US regulatory requirements collide with Chinese regulatory requirements in a single transaction path. Specify fallback cryptography explicitly and ensure both jurisdictions accept it.

Govern the three pillars as one programme. One owner accountable for entropy, interoperability and visibility together, expressed in the language of provenance, lifecycle and risk, and reported to the board against the resilience and regulatory obligations that actually bind you. Not three teams optimising three metrics that look healthy in isolation while the platform fails at the joints.

The close

Those that come through the post-quantum transition intact will not be the ones that adopted the new algorithms first. Algorithm adoption is the easy part, and being early confers no advantage if the pillars underneath are unsound or if early adoption creates regulatory exposure in jurisdictions where different algorithms are mandated.

They will be the ones that understood crypto-agility was never the goal. It was always the platform: the thing that rests on top of the foundations, not the thing that holds them up. The foundations are entropy, interoperability and visibility. The base beneath them is trust continuity. The platform is agility. The structure stands or falls together.

The history is unambiguous. Cryptography does not usually fail because the maths broke. It fails because organisations could not move, could not see, could not maintain trust through change, and could not generate sound randomness at the base of it all. It also fails when organisations must operate across jurisdictions that impose incompatible cryptographic requirements and they have not planned the interoperability strategy to navigate that incompatibility. The quantum threat does not change that pattern. It amplifies it. More demand on entropy. More layers to keep interoperable. More sovereign regimes to satisfy. More conflicting requirements to reconcile. More dependencies to govern. All at once.

Crypto-agility is not a product. It is not a feature. It is not the ability to swap algorithms on demand. It is a platform for preserving trust while cryptography changes.

That platform rests on three pillars: entropy, interoperability and visibility. Beneath them sits trust continuity, which is both the foundation and the objective. Remove any pillar and the platform comes down. Neglect the base and the pillars have nothing to stand on.

The post-quantum transition will not test algorithms first. It will test whether organisations understood what holds the platform up. It will test whether they can maintain trust continuity across jurisdictions that mandate incompatible regimes. It will test whether they can move without breaking compliance, without losing visibility, without creating points of catastrophic failure.

Organisations that understood the structure will navigate the transition. Organisations that bought the platform without building the pillars will discover, mid-implementation, that they purchased a capability with nothing beneath it.

That distinction determines whether the transition is a controlled evolution or a systemic crisis.