The Maturity Model (0-5) — Quantum-Safe: Migration and Governance

“Are we ready?” sounds like a reasonable question until someone has to answer it. Ready for what systems, what data, what deadlines, and what kind of cryptographic change? A maturity model makes the question useful by turning it into a ladder. In this model, Level 0 means the organisation has not yet recognised the quantum risk. Level 5 means cryptographic change is routine: algorithms can be replaced without a crisis, inventories stay current, and new guidance is monitored continuously. Most organisations will sit somewhere in between, and that is the point. The number is not a badge. It is a way to see the next honest move.

Why a maturity model helps

Post-quantum readiness is not a single task. It includes awareness, ownership, discovery, risk classification, planning, implementation, and long-term operational discipline. Without a model, these activities blur together. One team may say it is “working on quantum” because it attended a briefing. Another may say the same because it is testing post-quantum cryptography in production. Those are very different states.

A maturity model gives shared language to that difference. It does not replace engineering judgement, but it makes discussions more concrete. A board can ask what level the organisation is at. A security team can show why it gave that score. A programme lead can explain the next action needed to move up one rung.

The safest way to use the model is modestly. Score current capability, not ambition. Record evidence, not impressions. Accept that a large organisation may not have one score. A payments platform, an internal human resources application, and a legacy manufacturing network may be at different levels, and each may deserve its own rating.

📌

Use evidence. A maturity score is useful only when it is backed by artefacts such as an inventory, risk scoring, approved funding, or production deployment records.

Level 0 and Level 1: from silence to ownership

Level 0 is unaware. The organisation either does not know that quantum computing creates a future risk to widely used public-key cryptography, or it dismisses the issue as distant science fiction. No one owns the topic. If you ask architecture, security, compliance, procurement, and application teams what the organisation is doing about quantum-safe migration, the common answer is a blank look.

The next move from Level 0 is not a tool purchase or an algorithm choice. It is awareness and ownership. Senior technology and risk leaders need a short, factual briefing: what may break, why long-lived sensitive data matters, and why migration planning takes time. Then someone must be named as the owner, even if the first owner is only responsible for starting discovery.

Level 1 is aware. At this level, someone understands the issue and has raised it. There may be a security champion, an architect tracking standards, or a risk manager asking questions. But the organisation still lacks systematic data. It cannot yet answer where cryptography is used, which systems depend on vulnerable algorithms, or which data has a shelf life long enough to be exposed to “harvest now, decrypt later” attacks.

The next move from Level 1 is discovery. Awareness without discovery is only a conversation. Discovery begins the work of finding cryptography across applications, infrastructure, identity systems, cloud services, software dependencies, certificates, protocols, signing processes, and third-party integrations.

Level 0 signal: no owner, no shared understanding, and no recognised programme.
Level 0 next move: brief leadership and assign accountability.
Level 1 signal: a champion exists, but there is no reliable data.
Level 1 next move: start cryptographic discovery.

Level 2: inventoried, not merely interested

Level 2 is inventoried. The defining artefact is a Cryptographic Bill of Materials, or CBOM. A CBOM is an inventory of where and how cryptography is used across the estate. It should capture enough detail to support decisions: algorithms, key lengths, protocols, certificates, libraries, products, data flows, owners, environments, and last verification dates.

The word “living” matters. A spreadsheet created during a one-time assessment and forgotten for a year is not enough. A useful CBOM is refreshed when systems are deployed, changed, scanned, or reviewed on a defined schedule. Each entry should have an owner and a last-verified date. Without that discipline, the inventory becomes a snapshot of the past rather than a guide to present risk.

Level 2 lets the organisation answer a basic question: what cryptography do we use? It does not yet mean the organisation knows what to fix first. The next move is assessment and prioritisation. That means combining the CBOM with risk information: which systems protect long-lived data, which are externally exposed, which support critical business services, which depend on Rivest-Shamir-Adleman encryption or elliptic curve cryptography, and which are constrained by vendors or legacy platforms.

⚠️

Inventory test. If the inventory is not refreshed by deployment events or a scheduled review process, treat it as evidence of Level 1 activity rather than Level 2 maturity.

