Most organizations think about post-quantum cryptography as a destination: get from RSA and ECC to ML-KEM and ML-DSA, and the work is done. That framing guarantees the work will be done badly, because it treats a recurring problem as a one-time event. The algorithms standardized today will themselves be deprecated someday, and the next transition will arrive faster than anyone expects. The organizations that handle it well will be the ones that built the ability to change algorithms, not the ones that merely changed them once.
That ability has a name: crypto-agility. It is the property of a system that lets you replace a cryptographic algorithm, key, or protocol without rearchitecting the application around it. An agile system treats cryptography as a configurable, swappable component. A rigid system has the algorithm welded into its code, its data formats, and its assumptions, so changing it means a painful, high-risk rebuild. The difference between those two states is the difference between a quiet upgrade and a multi-year crisis.
This post lays out a five-level maturity model for crypto-agility, from Level 0, where algorithms are hardcoded, to Level 4, where systems negotiate and swap algorithms automatically. It describes what each level looks like in practice, how to assess which level you are at, and how to move up. The post-quantum migration is the forcing function; agility is the point.
Reactive vs. Proactive Certificate Management
Score comparison across key operational metrics (higher = better)
🔥 Reactive
4-24hr MTTD · $134K/year · 6+ outages · Burnout
✓ Proactive
<15min MTTD · $15K/year · 0 outages · Planned
Why Agility Is the Real Goal
The reactive version of post-quantum migration is a scramble: a deadline arrives, teams dig through code to find every hardcoded algorithm, and each one becomes a bespoke project with its own risk. The proactive version is a configuration change: the algorithm lives behind an abstraction, the system supports negotiating a new one, and the swap is a controlled rollout rather than an archaeology project. The gap between those two experiences is entirely a function of how much agility was built in beforehand.
This matters beyond post-quantum. Algorithms get deprecated for many reasons: cryptanalytic advances, implementation flaws, regulatory changes, and shifting compliance baselines. Every one of those events asks the same question of your systems, can you change the algorithm cleanly? An organization that answers yes handles each event as routine maintenance. An organization that answers no relives the same crisis every time. Post-quantum is simply the largest and most urgent instance of a problem that recurs indefinitely, which is why building the capability, not just completing the swap, is what actually pays off.
The Five Levels
The model runs from Level 0 to Level 4. Each level is defined by how cryptography is referenced, how keys and certificates are managed, and how much effort an algorithm change requires.
| Level | Name | Algorithm Change Effort | Characteristic |
|---|---|---|---|
| 0 | Hardcoded | Rebuild and redeploy per system | Algorithm welded into code |
| 1 | Aware | Manual, but located | Inventory exists, usage is known |
| 2 | Abstracted | Configuration change per system | Crypto behind interfaces |
| 3 | Managed | Centralized policy change | Governed, inventoried, orchestrated |
| 4 | Agile | Automated negotiation | Systems swap algorithms dynamically |
Level 0: Hardcoded
At Level 0, cryptographic choices are embedded directly in source code, data formats, and infrastructure. A function calls RSA by name. A database column is sized for a specific key length. A protocol parser assumes a signature is exactly a certain number of bytes. Nothing is written down centrally, and no one knows the full extent of where cryptography is used.
Changing an algorithm at Level 0 means finding every one of these sites by hand, editing code, resizing data structures, and redeploying each system individually, with full regression risk each time. This is the state most organizations are actually in, whatever their documentation claims. It is the state that makes post-quantum migration look terrifying, because at Level 0 the migration genuinely is a search-and-rebuild across the entire estate.
Level 1: Aware
Level 1 adds knowledge without yet adding flexibility. The organization has conducted a cryptographic inventory and knows where its algorithms, keys, and certificates live, how long they must remain secure, and which systems depend on them. The cryptography is still hardcoded, so a change still requires editing each system, but now the organization knows what it is facing and can plan the work rather than discover it mid-migration.
This is a meaningful step because discovery is the single largest source of surprise in a migration. An organization at Level 1 can scope and sequence the work accurately. It cannot yet execute it cheaply, but it is no longer flying blind, and the inventory it builds is the foundation every higher level depends on.
Level 2: Abstracted
At Level 2, cryptography lives behind interfaces rather than in line with application logic. Code calls a signing service or a cryptographic provider abstraction, not a named algorithm. Key lengths and algorithm identifiers come from configuration, not from constants. Data formats carry an algorithm identifier so a parser can handle more than one algorithm rather than assuming a single fixed one.
Changing an algorithm at Level 2 becomes a configuration change per system rather than a code rewrite. The abstraction absorbs the difference, so a team can point a service at ML-DSA instead of RSA without touching the business logic that calls it. This is the level at which post-quantum migration stops being frightening and becomes ordinary engineering work, because the thing you need to change is a setting, not a thousand call sites. The investment to reach Level 2 is real, it means refactoring systems to route cryptography through abstractions, but it is the investment that pays back on every future transition.
Level 3: Managed
Level 3 adds governance and centralization on top of abstraction. Cryptographic policy is defined centrally and pushed to systems, rather than configured system by system. There is a continuously maintained inventory, not a one-time snapshot. Certificate and key lifecycles are orchestrated through automation. When the organization decides to change an algorithm, it changes a policy and the change propagates, rather than coordinating dozens of separate configuration edits.
At Level 3, the organization can answer, on demand, what cryptography is in use everywhere and can enforce a change as a governed action with an audit trail. This is the level that makes compliance defensible, because the organization can prove both its current state and its ability to change that state. It is also the level where the cost of a transition drops sharply, because change is orchestrated centrally rather than executed by hand across the estate.
Level 4: Agile
At Level 4, systems negotiate and select cryptographic algorithms dynamically, within policy, without human intervention per change. Protocols negotiate the strongest mutually supported algorithm. Systems support multiple algorithms simultaneously and fall forward to preferred ones as peers gain support. New algorithms are introduced through policy and adopted automatically as the negotiation allows, and deprecated algorithms are retired the same way.
This is the end state the whole model points toward. At Level 4, an algorithm transition is not a project at all; it is the system doing what it was designed to do. The organization adds the new algorithm to policy, systems begin negotiating it, and old algorithms phase out on a schedule, all under governance and audit. The next cryptographic transition after post-quantum, whenever and whatever it is, costs a policy update rather than a program. Few organizations are fully at Level 4 across their estate today, and reaching it for the most critical systems is a reasonable multi-year ambition rather than a near-term expectation.
Assessing Your Level
Most organizations are not at a single level; different systems sit at different levels, and the organization’s effective maturity is set by its weakest critical systems. To assess honestly, examine a representative set of systems and ask a short series of questions.
- Can you produce, today, a complete list of every algorithm, key, and certificate in use, and is that list maintained continuously or was it a one-time effort? No list is Level 0; a one-time list is Level 1; a continuously maintained one points to Level 3.
- When a system uses an algorithm, is the algorithm named directly in code, or does the code call an abstraction and read the choice from configuration? Named in code is Level 0 or 1; an abstraction is Level 2 or higher.
- To change an algorithm in a given system, would you edit and redeploy code, change a configuration value, or change a central policy? Each answer maps directly to a level.
- Can systems support more than one algorithm at once and negotiate which to use? If yes, you are approaching Level 4 for those systems.
The honest answer is usually lower than the aspirational one. The purpose of the assessment is not a flattering score; it is to locate the weakest critical systems, because those set your real exposure during a transition.
Climbing the Model
Movement up the model follows a natural order, and the order is also the order of a well-run post-quantum migration, which is why the migration is the right moment to build agility.
Reach Level 1 by funding discovery first; the inventory is the prerequisite for everything else and the cheapest high-value step available. Reach Level 2 by refactoring systems to route cryptography through abstractions and to carry algorithm identifiers in data formats, prioritizing the systems with the longest-lived secrets and the hardest-to-change verifiers, because those are where rigidity hurts most. Reach Level 3 by centralizing cryptographic policy and automating certificate and key lifecycles, turning the per-system configuration of Level 2 into governed, orchestrated change. Reach Level 4 by building negotiation and multi-algorithm support into the systems that justify the investment, accepting that not every system needs to reach the top level and that the critical ones are where the effort belongs.
The mistake to avoid is skipping straight to swapping algorithms while leaving the estate at Level 0. That completes the post-quantum migration and leaves the organization exactly as unprepared for the next transition as it was for this one. The migration budget is the one chance in years to build the abstraction and governance that make the next transition cheap. Spending it only on the swap wastes the opportunity the swap created.
Agility Is the Deliverable
A post-quantum migration measured only by whether the algorithms changed is a migration that will be repeated, at full cost, the next time cryptography moves. A migration measured by how far it raised the organization’s crypto-agility delivers something durable: the ability to treat the next transition as routine. The five-level model exists to make that progress visible and fundable, so that the work done under post-quantum pressure leaves behind a capability rather than just a new set of algorithms that will someday be old.
Assess where your critical systems actually sit, be honest that it is probably lower than you would like, and spend the post-quantum effort climbing the model rather than merely reaching the far end of a single swap. The destination was never a particular algorithm. It was the ability to change algorithms without flinching.
FAQ
Q: What is crypto-agility and why does it matter more than the specific post-quantum algorithms? Crypto-agility is the ability to replace a cryptographic algorithm, key, or protocol without rearchitecting the systems that use it. It matters more than the specific algorithms because algorithms are deprecated repeatedly over time, for cryptanalytic, regulatory, and compliance reasons. Agility turns each transition into routine maintenance, while its absence turns each one into a crisis. Post-quantum is the largest current instance of a recurring problem.
Q: What are the five levels of the maturity model? Level 0 Hardcoded, where algorithms are welded into code. Level 1 Aware, where a cryptographic inventory exists but code is still hardcoded. Level 2 Abstracted, where cryptography sits behind interfaces and changes are configuration. Level 3 Managed, where policy is centralized, inventory is continuous, and lifecycles are orchestrated. Level 4 Agile, where systems negotiate and swap algorithms automatically within policy.
Q: How do I assess which level my organization is at? Examine representative systems and ask whether you have a continuously maintained cryptographic inventory, whether algorithms are named in code or read from an abstraction, whether changing an algorithm means editing code, changing configuration, or changing central policy, and whether systems can negotiate among multiple algorithms. Your effective maturity is set by your weakest critical systems, not your best ones.
Q: Why is skipping straight to swapping algorithms a mistake? Because swapping algorithms while leaving the estate at Level 0 completes the current migration but leaves the organization just as unprepared for the next transition. The migration budget is a rare opportunity to build the abstraction and governance that make future transitions cheap. Spending it only on the swap wastes that opportunity and guarantees the crisis repeats.
Q: Does every system need to reach Level 4? No. Reaching Level 4 is a reasonable multi-year ambition for the most critical systems, those with the longest-lived secrets and the hardest-to-change verifiers, but not every system justifies the investment. The practical goal is to raise the organization’s weakest critical systems to a level where transitions are configuration or policy changes rather than rebuilds, concentrating the deepest agility where rigidity would hurt most.
About QCecuring
QCecuring helps enterprises treat post-quantum migration as the moment to build crypto-agility, not just swap algorithms. Our platform produces the continuous inventory that moves you off Level 0, maps each critical system to its maturity level, and guides the abstraction, governance, and automation that climb the model, so the next cryptographic transition costs a policy change rather than a program.
Assess your crypto-agility maturity
Tags: Post-Quantum Cryptography, PQC, Enterprise Security, Crypto-Agility, Maturity Model, Cryptographic Inventory, Algorithm Negotiation, Governance, ML-KEM, ML-DSA, Cryptographic Bill of Materials, Migration Strategy, Compliance, Resilience