Post-Quantum Readiness Maturity Model: Five Levels

Most organisations know post-quantum cryptography is coming but cannot say how ready they are, because readiness is spread across inventory, risk ranking, suppliers and engineering work that nobody scores together. This model uses NHI Mgmt Group's five levels, Ad hoc, Developing, Defined, Managed and Optimised, to describe how a post-quantum programme matures across six capability areas, from a first cryptographic inventory to verified migration with no silent fallback to classical algorithms. It is written for CISOs, architects and PKI and platform owners who need a defensible score, a realistic target and a sequence of next steps. The discipline itself, how to design systems so algorithms can be swapped, is covered in the Crypto-Agility Guide, and the migration mechanics in the Post-Quantum Cryptography Migration Guide. This page is the scoring tool.

Key takeaways

The standards are no longer the blocker. NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on 13 August 2024, so the gap is now inventory, planning and supplier delivery.
Inventory decides the level. A programme with a strategy deck but no list of where public-key cryptography is used is Level 1, however senior the sponsor.
Level 3 is the sensible first target and lines up with the UK NCSC's 2028 milestone: goals defined, discovery and assessment complete, an initial plan agreed and needs communicated to suppliers.
Suppliers carry much of the work. Most cryptography sits inside products, cloud services and devices you buy, so vendor readiness is a capability area in its own right, not a footnote.
Measure what is actually negotiated. The NCSC asks organisations to use testing and metrics to confirm systems really use post-quantum algorithms and do not fall back to traditional ones.

The five levels

Level	Name	What it looks like
1	Ad hoc	Quantum risk is discussed but unowned. Nobody can list where RSA, elliptic curve Diffie-Hellman or ECDSA are used. Certificates, keys and libraries are found only when something breaks. Purchasing does not ask suppliers about post-quantum plans.
2	Developing	A sponsor and a small working group exist. Partial discovery has been run, usually certificate scanning and TLS endpoint scans, which miss code, firmware and embedded devices. Some vendors have been asked informally. Pilots of hybrid key exchange may run in a lab.
3	Defined	A written quantum-readiness roadmap, as recommended by the joint CISA, NSA and NIST factsheet. A cryptographic inventory covers critical services with algorithm, key size, purpose, owner and data lifetime. Systems are ranked by data sensitivity and shelf life. Post-quantum requirements are in new contracts. A migration strategy is chosen per system.
4	Managed	Inventory is kept current by automated discovery feeding the CMDB. Highest-priority services, typically those protecting long-lived confidential data, run hybrid or post-quantum key establishment in production. Supplier roadmaps are tracked with dates. Progress is reported to the board as metrics.
5	Optimised	Cryptography is managed as policy: algorithms are changed by configuration, new systems cannot go live with quantum-vulnerable public-key algorithms without an approved exception, and telemetry proves which algorithms are negotiated. The remaining long-lived hardware roots of trust have funded replacement dates.

Capability areas

Score each area on its own. A strong inventory with no supplier engagement is a Level 3 inventory and a Level 1 supplier programme, and the overall score should report both, not an average.

Capability area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Governance and ownership	No owner, no budget; quantum treated as a research topic	Named executive owner, roadmap approved, migration goals set against sector and regulatory requirements	Post-quantum policy is part of architecture and change approval; exceptions are time-bound and reviewed
Cryptographic inventory	None, or a certificate list only	Inventory of critical services: algorithm, key length, protocol, library, purpose, owner, data held and its required lifetime	Continuous discovery across hardware, firmware, operating systems, protocols, libraries and applications, reconciled with the asset inventory
Risk prioritisation	Everything urgent or nothing urgent	Ranking by data value and shelf life, exposure to harvest now, decrypt later, and dependencies; long-lived hardware flagged	Priorities recalculated as inventory and threat estimates change, using a documented method such as Mosca's inequality
Vendor and supply chain readiness	Not asked	Post-quantum questions in due diligence and contract clauses for new purchases; supplier list for critical products with stated plans	Supplier delivery dates tracked and enforced; products without a credible roadmap have replacement plans
Migration engineering	No pilots	Migration strategy per system (replace in place, re-platform, retire, run to end of life or accept risk); hybrid key exchange tested in non-production	Priority services migrated; post-quantum algorithms deployed by configuration through central crypto services
Verification and metrics	None	Test cases confirm which algorithms are negotiated in pilots; baseline metrics agreed	Production telemetry on negotiated algorithms, fallback alerts and inventory coverage reported monthly

