Scoping a Quantum Readiness Assessment Around Four Decisions

Producing a list is not producing a priority

In December 2022 the United States enacted the Quantum Computing Cybersecurity Preparedness Act, and the Office of Management and Budget instructed federal agencies to submit a prioritized inventory of the cryptographic systems they run. Inventory is discovery work, and scanners, configuration exports and certificate stores will carry you a long way through it. Prioritized is a different deliverable. It needs three judgments no scanner produces: how long each protected asset has to stay secret, how long each system would take to change, and who is going to pay for that change.

A quantum readiness assessment is the exercise that produces those judgments and writes them down in a form a budget committee can act on. Most published guidance describes it from the bottom up, beginning with the cryptographic inventory and ending with a roadmap. The order below is reversed. Four decisions first, then the evidence each one requires, because an assessment scoped from its decisions has a stopping condition and an assessment scoped from discovery does not.

The arithmetic that sets your deadline

Michele Mosca, a co-founder of the Institute for Quantum Computing at the University of Waterloo, gave this transition its planning formula years before there was much to plan. Call X the number of years your data has to remain confidential, Y the number of years your migration will take, and Z the number of years until a cryptographically relevant quantum computer exists, meaning one large enough and stable enough to run Shor’s algorithm against the key sizes you use in production. If X plus Y is greater than Z, you are already behind.

Put numbers in it. A mortgage origination file carries personal and financial data that a bank is obliged to retain for 25 years, so X is 25. Suppose the bank’s own planning says a full migration across its application estate would take five years once funded, so Y is 5. That gives 30 years of exposure to cover, and no published estimate of Z is anywhere near 30.

Executive conversations about this formula tend to stall on Z, which is the least productive place to spend the time. Z is a forecast, the published estimates disagree with each other, and the annual Quantum Threat Timeline report from the Global Risk Institute exists precisely so that nobody has to invent one. Y is the term you influence, and Y is the term your organisation currently cannot state. Producing a defensible Y is the single most useful thing an assessment delivers, and everything below is in service of it.

Four decisions the assessment has to produce

An assessment is finished when the organisation can make four decisions it could not make before. What gets migrated first. What is capable of changing inside one budget cycle. What depends on somebody else. Who owns the programme and who signs the funding. Each decision has its own evidence requirement, and scoping the work decision by decision is what stops the inventory from expanding until the budget runs out.

What goes first, and why data lifetime alone gets it wrong

The threat that gets the most attention is harvest now, decrypt later: an adversary records encrypted traffic or copies encrypted archives today and keeps them until decryption becomes possible. That risk is retroactive, and it is the reason confidentiality with a long tail ranks high. Rank purely on data lifetime, though, and you will push your signing infrastructure to the back of the queue, which is usually the wrong call.

Authentication risk works the other way round. Forging a firmware signature in 2035 gives an attacker nothing in 2026, so there is no harvesting to worry about. The problem is lead time. Consider a manufacturer whose devices verify firmware using ECDSA over the P-256 curve, with the verification key burned into a one-time-programmable region of the microcontroller. That key is the device’s root of trust, and it cannot be replaced in the field. Devices already shipped have service lives measured in 15 years. Changing the scheme means a new silicon revision, a new bootloader, a new signing pipeline, and a validation cycle for each, and the lead time on that chain runs to years before a single new unit reaches a customer.

The post-quantum signature schemes make the engineering harder rather than easier. NIST published ML-DSA in FIPS 204 and SLH-DSA in FIPS 205 in August 2024, alongside the ML-KEM key encapsulation mechanism in FIPS 203. An ECDSA P-256 signature is 64 bytes. An ML-DSA-44 signature is 2,420 bytes, and SLH-DSA signatures run to several kilobytes. On a constrained bootloader with a fixed flash partition for the signature block, that is not a configuration change, it’s a redesign.

So the sequencing evidence has two columns, not one. Column one is how long the protected asset must stay secret. Column two is how long the system would take to change if you started today. Systems with a long lead time go early even when their confidentiality exposure is modest, because the calendar, not the risk score, is the binding constraint.

What can change inside one budget cycle

Crypto-agility is the property that decides column two. Stated plainly, it’s whether you can change an algorithm without changing the thing that uses it. Assessing it well means picking representative systems and tracing exactly what a change would require, rather than asking teams to rate themselves.

Two transport estates make the point. In the first, several hundred internal services sit behind a managed load balancer fleet that terminates TLS on their behalf. Algorithm selection is a fleet configuration item, the terminating software already offers the hybrid key exchange group used across the public web, and the change is a config push with a rollback path. In the second estate, the same protocol is terminated on network appliances whose cryptography executes inside a validated hardware security module. The algorithm change there is a vendor firmware release, followed by a re-validation of the module on the vendor’s schedule, followed by a maintenance window on hardware that is often the last thing anyone wants to touch. Same protocol, same target algorithm, two projects with nothing in common.

