Ask a security team how it plans to begin post-quantum migration and the first answer is usually sensible: build a cryptographic inventory.
Then comes the difficult question.
Which inventory?
Network scanners see certificates and protocol handshakes. Source scanners see API calls and embedded libraries. Cloud tools see managed keys and services. PKI platforms see certificates, CAs, and lifecycle events. HSM and KMS platforms see keys and operations. Software bills of materials describe packaged components. None of these observation points sees the whole enterprise.
That is not a temporary product gap. It is a property of the problem.
The practical objective should therefore not be a single perfect scanner. It should be a governed inventory assembled from multiple evidence sources and connected to the dependency, ownership, and business context required to make a migration decision.
Discovery is distributed
Cryptography appears at different layers:
- in source code and application configuration;
- inside open-source and commercial libraries;
- in TLS, SSH, IPsec, S/MIME, code signing, and other protocols;
- in certificates, keys, keystores, HSMs, and KMS platforms;
- in appliances, firmware, containers, cloud services, and SaaS products;
- at partner connections and other organizational boundaries.
Each discovery method has a useful but incomplete field of view. A network scan may identify a certificate and public-key algorithm but not the internal library that produced the handshake. A source scan may find a cryptographic API but not prove that the code path runs in production. An HSM can report a key operation without knowing which business transaction ultimately required it.
The inventory program must reconcile observations rather than declare one of them authoritative for every layer.
The normalization layer is important. The same certificate, library, algorithm, key, endpoint, or application may appear in several tools under different names. Stable identifiers, provenance, confidence, and observation time are therefore part of the data model, not administrative extras.
CBOM is a useful exchange model, not an all-seeing inventory
The Cryptography Bill of Materials, or CBOM, gives organizations a machine-readable way to describe cryptographic assets and their relationships. CycloneDX supports cryptographic assets, algorithms, certificates, keys, protocols, and dependency relationships. Its bom-ref, dependsOn, and related structures make it possible to connect objects rather than publish a flat list.
That is valuable progress.
It does not mean every discovery tool will produce a complete CBOM, that every vendor will describe cryptography at the same level, or that an imported CBOM will know the current business owner of an application. Completeness, freshness, evidence quality, and organizational context remain operational responsibilities.
CBOM should be treated as a common representation that different tools can contribute to and exchange. It should not be treated as proof that discovery is complete.
A mature inventory program needs to record:
- which tool or process observed an item;
- when it was observed;
- whether the observation is direct or inferred;
- which environment it applies to;
- how confidently it maps to an application or service;
- whether another source confirms or contradicts it;
- what part of the estate remains unobserved.
The quality of the inventory is defined as much by its known gaps as by its row count.
The missing links are dependencies
The hardest migration questions are relational.
Intra-system dependencies exist within a product or service. An application depends on a library; the library depends on a provider; the provider relies on an operating-system capability or HSM; the application also assumes a particular key format, certificate profile, or handshake behavior.
Inter-system dependencies cross application and organizational boundaries. An API gateway trusts a client certificate issued by another team. A signed artifact must be verified by customer software. A payment connection must negotiate algorithms supported by a partner. A device may require a firmware update before it can accept a new signature scheme.
A cryptographic object cannot be prioritized correctly without both views.
The lines determine the migration unit. If a verifier cannot accept a new signature, changing the signer alone does not complete the migration. If one shared library serves twenty applications, the change may be technically centralized but operationally distributed across twenty owners and test plans.
Ownership turns inventory into work
An algorithm does not approve a maintenance window. A certificate does not fund an appliance replacement. A key does not negotiate a change with a partner.
Owners do.
Every cryptographic dependency that enters a migration backlog needs at least one accountable service or system owner. It may also need a data owner, platform owner, PKI owner, risk owner, and external dependency contact.
This information rarely lives in a cryptographic scanner. It may be found in a CMDB, service catalog, cloud tags, repository metadata, incident-management platform, architecture record, or simply with the team that operates the service.
The solution is not to force every governance attribute into every CBOM. Keep cryptographic evidence portable, then connect it through stable identifiers to the organization’s ownership and business-service records.
High-value assets require context, not a label
U.S. federal PQC guidance explicitly connects cryptographic inventory with High Value Assets and High Impact Systems. Outside that context, organizations may use different terms: crown-jewel service, tier-zero system, critical business service, regulated platform, safety system, or mission-essential asset.
The name matters less than the reasoning behind it.
A migration priority cannot be derived from algorithm strength alone. It should consider:
- business or mission criticality;
- confidentiality lifetime of the protected data;
- integrity and authentication consequences;
- external exposure;
- scale and reuse of the dependency;
- availability of a supported replacement;
- hardware, protocol, vendor, and partner constraints;
- time required to test and deploy the change.
A public website with an RSA certificate and a short data lifetime may be easy to change but lower priority. A long-lived device identity or signing key may have limited exposure yet require years of engineering and replacement planning. The second asset may need to enter the migration program first.
A sample inventory record
The following is an illustrative enterprise overlay, not a replacement for the CycloneDX specification:
recordId: crypto-observation-10482
assetRef: cdx:urn:cdx:example/1#crypto-asset-27
assetType: certificate
algorithm: RSA-2048
purpose:
- authentication
- key-establishment
environment: production
observedBy:
source: network-scanner
observedAt: 2026-07-29T18:42:00Z
confidence: high
system:
serviceId: svc-payment-api
ownerTeam: payments-platform
businessService: transaction-processing
criticality:
classification: high-value
dataConfidentialityLifetime: 7-years
dependencies:
intraSystem:
- openssl-provider-3
- hsm-cluster-west
interSystem:
- partner-clearing-api
- mobile-client-trust-store
migration:
replacementCandidate: ML-KEM-enabled-TLS-profile
blocker:
- partner-support-unconfirmed
status: discovery-completeFields such as owner, criticality, and migration status will often come from systems outside the CBOM producer. Preserve their provenance and avoid presenting inferred ownership as confirmed fact.
Prioritization needs two dimensions
The migration backlog should consider both risk importance and change lead time.
| Business or security importance | Change lead time | Suggested treatment |
|---|---|---|
| High | Long | Start discovery, ownership validation, vendor engagement, and testing immediately |
| High | Short | Schedule an early controlled migration and capture reusable lessons |
| Moderate | Long | Resolve dependencies early; place the change in the appropriate product roadmap |
| Moderate | Short | Group into a later migration wave |
| Low or unknown | Any | Validate classification; “unknown” is an investigation queue, not a risk acceptance |
This is not a universal scoring formula. Organizations should align prioritization with their risk framework, regulatory obligations, system architecture, and migration deadlines.
How to build the connected inventory
- Define the questions first. Decide which migration decisions the inventory must support. A field with no decision behind it becomes collection overhead.
- Use multiple discovery methods. Combine network, code, binary, PKI, cloud, HSM, KMS, asset-management, and BOM sources.
- Normalize without erasing provenance. Deduplicate observations while retaining the source, time, confidence, and environment.
- Build the dependency graph. Capture intra-system and inter-system relationships, including external verifiers and partners.
- Attach accountable ownership. Connect cryptographic observations to services, repositories, teams, and business owners.
- Map criticality and data lifetime. Identify high-value or mission-critical assets using the organization’s established risk process.
- Test the graph with a change. Pick a bounded use case and ask which components, owners, and external parties must move. Missing relationships will surface quickly.
Inventory is a maintained product
A spreadsheet assembled for a deadline will age as soon as the first certificate renews, library upgrades, workload moves, or service owner changes.
The inventory therefore needs an operating model: scheduled and event-driven discovery, ownership attestation, freshness targets, quality measures, exception handling, and integration with architecture and change-management processes.
No single tool will provide all of that. A credible program combines specialized discovery, a common representation such as CBOM, organizational context, and a dependency graph that can answer a basic question:
If this algorithm, certificate, key, library, or provider must change, what else has to move—and who can make that happen?
Until the inventory can answer that question, it is a catalog. Once it can, it becomes a migration capability.
References
- NIST National Cybersecurity Center of Excellence, “Migration to Post-Quantum Cryptography,” reviewed July 30, 2026.
- NIST NCCoE, “Frequently Asked Questions about Post-Quantum Cryptography,” updated June 30, 2026.
- National Institute of Standards and Technology, “Considerations for Achieving Crypto Agility: Strategies and Practices,” NIST CSWP 39-upd1, June 29, 2026.
- NIST, “Mappings of Migration to PQC Project Capabilities to Risk Framework Documents,” NIST CSWP 48, Initial Public Draft, September 2025.
- CISA, NSA, and NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” August 2023.
- OWASP CycloneDX, “CycloneDX Bill of Materials Specification,” ECMA-424 and CycloneDX 1.7 resources, reviewed July 30, 2026.
- OWASP CycloneDX, “Authoritative Guide to CBOM,” Second Edition, 2026.
- OWASP CycloneDX, “Inventory Management Use Case: Implementation Details,” reviewed July 30, 2026.
Limitations
This article proposes an operating model rather than a universal schema or risk-scoring method. Tool coverage, ownership systems, criticality classifications, and regulatory requirements differ by organization. NIST CSWP 48 remains an initial public draft at the time of writing. The sample inventory record is illustrative and should be mapped to the organization’s approved data model and the current CycloneDX specification before implementation.