Dimension detail: what moves each area up

Inventory, Level 2 to 3: go beyond certificates. The NCCoE Migration to Post-Quantum Cryptography project frames discovery as finding every instance of public-key algorithm use, across hardware, firmware, operating systems, protocols, cryptographic libraries and applications, then recording the algorithm and purpose for each component. Code scanning, library dependency analysis and network observation are needed together; each sees things the others miss. See the Cryptographic Discovery and PQC Readiness Tools Buyer's Guide.
Prioritisation, Level 2 to 3: attach a data lifetime to each service. If data must stay confidential for longer than the expected time to migrate plus the time until a cryptographically relevant quantum computer, the service is already exposed to harvest now, decrypt later collection. Signatures are a different problem: forged signatures only matter once such a computer exists, but signing keys in hardware and firmware have long replacement cycles.
Vendors, Level 3 to 4: move from asking to tracking. Keep a register of critical products with the supplier's stated support for ML-KEM and ML-DSA, the version and date, and whether hybrid modes are offered.
Migration, Level 3 to 4: put hybrid key establishment into production for the services ranked highest. The NCSC expects confidentiality-protecting services to be ready first, with certificate-based PKI and IoT and ICS protocols following more slowly. See the Hybrid Post-Quantum TLS Key Exchange Guide.
Machine identities, all levels: service accounts, workload certificates, SSH keys, code-signing keys and API gateways hold most of the public-key material in an estate. Their owners are often unclear, which stalls migration. See the Post-Quantum Migration for NHIs Guide.

Mapping to frameworks and timelines

The model maps to these controls and published milestones, confirmed against the official sources listed below.

Source	Reference	Relevance to the model
NIST SP 800-53 Rev. 5	SC-12, SC-13	Cryptographic key establishment and management; cryptographic protection. The core controls a migration changes.
NIST SP 800-53 Rev. 5	SC-8, SC-28	Transmission confidentiality and protection of information at rest, the services most exposed to harvest now, decrypt later.
NIST SP 800-53 Rev. 5	CM-8	System component inventory, the base the cryptographic inventory extends.
NIST SP 800-53 Rev. 5	SA-4, SR-3, SR-6	Acquisition requirements, supply chain controls and supplier assessments, where vendor readiness is enforced.
NIST CSF 2.0	ID.AM-02, ID.AM-07, ID.AM-08	Inventories of software and services, data and metadata, and life cycle management of assets.
NIST CSF 2.0	PR.DS-01, PR.DS-02, GV.SC-05, GV.SC-07	Data at rest and in transit protected; supply chain requirements in contracts; supplier risk understood and managed.
UK NCSC PQC migration timelines (20 March 2025)	2028, 2031, 2035	2028: goals, discovery and initial plan (about Level 3). 2031: highest-priority migration done (about Level 4). 2035: all systems migrated (Level 5).
NIST IR 8547	Final, October 2026	NIST's plan for the transition from quantum-vulnerable algorithms. See the NIST IR 8547 PQC Transition Timeline Guide for its dates.

For a single view of national and sector deadlines, use the Post-Quantum Cryptography Deadlines Tracker.

Self-assessment questions

Answer for your most critical services first. A capability that exists for one business unit but not the rest scores Level 2. Two or more "no" answers in an area cap that area at the level below.

Governance and ownership

Is one executive accountable for post-quantum readiness, with a budget line rather than borrowed time?
Is there an approved roadmap with dated goals, and has it been reviewed against a published national timeline in the last year?
Does architecture review reject new designs that hard-code a single public-key algorithm?

Cryptographic inventory

Could you list, within a week, every place your payment, identity or customer data platforms use RSA or elliptic curve cryptography, including inside libraries and appliances?
Does the inventory record owner, purpose and the required confidentiality lifetime of the data, not only the algorithm?
Have managed service providers confirmed they are running the same discovery for the services they operate for you?

Risk prioritisation

Have you ranked services by data shelf life and exposure to harvest now, decrypt later collection?
Are long-lived hardware roots of trust, such as HSMs, TPM-based device identity, secure boot keys and OT controllers, identified with their replacement cycles?

Vendor and supply chain readiness

Do new contracts for products that use cryptography include post-quantum support requirements and dates?
For your top 20 critical products, do you know whether and when each supplier will support ML-KEM and ML-DSA?