We teach teams to record agility in change-control units, because those translate directly into time and money. Six classes cover most estates: configuration change, code change, dependency upgrade, vendor release, hardware refresh, silicon respin. Each class carries a rough duration and a rough cost inside your own organisation, and once every system in the inventory carries a class, the sum of those durations is your first honest estimate of Y.

What you cannot fix yourself

Some of the cryptography you depend on is written by other people, shipped in their products, and changed on their timetable. Assessing that dependency is mostly a matter of asking suppliers a question precise enough that a vague answer becomes visible as one.

Vendor language in this market is currently worth very little. “Quantum-safe” on a datasheet is not a commitment, and “post-quantum ready” frequently means the product will be ready when the vendor is. Four things turn a marketing claim into evidence: the algorithm by its standard name, the standard or RFC number, the interoperability profile it will be offered in, and the release version with a date attached. A vendor who can supply all four is planning. A vendor who supplies none is not.

Most vendor claims blur the line between a library that contains an algorithm and a deployment that exposes it to clients. A product that links a cryptographic library containing ML-KEM has not necessarily enabled anything your clients can negotiate. What the browsers and content networks actually deployed for web traffic is a hybrid key exchange, running a classical elliptic-curve exchange and a post-quantum one together so that the connection stays secure if either component holds. Chrome and Cloudflare shipped the X25519Kyber768 group on that basis, and Signal shipped its PQXDH protocol in 2023. Apple announced PQ3 for iMessage in February 2024 and began rolling it out with iOS 17.4 in March 2024. Those are the concrete answers to point at when a supplier tells you the standards are still settling.

Contracts are the other half of this decision. New agreements and renewals can carry an obligation to support standardised post-quantum algorithms within a defined period, and the assessment is the natural moment to hand procurement a clause and a list of the contracts it belongs in.

Who owns it and who signs

The last decision is the shortest to describe and the most frequently skipped. Somebody has to own the programme, somebody has to fund the first tranche, and both facts have to exist somewhere other than a slide deck.

The evidence is unglamorous. Is quantum-vulnerable cryptography a named entry in the enterprise risk register, with an owner, a review date and a treatment plan, or is it a paragraph in a strategy document? Has anyone briefed the board, and did that briefing include a number? Does the security policy set a date after which new systems may not be built on quantum-vulnerable public-key cryptography? An assessment that ends without a named owner has produced a report, and reports don’t get funded.

What one algorithm migration already cost

There is a useful precedent, and it was a much smaller job than this one. In 2014 Google announced that Chrome would begin distrusting certificates signed with SHA-1, and the CA/Browser Forum set January 1, 2016 as the end of SHA-1 issuance for publicly trusted TLS certificates. The major browsers moved to distrusting SHA-1 in 2017. One hash function. One algorithm family. A hard external deadline set by a body with the power to enforce it, and a browser vendor showing warnings to users on the way.

That migration still surprised people for three years. Organisations found SHA-1 in internal public key infrastructure that no browser was ever going to police, in code-signing chains, in payment terminals, in appliances whose vendors had left the market, and in certificates issued by a team that had been reorganised out of existence. The discovery problem was the entire problem, and the deadline was the only reason it got solved.

The post-quantum transition changes key establishment and digital signatures at once, replaces algorithms whose key and signature sizes are an order of magnitude larger, and alters protocol behaviour in ways that surface as failures rather than warnings: a TLS handshake that no longer fits in one packet has been enough to break middleboxes on the public internet. And there is no browser vendor enforcing the date for your internal estate. Whatever deadline you get, you set yourself, which is what the assessment is for.

Choosing how much assessment to buy

Depth is a purchase, and the right amount is the amount that produces all four decisions. Five options are available, and most organisations end up using three of them in sequence.

A self-assessment questionnaire takes hours and produces a rough score. Its real value is diagnostic in a narrow sense: it tells you which of the four decisions you currently cannot make, which is exactly what you need in order to scope the next step.

Automated discovery takes weeks and produces the raw inventory. Scanners find algorithms in network traffic, certificate stores, configuration files and code repositories, and the Cybersecurity and Infrastructure Security Agency (CISA) has recommended automated inventory tooling for federal agencies on that basis. They are blind to cryptography implemented inside application logic, blind to what is happening inside a vendor’s binary, and blind to everything in the governance decision. A scan is an input, not an assessment.

