Cryptographic Agility Assessment: Measuring How Fast You Could Swap an Algorithm

The question behind "crypto agility"

Strip the term of its abstraction and there is one operational question underneath it: if an algorithm we depend on were deprecated or found weak, how long would it take us to stop using it?

Not whether it is theoretically possible. How long, in weeks or quarters, given the systems as they are actually built and the engineering capacity that actually exists.

Most organizations have never measured this, because until recently there was no forcing event that made the answer matter. The post-quantum transition supplies one, and it arrives with dates attached — which is what moves agility from a design philosophy to a number you can check your plan against.

Agility is three concrete properties, not a posture

"Agile cryptography" gets described as an architectural virtue. It is more useful as three separate properties, each of which fails in its own way and each of which is measurable on a given system.

Algorithms and parameters live in configuration, not in code. When an algorithm choice, a key size, or a curve is compiled into an application, embedded in firmware, or written into a protocol handler, changing it is a software release — build, test, staged rollout, and every dependency that has to move with it. When the same choice is read from configuration that operations can change, it is a deployment. The difference between those two is usually the difference between quarters and days.

Key and certificate lifetimes fit inside the transition window. A system whose certificates are valid for years cannot complete an algorithm change faster than its own rotation cycle unless someone forces an out-of-band reissue — which is precisely the disruptive, error-prone operation nobody wants to perform under time pressure. Rotation cadence is not just hygiene here; it sets the floor on how quickly the system can change algorithms at all.

Every place cryptography is used is known. This one is prior to the other two. Cryptography that nobody has located cannot be reconfigured, because no one will think to reconfigure it. You cannot make agile what you have not located — an unlocated dependency does not appear in the plan, does not appear in the schedule, and surfaces during the transition rather than before it.

Why deprecation dates make agility measurable

Agility becomes an assessable property rather than an aspiration the moment there is a deadline to measure it against.

NIST IR 8547 deprecates RSA-2048 and ECC P-256 in 2030 and disallows them after 2035. That two-stage structure is what makes the arithmetic possible: deprecation marks when the classical algorithms stop being acceptable for new use, and the disallow date marks the end of the runway. Working backwards from the later date through procurement, testing, interoperability checks, and staged rollout gives each system an implied start date.

An agility assessment compares that implied start date against how long the system would actually take to change. Where the second number exceeds the first, you have found a gap — and you have found it while there is still time to treat it as planning rather than escalation.

This is also why an agility assessment does not depend on predicting when quantum capability arrives. That question is genuinely open and debated among researchers, and no authoritative date exists for it. The deprecation dates, by contrast, are published. A system that cannot change algorithms inside a published window is a problem you can evaluate today, on facts that are already settled.

Locating first: agility gaps hide in what was never inventoried

Because the third property is prior to the others, an agility assessment starts with cryptographic inventory — discovering where and how cryptography is used across systems: the algorithms, key sizes, protocols, certificate lifetimes, and what depends on each.

The inventory is where the specific inflexibilities become visible rather than suspected:

• Algorithm choices compiled into applications or embedded in appliance firmware.
• Certificate and key lifetimes long enough that a rotation cycle overruns the migration window.
• Protocol versions or cipher suites pinned by a counterparty or vendor whose schedule you do not control.
• Shared libraries and key management services that many systems inherit from, where a single inflexible component sets the pace for everything downstream.
• Cryptography in systems that were never in scope for any previous review.

The cryptographic inventory page covers that discovery step in full. What matters for agility is that each finding carries not only *what algorithm is here* but *what it would take to change it* — the second question is the one an agility assessment adds.

Scoring the gaps: five axes, not one rating

A list of inflexibilities implies they all deserve equal attention, which they never do. An algorithm hard-coded into a system protecting short-lived internal sessions is a different problem from the same inflexibility protecting records that must stay confidential for a decade.

Q-Shield scores quantum risk on five axes — a five-axis QRS — so that the highest-risk, longest-lived secrets surface ahead of the rest. Applied to agility, that scoring answers a sharper question than "how inflexible is this system?": *which inflexibility costs the most if it is still there when the deadline arrives?*

The two inputs multiply rather than add. A system that is slow to change and protects data that must outlive the transition window is where the cost concentrates, and a single agility rating averaged across an estate would hide exactly that combination.

From gaps to an order

Scored gaps still need a sequence, because engineering capacity is finite and everything cannot be first. Q-Shield produces a NIST-aligned migration roadmap — toward ML-KEM for key establishment, including a hybrid ECDH + ML-KEM key exchange where that fits — and agility findings shape that order in a few predictable ways:

1. Shared components ahead of their dependents. A key management service or shared library that many systems inherit from sets the pace for all of them. Its agility gap is worth more resolved than any single dependent's.

2. Long rotation cycles need an earlier start, not more urgency. A system whose certificate lifetime is measured in years has to begin sooner simply to complete a cycle in time. That is a calendar fact, independent of how the system scores on risk.

3. Vendor-blocked systems belong in the plan as blocked. An appliance whose vendor has not shipped support is not agile and cannot be made agile by your own engineering. Recording it as an explicitly blocked item with the blocking condition named keeps it visible; omitting it makes the plan look more complete than it is.

4. Configurable systems make useful early moves. Where the algorithm is already a configuration value, the change is cheap enough to establish the testing and interoperability process before that process meets the harder cases.

The migration roadmap page covers how the full sequence is built. Agility findings enter it as the feasibility constraint: risk ranking says what matters most, agility says what can actually move when.

What an agility assessment does not do

• It does not refactor anything. Q-Shield locates, scores, and sequences. Making an algorithm configurable, shortening a certificate lifetime, or rotating a key are changes your engineering teams implement.
• It does not automate algorithm swaps. No part of the assessment changes a running system's cryptography.
• It does not produce a single agility score to report upward. One number averaged across an estate hides the concentration that matters — a small number of slow, long-lived, high-exposure systems.
• It does not establish compliance. Whether a system meets a given obligation is determined by the body that sets the obligation, not by an assessment artifact.

Agility lowers the cost of the next transition; it does not remove it

This is the honest framing, and it is the exact place where the topic invites overclaiming.

An agile system still has to be changed. The configuration layer still has to be tested. Counterparties still migrate on their own schedules, so interoperability work persists regardless of how cleanly your own side selects its algorithms. Validation and approval processes run whether the algorithm came from a config file or a recompile.

What agility changes is the *magnitude*: a transition that would have been a multi-quarter software program becomes a shorter, more predictable operational one. That is a substantial difference, and it is worth measuring and investing in. It is not the same as making the next transition free, and any assessment that implies otherwise has stopped being useful as a planning input.

The practical takeaway is narrower than the term suggests: locate every place cryptography is used, measure how long each of those places would take to change, compare that against the dates that already exist, and fix the gaps in the order where the cost concentrates.