Cryptographic inventory and CBOM: the control surface for post-quantum readiness.

Public-key cryptography appears in TLS endpoints, VPNs, service identities, certificate authorities, signed software, firmware update chains, mobile applications, hardware modules, authentication flows, partner interfaces, and managed cloud services. A library name found on one server does not reveal which business process depends on it, what data it protects, or whether the organization can change it.

NIST's NCCoE migration project therefore separates cryptographic discovery and risk management from interoperability and benchmarking. Discovery establishes where and how cryptography is used; interoperability work tests whether replacement technology can operate across products and protocols. An inventory should connect these workstreams by showing which real dependency each test is meant to retire or transform.

Network observation can reveal certificates, protocol versions, public endpoints, and advertised cipher behavior. Source and dependency analysis can find cryptographic APIs and packages. Configuration review can expose certificate stores, key-management services, signing policies, and trust anchors. Device and firmware review covers secure boot, update validation, hardware roots of trust, and proprietary protocols. Contract and vendor review reaches SaaS and embedded components the organization cannot inspect directly.

The joint CISA, NSA, and NIST readiness factsheet warns that discovery tools may not identify cryptography embedded inside products and tells organizations to ask vendors for that information. A credible coverage statement must therefore say which lenses were used, what environments were in scope, which areas remain opaque, and who owns the follow-up. Scanner count is not inventory completeness.

For current program work, an evidence-ready record should connect: the business system, cryptographic function, exact algorithm or protocol, implementation and version, protected data or process, accountable owner, supplier or platform dependency, and migration state. Useful extensions include key and certificate lifecycle, validation scope, exposure, data-retention period, replacement window, test evidence, exception, and review date.

These fields are an operational synthesis, not a claim that the United States has already issued one mandatory CBOM schema. Executive Order 14412 directs CISA, in coordination with NIST, to publish guidance on minimum CBOM elements within 270 days of June 22, 2026. As of this article's July 20 date, that future guidance should be tracked as a review trigger rather than quoted as if already final.

A public TLS endpoint is easy to find, but an internal signing root, device trust anchor, archival verification key, or backup workflow may carry more durable risk. The inventory should capture confidentiality lifetime for encrypted data, integrity and authenticity lifetime for signed artifacts, current exposure, mission or business criticality, and the time required to replace the dependency.

OMB M-26-15 prioritizes high-impact systems, high-value assets, other systems with highly sensitive data, logical access systems based on vulnerable asymmetric cryptography, and data expected to remain mission-sensitive in 2030. Private organizations are not automatically governed by that memo, but its separation of criticality, data lifetime, access control, and replacement difficulty is a useful risk model when adapted to their own obligations.

Manual discovery cannot keep pace with a large estate, and OMB M-26-15 explicitly calls automation critical for inventory management, policy enforcement, and compliance reporting where feasible. Automation should ingest repeatable signals, compare them with the approved baseline, identify new or changed cryptographic use, and open a review when ownership or migration state is missing.

Automation does not remove human judgment. A certificate observation may belong to a load balancer managed for dozens of services. A vulnerable library may be installed but unreachable. A vendor may terminate TLS before the customer's environment. Findings need resolution, deduplication, context, and evidence. Track both machine coverage and the queue of unresolved relationships so a high scan rate cannot hide weak decision coverage.

For products and services outside direct control, ask where vulnerable public-key cryptography is used, which final NIST standards are implemented, which protocols and parameter sets are supported, whether the path is hybrid or PQ-only, what validation applies, and how certificates, keys, firmware, rollback, telemetry, and interoperability are handled. Request dates and version identifiers rather than a generic quantum-ready label.

CISA's product-category resource helps teams organize this outreach, while OMB M-26-15 calls out shared-responsibility questions for cloud services and directs federal agencies to incorporate PQC into modernization and procurement. An enterprise can use the same operating principle without claiming federal compliance: assign each supplier dependency an internal owner, evidence state, alternative path, decision deadline, and exit condition.

Every prioritized record needs a governed closure path: investigate, await supplier, design, pilot, approve, migrate, validate, retire, or accept a time-bounded exception. The transition evidence should identify the baseline, change, test environment, protocol and module versions, performance and failure observations, rollback result, approver, and monitoring plan.

This turns the inventory from a spreadsheet into a control surface. Executives can see coverage and blocked dependencies; architects can see protocol and trust-boundary work; procurement can see supplier gaps; auditors can trace a risk classification to evidence and approval. Re-scanning then verifies whether the old dependency disappeared and whether a new unmanaged path emerged.