An internal framework-based review takes months and costs the least per unit of depth, provided the team already understands the material. If it doesn’t, the training bill arrives before the assessment does, and pretending otherwise produces a confident document built on misunderstandings.

An external assessment buys method, comparison against other estates and an opinion that boards and regulators tend to weigh more heavily. It costs money and it costs disclosure, since the assessor needs to see the environment properly to be useful.

Third-party certification against a quantum readiness standard is not yet broadly available. Schemes are in development, and none of them should change what you do this year.

The sensible combination for a large estate is a questionnaire to scope, automated discovery to build the inventory, and expert review to turn the inventory into a priority. The order is deliberate, because the expensive resource should be spent on judgment rather than on data collection.

What the finished deliverable contains

An assessment is done when six artefacts exist and join up. The joining is the part that gets skipped, and it’s the part that makes the rest usable.

• A cryptographic bill of materials. A CBOM is a machine-readable list of cryptographic assets, algorithms, keys, certificates and protocols, each tied to the system that uses it. The CycloneDX 1.6 specification added support for cryptographic assets in 2024, which means the list can live in the same tooling as your software bill of materials rather than in a spreadsheet. Every entry needs a key that points at a system in your configuration management database, or the inventory cannot be joined to anything else.
• Data lifetime per system, taken from retention schedules, regulatory obligations and customer contracts rather than from an engineer’s estimate.
• A change-control class per system, using the six classes above.
• A supplier position per external dependency, recording the algorithm, the standard, the profile, the release and the date, plus the name of the person who answered.
• A sequenced plan in which the first tranche is costed and the later tranches are not, because costing year four in year one is a way of delaying year one.
• A risk register entry with a named owner, a funding line and a review date.

There is a straightforward test for whether the deliverable is finished. Hand it to a competent colleague who took no part in the interviews, and ask them to name the first five systems to be migrated and the cost of the first tranche. If they can, you have an assessment. If they have to ask who to call, you have a document.

Three ways assessments fail

The first failure is an inventory with no join keys. Thousands of rows of algorithm findings, no reliable link to system owners, no link to data classification, and no way to sort by anything except algorithm name. Everything downstream then has to be reconstructed by hand, and usually isn’t.

The second is treating the scan as the assessment. The tool ran, the report is long, the finding count is impressive, and not one of the four decisions has moved. This one is common because the scan is the only part of the exercise with a visible completion event.

The third is a report with no owner and no date. The findings are correct, the recommendations are sound, the executive summary is well written, and eighteen months later the same consultancy is asked to run the same assessment because nothing changed. We see this pattern most often where the assessment was commissioned to satisfy an audit question rather than to produce a plan, and the fix is upstream of the assessment itself.

When to run it again

Readiness is a moving target, so treat re-assessment as trigger-based with an annual floor rather than as a calendar ritual.

Four triggers are worth writing into the register entry. A significant acquisition or divestment, which changes the estate faster than any other event. A change in the standards, and there are two pending: FN-DSA has been designated FIPS 206 and is not yet published, and HQC was selected in March 2025 as an additional key encapsulation mechanism and is not yet standardised. Movement in a supplier roadmap, particularly a slip on a system you classified as a vendor-release dependency. And a regulatory date entering force in a jurisdiction you operate in, whether that is the European coordinated roadmap or NIST’s draft transition guidance on moving away from RSA-2048 and 256-bit elliptic curve cryptography.

Between triggers, the annual job is small: refresh the register entry, re-check the supplier positions that carried dates, and re-run discovery against systems deployed since the last pass. Keep the same metrics each time, because a readiness score is only informative against its own history.

Building the capability in-house

Every part of this exercise is a skill rather than a tool. Reading a CBOM and knowing which findings determine the migration sequence, classifying a system’s agility without over-trusting the team that owns it, separating a supplier’s library support from its deployment support, and constructing a sequence that a finance function will actually fund: those are learned, and consultants who do them for you take them with them when the engagement ends.

Quantum Academy’s post-quantum cryptography migration program teaches this work as a method, with the inventory, the sequencing arithmetic and the governance artefacts built as exercises rather than described in slides. Participants who complete the assessment and hold the credential can run the exercise in their own organisation and re-run it as the standards move. It is a private professional credential, not an accredited qualification or a licence, and what it certifies is that the holder has demonstrated the method against a defined standard.

For the underlying migration methodology, the framework documentation at pqcframework.org is freely available and worth reading before you scope anything. For deeper technical background on the algorithms themselves and on how the standards are developing, PostQuantum.com covers the material at the level an architect needs. And the programs themselves, with current dates and enrollment details, are at quantumacademy.com/.