Turn a cryptographic inventory into a decision queue.

A cryptographic inventory is often the first serious deliverable in a quantum-readiness programme. It is also where many programmes stall. A spreadsheet can contain hundreds of rows and still leave leadership unable to answer the questions that matter: what should move first, who decides, what evidence is missing and what happens if the migration is delayed?

The answer is to treat the inventory as a decision queue, not a catalogue. NIST and CISA both place discovery and inventory near the beginning of post-quantum migration because teams cannot prioritise systems they cannot see. The inventory becomes useful when it connects a cryptographic dependency to the data it protects, the service that uses it, the owner who can change it and the evidence that supports the current assessment.

Capture the context around the algorithm.

“RSA”, “ECC” or “TLS” is not enough context for a migration decision. Record the boundary where the mechanism is used and the consequence of changing it. Keep private key material out of the inventory; the goal is visibility, ownership and safe planning, not collection of secrets.

Prioritise by consequence and change effort.

A public endpoint is not automatically the highest priority, and an internal system is not automatically low risk. Start with the information and decisions that are difficult to reverse. Long-lived sensitive data deserves attention because an adversary may capture encrypted traffic today and attempt to decrypt it later. Signing systems deserve a different question: how would a compromised or obsolete signature affect software release, identity, safety or trust in the business process?

Use a small set of explicit factors rather than a mysterious score. For each row, mark data lifetime, business impact, exposure, cryptographic dependency, supplier dependency and migration friction. Then record why the row is urgent, why it can wait or what evidence would change the decision. A simple explanation is more valuable than a precise-looking number no one can defend.

Make uncertainty visible.

Inventory work contains different kinds of uncertainty. “Not observed” means the team has not checked the relevant boundary. “Not supported” means a tested product or protocol cannot do what the roadmap requires. “Planned” means a supplier has described a future capability, not that your environment has exercised it. Keep these states separate so a green-looking dashboard does not turn an assumption into a control.

Each open question should become a small evidence task: inspect a certificate chain, confirm a library version, ask a supplier for a reproducible test, or run a safe handshake comparison. Link the result to the inventory row and record the date. That creates a trail another engineer, auditor or executive can understand without repeating the entire discovery exercise.

The objective is not a perfect inventory on day one. It is a trustworthy queue that gets better as each boundary is checked. Start with one public endpoint, critical application or supplier path, then use the result to improve the next row. The Q-Ready Check can provide the public-signal starting point; the decision queue shows what needs deeper evidence afterwards.