A cryptographic bill of materials must refresh as systems change.

Level 3: planned means risk-scored and resourced

Level 3 is planned. At this stage, the organisation has taken the inventory and turned it into a migration roadmap. The plan is not just a list of systems that use old cryptography. It classifies data by shelf life, scores systems by business and technical risk, identifies dependencies, assigns owners, and places work into waves with dates.

Data shelf life is central. Some data loses value quickly. Some must remain confidential for years or decades: health records, government material, intellectual property, legal archives, strategic plans, credentials, and personal data subject to retention rules. Systems protecting long-lived sensitive data often deserve earlier attention because encrypted traffic or files captured today may be decrypted later if the underlying algorithm becomes breakable by a capable quantum computer.

A real Level 3 plan is approved and resourced. That means named owners, committed funding or headcount, and agreement on sequencing. An attractive slide deck that no team is funded to execute is not Level 3. It may show intent, but it is still short of a programme.

The next move from Level 3 is to execute the first migration wave. The best first wave is usually not “everything.” It is a selected set of high-risk, tractable systems where the organisation can reduce meaningful exposure and learn how migration works in its environment.

Classify data by confidentiality lifetime.
Score systems by cryptographic exposure, business criticality, and operational constraint.
Group work into migration waves.
Assign owners, dates, budget, and success measures.
Start with systems where risk reduction and practical learning are both high.

A real plan classifies data, scores risk, and schedules migration waves.

Level 4: migrating in real systems

Level 4 is migrating. This is where plans become production change. The organisation is actively replacing vulnerable cryptography, upgrading protocols, changing certificate and key management processes, testing interoperability, and deploying post-quantum cryptography, or PQC, where appropriate.

Many Level 4 migrations will use hybrid modes. A hybrid mode combines a classical algorithm with a post-quantum algorithm so that security does not depend on only one new component. For example, a key establishment process may use both a traditional method and a post-quantum key encapsulation mechanism, then combine the results. Hybrid deployment can reduce transition risk while standards, products, and operational experience mature.

Level 4 must be prioritised. The highest-risk systems should move first: systems carrying long-lived sensitive data, externally exposed services, critical identity and trust infrastructure, and places where migration lead times are long. Public Key Infrastructure, or PKI, deserves special care because it underpins certificates, signatures, authentication, and trust chains across many systems.

The signal for Level 4 is production evidence. Lab tests, proofs of concept, and vendor briefings are useful, but they do not by themselves make an organisation migrating. Level 4 means production systems are running changed cryptography under controlled operations, with monitoring, rollback plans, and compatibility testing.

✅

Production proof. The Level 4 signal is not that a team has tested PQC, but that real systems are safely operating with changed cryptography.

Hybrid key exchange combines a classical and a post-quantum algorithm.

Level 5: crypto-agile and continuous

Level 5 is crypto-agile and continuous. Crypto-agility means systems can change cryptographic algorithms, parameters, certificates, and libraries without a major redesign each time. In practice, that may involve configuration-driven algorithm choices, clear abstraction layers, automated certificate and key lifecycle management, versioned policy, repeatable testing, and documented rollback paths.

Continuous means the organisation treats cryptographic change as an ongoing capability, not a one-off project. The CBOM updates itself through tooling and process. New deployments feed the inventory. Security and architecture teams monitor standards bodies, government guidance, vendor advisories, protocol updates, and emerging research. When guidance changes, the organisation can assess impact quickly because it knows where affected cryptography lives.

The signal for Level 5 is routine change. If an approved algorithm needs to be deprecated, teams can identify affected systems, test alternatives, update policy, deploy changes, and verify results through established processes. The event is still serious, but it is not chaotic.

Level 5 does not mean nothing can go wrong. It means the organisation has reduced dependence on heroic, one-time migrations. It has made cryptographic maintenance part of normal engineering and risk management.

Level 5 makes cryptographic change a routine, continuous capability.

How leaders and practitioners should use the score

