Building and maintaining a cryptographic inventory for post-quantum migration

Goal

Status as of 25 October 2026. Build an evidence-backed inventory that supports migration decisions and remains useful after deployment changes. Re-check NIST's living migration FAQ and the CycloneDX schema selected for interchange. This procedure proposes an operating record rather than asserting that a scanner can discover every cryptographic dependency.

NIST describes an inventory spanning systems, applications, services, devices and data flows. CycloneDX provides a model for algorithms, keys, certificates and their relationships to software components. Those technical relationships are useful inputs; ownership and migration decisions still need recording.

Prerequisites

Choose a bounded service and an accountable owner. Obtain its architecture, software and hardware inventories, certificate records, configuration and authorized runtime observations. Include suppliers where a dependency is managed externally. Record unknowns explicitly instead of assuming a missing result means no cryptography exists.

Steps

1. Map the service's data flows and trust boundaries. Create separate records for externally terminated connections, internal connections, stored data and signature verification. Identify which data needs confidentiality over a long period and which signatures must remain verifiable.
2. Record the cryptographic purpose, exact algorithm or parameter set, key size where applicable, protocol and negotiated group. Distinguish an implemented capability, an enabled setting and observed use. Avoid a single post-quantum yes/no field for an entire service.
3. Attach implementation context: library and runtime versions, package or image identifier, provider, configuration location, certificate chain and public-key algorithm. Record hardware model and firmware dependencies where an HSM or appliance constrains upgrades. Store key identifiers and custody metadata, never private keys, shared secrets or recovery material.
4. Add evidence and responsibility. For each entry, retain the collection method, observation time, environment, responsible team and source reference. Mark whether the evidence came from source inspection, configuration, supplier documentation or an observed connection. Treat disagreements as work items, not values to merge silently.
5. Export technical assets and relationships as a CycloneDX CBOM using a schema supported by the receiving tools. Validate the export against that schema. Link it to the software inventory and maintain a companion register for business ownership, retention needs, supplier constraints, exceptions and the proposed migration action.
6. Refresh the record when software, firmware, certificates, policy or termination paths change. Review the differences during deployment approval. Give each unresolved dependency an owner and a next review point; retain the evidence that explains a previous migration decision.

Expected result

The owner can trace protected data to a protocol, implementation and responsible party, distinguish confirmed observations from assumptions, and identify the next practical migration task. A new release produces reviewable inventory changes.

Limits and test basis

No discovery tool or estate was tested for this article. A successful schema check establishes document structure, not completeness or cryptographic correctness. Network evidence cannot establish all offline signing or storage behavior. Restrict access to the inventory because its metadata describes sensitive infrastructure, even when it contains no secret material.