Begin with the service, not the algorithm
An algorithm name does not tell a technology leader how to migrate a service. The useful questions are where cryptography is used, what it protects, who can change it and what depends on it. An inventory should answer those questions before a programme commits to a sequence of upgrades.
NIST describes cryptographic inventory as a record spanning systems, applications, services, devices and data flows. That breadth matters. A certificate list can be valuable evidence, but it should not be mistaken for a complete account of cryptographic dependencies. Begin with a clearly bounded service and document what remains outside the view.
Record enough to support a decision
For each finding, our recommendation is to capture the affected component, its cryptographic function and its relationship to a business service. Include the evidence source, observation date, accountable owner and known upgrade constraints. Where a detail is unverified, mark it as unknown rather than allowing an assumption to become a planning fact.
Keep key metadata separate from secret key material. The inventory needs to explain a key's purpose and dependencies, not create another repository of secrets. A useful record should let an application owner understand the finding and let a delivery team identify the next investigation without repeating the entire discovery exercise.
Bring the layers into one view
QUAMO discovers cryptography across perimeter, cloud, network and code, bringing findings into a Cryptographic Bill of Materials, or C-BOM. The value is the connected view: evidence from different parts of the estate can inform a single migration discussion rather than remain scattered across separate technical reports.
Treat that view as a working baseline, not a claim that every dependency has been resolved. Reconcile findings with service owners and supplier information. A discrepancy between observed behaviour and a documented design is a reason to investigate. It is not a reason to quietly choose whichever account makes the plan easier.
Prioritise the consequence of exposure
NCSC guidance explains the potential for an attacker to retain encrypted information and decrypt it with a future cryptographically relevant quantum computer. This harvest-now, decrypt-later risk is particularly relevant to very high-value information requiring long-term protection. It does not make every encrypted connection equally urgent.
Ask data owners how long confidentiality must last, then connect that requirement to the observed cryptographic path. Consider service criticality, the ability to make changes and dependencies on other systems. QUAMO uses discovery evidence and harvest-now, decrypt-later context to support prioritised migration waves, rather than treating the number of findings as the strategy.
Make the inventory part of delivery
A first baseline should produce a manageable next decision: validate an uncertain dependency, engage a supplier or prepare a controlled pilot. Record the target state and what evidence will demonstrate that the change worked. Refresh the inventory as the estate changes so that a completed migration remains connected to current operations.
Discovery is necessary, but it is not deployment. The QUAMO product model explicitly recognises that no product fully automates post-quantum cryptography migration. QUAMO creates the evidence-led roadmap; Cystel supports controlled implementation. A credible inventory gives that implementation a starting point, an accountable owner and a way to verify progress.