For leaders, the score should drive decisions about accountability, funding, risk acceptance, and sequencing. A Level 1 organisation should not be asked for a detailed migration budget before discovery exists. A Level 2 organisation should not be satisfied with inventory alone when high-risk data may need protection for decades. A Level 3 organisation should be challenged on whether its plan is actually funded. A Level 4 organisation should be asked whether the migration is also improving future agility.

For practitioners, the score should prevent wasted motion. If you are at Level 1, do not start by arguing over final algorithm choices for every system. Build the inventory. If you are at Level 2, do not declare victory because the inventory exists. Risk-score it. If you are at Level 3, do not keep refining the roadmap forever. Start wave one. If you are at Level 4, do not make every replacement a bespoke engineering effort. Build patterns that can be reused.

The model is most useful when applied at the right level of granularity. A central security office may be Level 3 because it has a funded roadmap, while a business unit may be Level 1 because it has not yet discovered its application dependencies. A cloud-hosted customer platform may be Level 4, while an embedded operational technology environment may be Level 2. Separate scores are not a failure; they are better evidence.

The rule is simple: climb one rung at a time. Skipping levels usually creates false confidence. A plan without an inventory is guesswork. Migration without prioritisation can waste effort on low-risk systems while high-risk ones wait. Agility without production experience is aspiration. The next move is the one attached to your current rung.

⚠️

Do not skip. A Level 3 roadmap built without a Level 2 inventory is not a shortcut; it is planning on unknowns.

A practical scoring checklist

A maturity score should be easy to challenge. If a team claims a level, ask for the signal that proves it and the next move it intends to take. The discussion should be specific enough that two independent reviewers would usually reach the same conclusion.

Use the checklist below as a field test. It is deliberately plain. The aim is not to produce a perfect audit instrument, but to stop the common mistake of treating awareness, planning, and migration as if they were the same thing.

Level 0, unaware: there is no recognised quantum-safe owner or programme. Next move: brief leadership and assign ownership.
Level 1, aware: a champion exists, but the organisation has no reliable cryptographic inventory. Next move: start discovery.
Level 2, inventoried: a living Cryptographic Bill of Materials exists and stays current. Next move: classify data and risk-score systems.
Level 3, planned: a risk-based roadmap is approved, funded, and assigned to owners. Next move: execute the first migration wave.
Level 4, migrating: production systems are being changed, often using hybrid classical and post-quantum approaches. Next move: continue migration while building reusable agility.
Level 5, crypto-agile and continuous: algorithm change is routine, inventory updates continuously, and new guidance is monitored. Next move: sustain the capability.

Key takeaways

Post-quantum readiness is easier to manage when it is scored as a maturity level rather than described as a vague feeling.
Level 2 requires a living Cryptographic Bill of Materials, not a stale one-time spreadsheet.
Level 3 means the roadmap is risk-based, approved, and resourced; an unfunded slide deck is not enough.
Level 4 is proven by production migration, often starting with hybrid classical and post-quantum deployments on high-risk systems.
Level 5 makes cryptographic change a normal capability through crypto-agility, continuous inventory, and monitoring.
Large organisations should score different divisions, systems, or environments separately and climb one rung at a time.

Glossary

Maturity model: A numbered framework that describes how developed a capability is and what improvement should come next.
Post-quantum cryptography: Cryptographic algorithms designed to resist attacks from both classical computers and future cryptographically relevant quantum computers.
Cryptographic Bill of Materials: An inventory of the cryptographic algorithms, protocols, keys, certificates, libraries, systems, owners, and dependencies in an environment.
Crypto-agility: The ability to change cryptographic algorithms, parameters, libraries, and policies without redesigning systems from scratch.
Hybrid mode: A transition approach that combines classical cryptography with post-quantum cryptography so security does not rely on only one method.
Data shelf life: The length of time information must remain confidential or trustworthy after it is created or transmitted.
Harvest now, decrypt later: An attack strategy in which encrypted data is collected today in the hope that it can be decrypted in the future.
Public Key Infrastructure: The systems, policies, and processes used to issue, manage, validate, and revoke digital certificates and the trust relationships behind them.