Cryptographic agility is the only honest answer to 'when will quantum arrive?'

The honest answer to "when will a cryptographically-relevant quantum computer arrive" is that nobody knows. The estimates from credible labs range from the early 2030s to the early 2040s, with most clustered around the middle of that range. Anyone who tells you they have a more precise number is selling you something.

This creates a planning problem. A vehicle shipped today will still be on the road in 2041. The cryptography that secures it has to last that long. If the manufacturer waits for certainty about quantum timelines, the certainty arrives after the vehicles are already in the field, and at that point the migration is happening under pressure rather than by design.

The standard response to this kind of problem is to deploy the strongest available defence today. That works for most security problems. It does not quite work for cryptographic algorithms, because the strongest available post-quantum defence today might not be the strongest available defence in 2030. NIST is still running competitions. New attacks on lattice-based schemes appear periodically. The algorithm landscape will evolve, and the vehicles in the field have to evolve with it.

The technique that makes this possible is cryptographic agility. It is the most important architectural property a modern vehicle security platform can have, and it is also the most misunderstood. This post is about what it actually is and what it actually requires.

What people mean when they say "agility"

The marketing definition of cryptographic agility is something like "the ability to upgrade cryptographic algorithms in deployed systems without re-architecture." That definition is true and almost useless. Every vendor claims it. Most of what gets shipped under the label is closer to a feature flag for cryptographic primitives than a real architectural property.

The engineering definition is more demanding. A system is cryptographically agile if, given a new algorithm with the same interface as an existing one, the operator can deploy the new algorithm to the entire fleet through a configuration change, without recompiling, reflashing, or reissuing certificates. The new algorithm has to be selectable per-cohort, rollback-able, and auditable. The system has to be able to operate with two algorithms simultaneously during the transition.

A useful test for whether a system is genuinely agile is this. If a vulnerability is announced in ML-DSA-87 tomorrow morning, can the security team push a fleet-wide switch to FALCON-512 by the end of the week? If the answer involves recompiling firmware or reflashing ECUs, the system is not agile. If the answer is "we publish a new signed manifest and the fleet picks it up on next boot," the system is agile.

The architectural pattern

Cryptographic agility, done correctly, has three architectural elements. The first is the absence of hard-coded algorithm identifiers in the code that uses cryptography. The second is a signed registry of algorithm identifiers, separate from the code, that maps capabilities to implementations. The third is an operational pipeline that can update the registry, validate it against the current fleet's capabilities, and roll it out with the same controls as any other safety-critical OTA campaign.

The first element looks like this in practice. A piece of code that needs to sign a message does not call ml_dsa_sign(message, key). It calls crypto.sign(capability="signing", message, key). The dispatch from "signing" to a specific algorithm happens at runtime, looking up the algorithm in the registry. If the registry says ML-DSA-87 today, ML-DSA-87 runs. If the registry says FALCON-512 tomorrow, FALCON-512 runs.

The cost of this pattern is real but small. There is a function-call indirection that costs maybe ten nanoseconds. There is a memory cost for the registry itself, probably a few kilobytes. There is a complexity cost in the boot sequence, because the registry has to be loaded and verified before any cryptographic operations can occur. These costs are not the reason people skip the pattern. The reason people skip it is that it requires discipline at the code-review level. Every cryptographic call has to go through the dispatch. Every cryptographic constant has to live in the registry. The first time someone hard-codes ML-DSA-87 because it's easier, the agility property is broken until the next refactor.

The registry is the load-bearing part

The registry deserves more attention than it usually gets. A registry is just a signed manifest of algorithm capabilities, with versioning and rollback paths. The structure is straightforward. The operational requirements are not.

A working registry has to answer at least the following questions. Which algorithms are currently active, and for which capabilities? Which algorithms are deprecated but still verifiable? Which algorithms are completely retired? Which combinations are valid as hybrids? Which signing keys correspond to which algorithm versions? What is the rollback path if the new algorithm has a problem?

