Quick answer: A cryptographic inventory that actually drives migration decisions needs twelve specific fields per entry, not just “we found RSA here”: asset, owner, algorithm, key size, protocol, certificate, library, data lifetime, exposure, vendor, replacement path, and migration status. NIST SP 1800-38B identifies cryptographic inventory as the mandatory first step in PQC migration, and CycloneDX’s Cryptography Bill of Materials extension, now standardized as ECMA-424, is the common schema most tooling produces this inventory in. The difference between an inventory that sits in a spreadsheet and one that actually drives remediation work is whether every entry carries enough of these fields to answer “who owns this, how exposed is it, and what replaces it” without a follow-up meeting.
Most organizations starting PQC discovery produce a list of algorithms and where they were found. That is a starting point, not a usable inventory. This guide defines the twelve fields a PQC-ready cryptographic inventory entry actually needs, and why each one earns its place.
Key Takeaways
- NIST SP 1800-38B identifies cryptographic inventory as the mandatory first phase of PQC migration, with the Cryptography Bill of Materials as the target inventory artifact.
- CycloneDX’s CBOM extension, standardized as ECMA-424 (current version 1.7, released October 2025), is the common machine-readable schema most cryptographic discovery tooling produces.
- A twelve-field data model, asset, owner, algorithm, key size, protocol, certificate, library, data lifetime, exposure, vendor, replacement path, and migration status, is what separates an actionable inventory from a simple algorithm list.
- Fields like data lifetime and exposure are what actually enable risk-based prioritization; without them, every finding looks equally urgent regardless of real-world consequence.
- Migration status as a tracked field, not just a discovery-time snapshot, is what turns a one-time inventory project into an ongoing operational capability.
Why a Defined Schema Matters More Than the Tooling
Different discovery tools scan different layers, source code, TLS traffic, binaries, container images, cloud configuration, and each surfaces cryptographic findings in its own native format. Without a common data model that every finding gets normalized into, an organization ends up with several disconnected lists rather than one inventory, and no consistent way to prioritize across them. CycloneDX’s CBOM extension exists to solve exactly this: a standardized, machine-readable format that different tools can all export to and that downstream migration planning, risk scoring, and compliance reporting can all consume from a single source.
The Twelve Fields, and Why Each One Earns Its Place
| Field | What it captures | Why it matters for migration |
|---|---|---|
| Asset | The specific system, application, or component where the cryptography was found | Without a precise asset identifier, a finding cannot be traced back to anything actionable |
| Owner | The named team or individual responsible for that asset | An unowned finding has no one accountable for remediation; this is the single most common reason inventories stall |
| Algorithm | The specific cryptographic algorithm and parameters (e.g., RSA-2048, ECDSA-P256, AES-128-GCM) | Determines quantum vulnerability status and which PQC replacement applies |
| Key size | The specific key length or curve in use | Affects both classical security margin and which specific replacement parameter set is appropriate |
| Protocol | The protocol context the cryptography operates within (TLS, SSH, IPsec, S/MIME, etc.) | The same algorithm carries different migration paths and urgency depending on protocol context |
| Certificate | Associated certificate details: issuer, validity period, chain position | Certificate-bound cryptography has its own lifecycle and renewal-driven migration opportunity distinct from library-level findings |
| Library | The specific cryptographic library or module implementing the algorithm | Determines whether an update is a configuration change, a library upgrade, or a full redevelopment |
| Data lifetime | How long data protected by this cryptography needs to remain confidential or verifiable | The core input to harvest-now-decrypt-later risk assessment; short-lived data carries fundamentally different urgency than decade-plus retention data |
| Exposure | Whether the asset is internet-facing, internal-only, or air-gapped, and its blast radius if compromised | External exposure combined with long data lifetime is the highest-priority combination in almost every risk model |
| Vendor | Any third-party dependency this cryptography relies on (HSM, CA, cloud KMS) | Migration timeline is bounded by vendor readiness, not just internal engineering capacity |
| Replacement path | The specific PQC algorithm and implementation approach planned for this finding | Converts a passive finding into an active remediation plan with a defined target state |
| Migration status | Current state: not started, planned, in progress, or complete | Turns the inventory into a living tracking tool rather than a point-in-time snapshot |
From Observation to Work Item
The difference these fields make is concrete. “RSA-2048 found in a TLS context” is an observation; it tells a reviewer almost nothing about what to do next. “RSA-2048 in a TLS context on a payment processing API handling long-retention transaction data, owned by the payments infrastructure team, with a vendor HSM dependency whose ML-KEM support lands in Q3,” is a work item, with an owner, a risk context, a dependency, and a concrete constraint on when remediation can realistically start. The twelve-field model is what produces the second kind of entry consistently, rather than depending on whoever reviews the raw scan output to reconstruct that context manually every time.
What We’d Actually Recommend
Standardize on CycloneDX’s CBOM extension as your inventory’s underlying format from the start, since it is already the common target format most discovery tools and NIST guidance converge on, and it avoids a costly format migration later. Populate all twelve fields for every finding, not just the technical ones (asset, algorithm, key size); the ownership, data lifetime, and exposure fields are what make the inventory usable for prioritization, and they are also the fields most commonly skipped when discovery is treated as a purely technical scanning exercise. Treat migration status as a field that gets actively updated, not a one-time snapshot, so the inventory remains the single source of truth for program progress rather than going stale the day after the initial scan.
How Encryption Consulting Can Help
CBOM Secure is built around exactly this twelve-field model, producing a deduplicated, CycloneDX-based cryptographic bill of materials with ownership, data sensitivity, and vendor dependency captured at discovery time, not reconstructed manually afterward.
Our PQC Advisory Services use that structured inventory as the direct input to risk-based migration prioritization and roadmap planning, so the schema this guide describes translates into an actual sequenced program rather than staying a static reference document.
A Schema, Not Just a Scan
The technology that finds cryptography across a large environment has matured quickly; the discipline of turning what it finds into a usable inventory has not kept pace at the same rate. A twelve-field data model, anchored in the CycloneDX CBOM standard NIST guidance already points to, is what closes that gap, converting a list of algorithm findings into a genuine work queue with owners, risk context, and tracked progress. Getting the schema right at the start of a PQC migration program saves the far more expensive work of retrofitting ownership and risk data onto thousands of findings later.
Frequently Asked Questions
What is the standard format for a cryptographic inventory?
CycloneDX’s Cryptography Bill of Materials extension, now standardized as ECMA-424, is the common machine-readable format most current discovery tooling and NIST guidance point to, allowing findings from different scanning layers to be normalized into one consistent inventory.
Which fields are most commonly missing from a first-pass cryptographic inventory?
Owner, data lifetime, and exposure. Automated scanning tools reliably capture the technical fields, algorithm, key size, protocol, but ownership and risk-context fields typically require a manual enrichment step that gets skipped when discovery is treated as a purely technical exercise.
Why does data lifetime matter as its own inventory field?
It is the core input to harvest-now-decrypt-later risk assessment. Two findings with identical algorithms can carry completely different urgency depending on how long the data they protect needs to remain confidential or verifiable.
Should migration status be tracked as a static field or updated over time?
Updated continuously. A migration status field that only reflects a one-time discovery snapshot loses its value almost immediately; it needs to function as a live tracking field so the inventory remains the accurate source of truth for program progress.
Does NIST require a specific cryptographic inventory format?
NIST SP 1800-38B identifies cryptographic inventory as a mandatory first phase of PQC migration and references CBOM as the target artifact, but does not mandate a single specific format. CycloneDX’s CBOM extension is the format most current tooling and guidance converge on in practice.
