Quantum risk assessment template, with a transparent scoring method

A quantum risk assessment template is a single table with one row per cryptographic asset and six columns that decide its priority: asset, algorithm in use, data shelf life, exposure, migration time and supplier dependency. The scoring method below is deliberately transparent: every number comes from your own estimates and from published migration deadlines, never from a predicted arrival date for a quantum computer. Copy the structure, keep the evidence beside it, and you have an inventory you can defend in an audit.

The six columns, and the question each one answers

Keep the template narrow. Six columns are enough to rank work, and a narrow table actually gets filled in. Owner, ticket reference and review date are administration: useful, but they do not change a priority.

Why key exchange needs its own flag

Recorded traffic is protected only by the key exchange. That is the whole logic of harvest now, decrypt later (HNDL): an adversary stores ciphertext today and decrypts it when the mathematics allows. Signatures behave differently, because forging a signature later does not retroactively expose a past session. So the template carries a vulnerability flag that separates the two cases rather than treating all quantum-vulnerable algorithms as one risk.

Scoring: three bands per column

Each column scores 1, 2 or 3, with the band definitions written into the template so two assessors reach the same number from the same facts. The shelf life bands below are a starting point: adjust them to your retention schedule and contracts, and record the adjustment in the template so the score stays auditable.

Two sums follow, and they must stay separate. Urgency, U = Q + S + E, from 3 to 9, measures what a delay costs. Lead time, L = M + D, from 2 to 6, measures how long the change takes once started. Averaging them into one figure destroys exactly the information you need, because a cheap urgent row and an expensive slow row require different decisions.

Mosca's inequality as reasoning, not prophecy

Michele Mosca stated the migration problem with three quantities: X, the time your data must stay confidential; Y, the time you need to migrate; Z, the time until the algorithm can be broken. If X plus Y is greater than Z, data leaving your systems today is already outside its protection window.

Z is not knowable, and this site publishes no estimate of it. The useful substitution is to replace Z with a planning horizon you are accountable for: the earliest dated milestone in your own regulatory scope. The inequality then stops being a forecast and becomes a compliance calculation, with no invented probabilities anywhere in it.

The arithmetic is short. A row with a shelf life of 10 years and a migration time of 2 years needs 12 years of protection. A horizon at the end of 2030 is roughly 4 years away. Twelve is greater than four, so the flag is set: start now. That statement says nothing about when a quantum computer will exist, only that the protection window extends past the date your own scope gives you. Record the horizon you used in a column next to the flag, so a reviewer can argue with the horizon without redoing the assessment.

Turning scores into an order of work

1. Rows with the Mosca flag set and Q equal to 3 come first, highest U first. These are the HNDL rows, where a delay cannot be recovered later.
2. Within equal urgency, put the longest lead time first. An HSM replacement must begin before a one-line configuration change, even though the configuration change finishes sooner.
3. Rows with Q equal to 1 leave the queue and join a monitoring list, reviewed on the same cycle as everything else, because a hybrid deployment today can regress tomorrow.

U = Q + S + E          # urgency, 3 to 9
L = M + D              # lead time, 2 to 6
sort by (mosca_flag, Q, U, L), all descending

There are no weights and no multiplication on purpose. A weighted composite score hides which estimate a reviewer disagrees with. Four visible components let an auditor challenge one cell, not the ranking.

Filling the columns with evidence, not opinion

Three sources cover most rows. For anything with a public endpoint, read the negotiated group directly. OpenSSL 3.5 or later is required for the ML-KEM groups, and the hybrid group names are registered by IANA: X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) and SecP384r1MLKEM1024 (0x11ED).

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i 'Negotiated TLS1.3 group'

ssh -Q kex | grep mlkem

For administrative access, OpenSSH made mlkem768x25519-sha256 the default key agreement in 10.0 (2025-04-09), and 10.1 (2025-10-06) warns when a connection negotiates a non post-quantum key agreement, per the OpenSSH release notes. For code, libraries and build artefacts, a CBOM (cryptographic bill of materials) populates the algorithm column at scale, which matters because a typed inventory ages the day it is finished. Test any group change in staging, and keep a classical fallback such as X25519 listed after X25519MLKEM768.

Mapping the template to obligations

This section is information, not legal advice. Where a line above is our reading rather than the text itself, it is labelled as an interpretation, and your copy of the template should keep that distinction visible for auditors.

Measure first, then score

Scores built on assumed configuration are worth nothing. Start with the externally visible facts: run a free scan of your domain with PQC Status to see the negotiated TLS groups, versions and certificate chain, paste the result into the Algorithm and Exposure columns of the first rows, then work inward with ssh -Q kex and a CBOM. A scan describes the externally visible TLS configuration only: it is not a certification and not a compliance attestation, but it is the one column nobody can dispute.