Migration engineering

Is a migration strategy recorded per system: replace in place, re-platform, retire, run to end of life or accept the risk?
Has hybrid key exchange run in production for at least one high-priority service, with a tested rollback?
Are cryptographic calls routed through shared libraries or services so algorithms can be changed by configuration?

Verification and metrics

Can you show, from logs or scans, which key exchange and signature algorithms each priority service actually negotiates?
Would you be alerted if a migrated service silently fell back to a classical-only algorithm?

Scoring and evidence

Evidence an assessor should ask for	Supports
Approved roadmap, named owner, budget	Governance at Level 3
Inventory export with algorithm, owner, purpose and data lifetime fields populated for critical services	Inventory at Level 3
Discovery tool runs scheduled and reconciled with the CMDB	Inventory at Level 4
Prioritised migration list with rationale per service	Prioritisation at Level 3
Contract clauses and a supplier readiness register with dates	Vendors at Level 3 to 4
Change records for production hybrid deployments and rollback tests	Migration at Level 4
Dashboards of negotiated algorithms and fallback alerts	Verification at Level 4 to 5

Moving up: roadmap

Level 1 to 2, first quarter: appoint an owner, form a working group from PKI, network, application, procurement and OT teams, and run discovery on the obvious sources: certificate authorities, TLS endpoints, SSH, VPN and code repositories. Agree on a single inventory record format; CycloneDX's cryptography bill of materials is one option.
Level 2 to 3, within 12 to 18 months: extend discovery into libraries, firmware and appliances; attach owners and data lifetimes; rank services; write the roadmap; add post-quantum clauses to procurement templates; and send your needs to critical suppliers. This is the NCSC's 2028 milestone.
Level 3 to 4: automate discovery, migrate the highest-priority confidentiality services to hybrid key establishment, test rollback, and start reporting coverage and progress to the board. Begin PKI planning early, as certificate hierarchies, HSM firmware and relying parties move slowly. See the PKI and Certificate Lifecycle Maturity Model.
Level 4 to 5: make post-quantum algorithms the default in shared crypto services, block new quantum-vulnerable deployments through architecture and change control, migrate signatures as supplier support allows, and fund replacement of the remaining long-lived hardware.

Small vs large organisations: a small organisation will rarely run its own discovery tooling; its readiness is mostly vendor readiness, so it should focus on the supplier register, contract clauses and keeping products updated. A large or regulated organisation, or one holding data that must stay secret for decades, needs the full inventory and prioritisation work and should aim for Level 3 well before 2028.

Metrics that show progress

Inventory coverage: share of critical services with a complete cryptographic inventory entry (owner, algorithm, purpose, data lifetime).
Prioritised migration progress: share of top-priority services running hybrid or post-quantum key establishment in production.
Supplier readiness: share of critical products with a dated supplier commitment to post-quantum support.
Contract coverage: share of new cryptography-bearing purchases with post-quantum clauses.
Fallback rate: number of connections on migrated services that negotiated a classical-only algorithm, trending to zero.
Exceptions: open exceptions for quantum-vulnerable deployments, with age.

Common failure patterns

Certificates mistaken for the inventory: a certificate list misses libraries, firmware, SSH host keys and protocols embedded in appliances.
Waiting for a date: treating the absence of a quantum computer as a reason to wait ignores data already being collected and the long tail of hardware replacement.
Vendor silence accepted: suppliers that cannot state a roadmap are recorded as "unknown" and never escalated.
Migration without verification: a service is marked migrated because the new library is installed, while clients still negotiate classical key exchange.
No rollback: larger keys and handshakes break middleboxes or constrained clients, and a team with no rollback plan stops the programme after one outage.

Practitioner checklist

Name an accountable executive and approve a dated quantum-readiness roadmap.
Build a cryptographic inventory with algorithm, purpose, owner and data lifetime for every critical service.
Extend discovery beyond certificates to libraries, firmware, appliances, OT and provider-run services.
Rank services by data shelf life and harvest now, decrypt later exposure, and flag long-lived hardware.
Add post-quantum requirements to procurement templates and keep a dated supplier readiness register.
Record a migration strategy per system and test hybrid key exchange with a rollback plan.
Monitor negotiated algorithms and alert on fallback to classical-only key exchange.
Re-score this model annually and report the area scores, not an average, to the board.

Post-Quantum Readiness Maturity Model: Score Your Path From Inventory to Migration