Each of those questions translates to a field in the registry schema, and each field has to be authoritatively answered for every vehicle in the fleet. The registry is itself a piece of critical infrastructure, and it needs to be designed with the same care as the rest of the vehicle's security stack. We have seen registries implemented as JSON files signed with a root key. We have also seen them implemented as in-vehicle databases with their own consensus protocols. The right answer depends on the operational scale, but the basic property — every vehicle agrees on the current registry — is non-negotiable.

The registry update path is where most agility programmes fail. Pushing a new registry to ten million vehicles is an OTA campaign with the same risks and controls as any other. It has to be staged. It has to be canaried. It has to be rollback-able. If the new registry breaks something on five percent of the fleet, the operations team has to be able to revert to the previous registry in under an hour. That capability has to exist before the registry update is sent, not be designed after the fact.

What hybrid actually means

A frequent source of confusion is the difference between cryptographic agility and hybrid cryptography. They are related but not the same thing.

Hybrid cryptography is the practice of combining a classical algorithm and a post-quantum algorithm in a single operation, such that the result is secure if either algorithm is secure. A hybrid key exchange combines, for example, X25519 and ML-KEM, with both contributing to the final shared secret. If ML-KEM is broken, the X25519 component still provides classical security. If X25519 is broken by a quantum computer, the ML-KEM component provides post-quantum security. Hybrid is a belt-and-braces design that exists specifically because nobody is willing to bet a vehicle's security on a single algorithm during a transition.

Cryptographic agility is the architectural property that lets you change the algorithms inside a hybrid construction, or change from hybrid to pure post-quantum, or move to a different post-quantum algorithm if the current one is compromised. Agility is about being able to change. Hybrid is what you change to and from.

A platform can be hybrid without being agile (a hard-coded X25519 + ML-KEM combination is hybrid, but if you cannot replace either side without a firmware update, you have hybrid without agility). A platform can be agile without being hybrid (a system that runs pure ML-KEM today but could swap to FALCON tomorrow is agile but not hybrid). The strongest position is both. A hybrid cryptographic envelope, with agile selection of the algorithms inside.

What this looks like during a real migration

An agile platform handles the next decade of cryptographic uncertainty as follows. Today, the registry specifies hybrid X25519 + ML-KEM-1024 for key exchange, ML-DSA-87 for signatures, and SLH-DSA for long-term archival signatures. The fleet runs this configuration.

Eighteen months from now, a vulnerability in ML-DSA-87 is announced. The security team validates the issue, picks FALCON-512 as the replacement, tests it on the bench, runs it through HiL and a canary cohort, and pushes a registry update. The fleet picks up the new registry, switches to FALCON-512 for new signing operations, continues to verify ML-DSA-87 signatures issued before the cut-over. No firmware update. No re-flashing. No supply-chain coordination beyond the registry update itself.

Three years from now, NIST finalises an algorithm we do not currently anticipate, with better properties than ML-DSA or FALCON. The registry is updated to add it as an option, then to make it primary, then to deprecate the older algorithms over a transition period. The fleet moves through the transition without any vehicle being out of service.

This is not an optimistic projection. This is what the architecture is designed to do. The work happens up front, in the design of the dispatch layer and the registry. The work does not happen during the transitions. That is the entire point.

The honest answer

The honest answer to "when will a cryptographically-relevant quantum computer arrive" is that the question is the wrong question for vehicle security. The right question is "how quickly can we change cryptographic algorithms when we need to, regardless of why we need to." The reasons could be a quantum computer. They could also be a new lattice attack, a new standard, a regulatory change, a procurement constraint, or any of the other reasons cryptographic algorithms get replaced over the lifetime of a long-lived platform.

Cryptographic agility is the answer to all of those questions at once. Build it in once, at the start, and the platform is resilient to a class of risks you cannot enumerate in advance. Skip it, and every cryptographic change becomes a vehicle-wide migration project.

Quantum computing is a useful forcing function for thinking about this. It is not the only reason to do the work. The work would be valuable even if quantum computing turned out to be physically impossible. The fact that it is also a possible future threat is why most platforms are doing the work now rather than waiting.

---

Digital North works with OEMs on cryptographic agility architecture, post-quantum migration sequencing, and the operational tooling that makes algorithm swaps a routine event rather than a fire drill.