Post-quantum cryptography readiness assessment
Decide which systems need post-quantum work first, and which do not need it yet
A regulator, a customer or a board question asks what the organisation's post-quantum position is. The decision is which systems need post-quantum work first, and which do not need it yet. The work starts from which mechanisms are quantum-vulnerable, how long their data must stay confidential, and which dependencies are outside your control and ends with a post-quantum readiness diagnostic with a vulnerable-mechanism inventory and a prioritised position. It is most relevant to security leaders and architects responding to post-quantum guidance. A useful result states what was examined, what remains uncertain and which decision the evidence can support.
Decide which systems need post-quantum work first, and which do not need it yet
- Vulnerable mechanism
The starting condition this work depends on.
- Confidentiality lifetime
Where the consequence actually arises.
- Dependency control
The finding and its open dependencies.
Decision
Frame the decision before scoping the work
Questions and the evidence each one needs
- Vulnerable mechanism
- Inspect the cryptographic inventory across products and infrastructure.
- Confidentiality lifetime
- Inspect data retention and confidentiality-lifetime requirements.
- Dependency control
- Inspect vendor and hardware roadmaps.
The decision is which systems need post-quantum work first, and which do not need it yet. This matters to security leaders and architects responding to post-quantum guidance when a regulator, a customer or a board question asks what the organisation’s post-quantum position is. Name the affected system, the consequence of a wrong decision and the owner who can act. The opening conversation should establish which evidence already exists and which uncertainty is material enough to investigate.
The specific failure hypothesis is that long-lived confidential data is protected today by key exchange that a future adversary could retroactively break. It stays a hypothesis until it is examined in your own case. Existing design records, inventories or operating evidence may already resolve it, so identify the uncovered question before commissioning further work.
Mechanism
Follow the relationship that carries the consequence
Where the boundary is actually crossed
- Vulnerable mechanism
- The condition the design assumes.
- Confidentiality lifetime
- Where authority or information changes hands.
- Dependency control
- The effect the owner must answer for.
What this specialty examines
Post-quantum cryptography readiness assessment rests on which mechanisms are quantum-vulnerable, how long their data must stay confidential, and which dependencies are outside your control. Work from the mechanism as deployed and its actual key custody rather than from the standard it cites, and record where the two differ.
The examination draws on the cryptographic inventory across products and infrastructure; data retention and confidentiality-lifetime requirements; and vendor and hardware roadmaps. Identify the owner, revision and operating context of each source. Keep an incomplete input visible, with an explanation of what its absence prevents the owner from concluding, rather than quietly treating a gap as a satisfactory result.
The tradeoff to make explicit
The tradeoff here is acting early on systems you control against waiting for vendor and standards maturity elsewhere. Compare the available options against the same intended outcome. If one option removes a control or moves a boundary, describe that difference before treating its lower effort as an improvement. The decision should expose the tradeoff rather than bury it in a single rating.
Preparation
Connect the inputs to the boundary examined
Preparation record for the engagement
Illustrative working format
- The cryptographic inventory across products and infrastructure
- Bounds the context.
- Data retention and confidentiality-lifetime requirements
- Supplies the material examined.
- Vendor and hardware roadmaps
- Exposes conditions that qualify a result.
Start with the cryptographic inventory across products and infrastructure; data retention and confidentiality-lifetime requirements; and vendor and hardware roadmaps. Each has a different job: the first establishes context, the second supplies the material to examine, and the third exposes operating conditions that may qualify a conclusion. Sanitised examples can support early work, provided the differences from the real configuration stay explicit.
The scope also needs security leaders and architects responding to post-quantum guidance with the authority to inspect the relevant boundary, and agreement on what evidence would distinguish the failure in which long-lived confidential data is protected today by key exchange that a future adversary could retroactively break from acceptable behaviour. Where stakeholders disagree about intended behaviour, resolve that interpretation before classifying an observed difference as a defect.
Working sequence
Carry the question through to an accountable finding
From scoped material to a decision record
- Inventory the vulnerable mechanisms
Set the conditions assumed.
- Apply the confidentiality lifetime
Apply the scoped check.
- Prioritise and constrain
Record evidence and the next decision.
Inventory the vulnerable mechanisms
Separate public-key exchange, digital signatures and symmetric cryptography, and record where each is used and by what. Record what is deliberately excluded.
Apply the confidentiality lifetime
For each data class, compare how long it must stay confidential with the period in which harvested traffic could be retroactively decrypted. Keep an unreproducible observation in the record with its reason.
Prioritise and constrain
Rank systems by data lifetime, exposure and dependency control, and state which items are blocked by a vendor, a standard or hardware. Hand the result over with its open dependencies attached.
Indicative artefact
Make the artefact usable by the person who owns the decision
A post-quantum readiness diagnostic with a vulnerable-mechanism inventory and a prioritised position
Illustrative working format
- Quantum-vulnerable mechanism inventory
- What was examined, and under which assumptions.
- Confidentiality-lifetime analysis per data class
- Each observation, linked to evidence.
- Prioritised systems and externally blocked dependencies
- The next decision, and its limits.
The proposed decision artefact is a post-quantum readiness diagnostic with a vulnerable-mechanism inventory and a prioritised position. Depending on the agreed scope, the pack may include:
-
Quantum-vulnerable mechanism inventory. Basis: the definitions, boundaries and assumptions another reviewer would need.
-
Confidentiality-lifetime analysis per data class. Observation: the findings and their interpretation, preserving adverse results and disagreement.
-
Prioritised systems and externally blocked dependencies. Decision: what the owner could do next, and what change would justify revisiting it.
Retain the selection rationale beside the result. Without it, a bounded finding is easily mistaken for complete coverage.
Illustrative scenario
Examine the question through a constructed case
A constructed case and its decision paths
Illustrative scenario
- Vulnerable mechanism
A platform transmits records that must remain confidential for fifteen years over a classical key exchange.
- Confidentiality lifetime
Does the confidentiality requirement extend past the period in which captured traffic could be decrypted later?
- Dependency control
Prioritise hybrid key exchange on that path ahead of systems whose data loses value quickly.
Consider an illustrative situation: a platform transmits records that must remain confidential for fifteen years over a classical key exchange. The example is constructed to show how the question is framed. No client engagement, executed test or measured improvement is implied.
The question to examine is does the confidentiality requirement extend past the period in which captured traffic could be decrypted later. A reasonable next action would be to prioritise hybrid key exchange on that path ahead of systems whose data loses value quickly. The decision record should state which configuration was accepted and which limitations came with it.
Scope and next action
Keep the conclusion inside the agreed boundary
Confirm fit before the next commitment
- Vulnerable mechanism
- Limited to the agreed scope and configuration.
- The cryptographic inventory across products and infrastructure
- The owner confirms access and conditions.
- Dependency control
- Readiness work follows published guidance and current standards. No forecast of cryptographically relevant quantum computing is asserted here.
Readiness work follows published guidance and current standards. No forecast of cryptographically relevant quantum computing is asserted here. Any engagement depends on an agreed scope, a qualified team and authorised access.
Bring the affected system, the inventory you already have and the obligation that prompted the question. The scope question follows from the situation in which a regulator, a customer or a board question asks what the organisation’s post-quantum position is. Confirm which missing observation would change the owner’s next action.