A cryptographic bill of materials is useful only when it answers operational questions: which business service depends on a vulnerable algorithm, where the implementation comes from, what data or function it protects, who can change it, and whether a replacement has been tested. A certificate spreadsheet answers only a narrow subset. It misses hard-coded algorithms, library defaults, application protocols, firmware verification, code-signing formats, hardware security modules, API gateways, partner connections, and cryptography hidden inside purchased products. That omission becomes expensive during a post-quantum migration because teams discover dependencies only after a protocol or key change breaks production.
The NIST NCCoE migration project describes cryptographic inventory as a record of algorithms, protocols, keys, certificates, systems, components, and protected data, without storing secret key material. Joint CISA, NSA, and NIST guidance similarly calls for discovery across network protocols, endpoints, servers, application libraries, firmware, update mechanisms, and CI/CD pipelines. Treat those categories as the minimum coverage model, then connect them in a machine-readable CBOM that can change with the estate.
Define the decisions the CBOM must support
Start with decisions, not fields. A PQC program needs to rank migrations, identify systems that cannot accept a larger key or signature, contact suppliers, plan dual-algorithm operation, and prove that old cryptography has been removed. Incident responders may need to find every service using a compromised library or certificate authority. Architects need to detect policy exceptions. Asset owners need upcoming certificate, key, and product end-of-support dates. Write these queries as acceptance tests for the inventory. If the proposed data model cannot answer them with attributable evidence, adding more scanner output will not make the CBOM complete.
| Decision | Required relationships | Evidence | Action produced |
|---|---|---|---|
| Prioritize PQC work | Data lifetime, exposure, algorithm, service criticality | Data classification and observed crypto use | Ranked migration backlog |
| Replace a library | Component version, consumers, API, build artifact | SBOM, build manifest, runtime trace | Compatibility test set |
| Respond to deprecation | Algorithm, key length, protocol, policy exception | Configuration and handshake observations | Owner and deadline |
| Manage a supplier | Product, vendor, embedded crypto, support release | Supplier CBOM and contract evidence | Upgrade or exit decision |
| Prove completion | Old and new states, deployment, validation result | Scan history and change record | Signed closure evidence |
Design a relational CBOM data model
Model entities separately so one observation does not become an overloaded row. Useful entities include business service, deployable asset, software component, cryptographic primitive, protocol, key or certificate metadata, cryptographic operation, protected data class, external counterparty, supplier, environment, owner, and discovery observation. Relationships carry the meaning: a service uses a component; the component invokes an algorithm for a named operation; that operation protects a data flow; a certificate chains to an issuer; a supplier supports a replacement in a particular release. Keep provenance, collection time, confidence, and last verification on every observation.
Do not place private keys, symmetric keys, seeds, recovery material, or sensitive plaintext in the CBOM. Store identifiers and management metadata: key type, size, purpose, owning vault or HSM, non-secret fingerprint, rotation state, and reference to the authoritative system. The CycloneDX CBOM capability provides structured representations for algorithms, certificates, protocols, and related cryptographic assets. Use a standard where it fits, but preserve local links to services, data classifications, owners, findings, and migration work because those relationships turn component facts into risk decisions.
Collect evidence from multiple planes
No single discovery technique sees the whole system. Static source and binary analysis can find algorithm calls and bundled libraries but may miss dynamically selected providers. Configuration collection sees enabled suites but not necessarily negotiated use. Network observation reveals actual handshakes but misses dormant disaster-recovery paths and internal cryptography. Certificate management systems know issuance and expiry but not every consumer. HSM and cloud key-management inventories reveal managed keys, while build manifests reveal dependencies. Supplier attestations are essential for appliances and SaaS, yet should be tagged as declared rather than observed evidence. Reconcile these planes instead of declaring one tool authoritative for all fields.
| Evidence plane | Strong coverage | Common blind spot | Reconciliation key |
|---|---|---|---|
| Source and binary scan | Calls, constants, bundled providers | Runtime selection and remote services | Repository, component, build digest |
| Runtime and network | Negotiated protocols and active endpoints | Dormant paths and payload encryption | Asset, process, destination |
| PKI and key management | Certificates, managed keys, lifecycle | Unmanaged stores and application semantics | Fingerprint or key reference |
| Configuration management | Allowed suites and policy | Actual use and local overrides | Asset and configuration version |
| Supplier evidence | Embedded product and roadmap claims | Local configuration and evidence freshness | Product version and contract |
| Manual architecture review | Business purpose and protected data | Rapid drift and technical detail | Service and accountable owner |
Normalize observations and score confidence
Normalize algorithm names, object identifiers, protocol versions, key sizes, certificate fingerprints, component identifiers, and environment labels before deduplication. RSA may appear as a library symbol, certificate public-key algorithm, SSH host-key type, or policy label; those are related observations, not interchangeable facts. Retain raw evidence for audit, map it to a canonical taxonomy, and record whether use is configured, observed, inferred, or supplier-declared. A confidence score should drive follow-up, never hide uncertainty. Conflicting observations become work items: for example, a scanner finds RSA code while production telemetry shows only ML-KEM-enabled test traffic.
Connect every finding to migration state
Inventory without workflow decays into reporting theatre. Add a migration state such as discovered, validated, risk-assessed, target selected, dependency blocked, pilot scheduled, dual-operation, production migrated, legacy disabled, and independently verified. Record the target standard and profile, not merely the word quantum-safe. The NIST PQC project is the authoritative source for standardized algorithms and updates; local profiles must still specify protocol integration, parameters, provider validation, interoperability, and fallback policy. Link each state change to a ticket, change record, test result, approver, and review date.
Operate the CBOM as a continuous control
Generate CBOM fragments during builds, ingest cloud and PKI changes, observe selected protocols at runtime, and reconcile supplier updates on a schedule. Event-driven updates should follow a new component version, certificate issuance, algorithm-policy change, architecture release, asset retirement, or vendor roadmap revision. Measure coverage by critical service and evidence plane, stale observations, unowned findings, conflicting records, and time from discovery to validated disposition. Snapshot signed exports for audits and migration milestones, while keeping the operational graph current. A spreadsheet may remain a convenient review view, but it should be a projection of governed records rather than the system of truth.
Phase CBOM delivery around useful evidence
Begin with two critical services and trace transport, signing, and stored-data cryptography from business purpose to observed implementation. Confirm canonical identifiers, provenance, ownership, data links, and refresh events before connecting more scanners. Next, automate build, PKI, cloud key-management, and network observations; route conflicts to service owners instead of silently choosing one source. Add supplier records only with product versions, evidence dates, and local configuration links. A service is onboarded when its owner validates relationships, evidence-plane blind spots are explicit, material findings have migration states, and change events refresh the record. Expand coverage by business criticality, then use stale observations, unknown owners, unresolved conflicts, and verified legacy removal as governance metrics. This sequencing proves that the CBOM supports real decisions before volume makes an inadequate model costly to replace.
Govern schema changes as carefully as scanner changes. A new field should have a decision use, source, validation rule, steward, and compatibility plan. Restrict access because the graph can reveal critical systems and trust relationships even without secrets. Test exports for accidental key material and sensitive topology. Back up the inventory, rehearse restore, and sign milestone snapshots so auditors can distinguish what was known at a past date from later discovery. When an asset retires, preserve enough history to explain earlier risk and evidence while removing obsolete operational access. These controls make the CBOM itself a dependable security system.
Cryptographic bill of materials key takeaways
- Define the migration, deprecation, incident, and supplier decisions before selecting fields or tools.
- Represent algorithms, operations, components, keys, protocols, data, services, owners, and counterparties as linked entities.
- Combine static, runtime, configuration, PKI, key-management, architecture, and supplier evidence.
- Keep secret material out of the CBOM while retaining non-secret lifecycle and provenance metadata.
- Turn every material finding into an owned migration state with tests and closure evidence.
- Measure critical-service coverage and freshness, not the raw number of discovered cryptographic objects.
Cryptographic bill of materials FAQ
Is a CBOM the same as an SBOM? No. An SBOM identifies software components and dependencies. A CBOM represents cryptographic assets and use. The two should link because a component may implement or invoke cryptography, but neither replaces the other.
Should certificates be included? Yes, with non-secret metadata, chains, uses, consumers, expiry, and management references. They are one class of cryptographic asset, not the boundary of the inventory.
How complete must the first release be? Complete enough to expose uncertainty. Begin with critical services and high-value data, document evidence-plane coverage and blind spots, then expand through automated collection and owner validation.
Conclusion
A defensible CBOM is a living map from cryptographic implementation to business consequence and change authority. Build it from multiple evidence planes, preserve provenance, make uncertainty visible, and connect records to migration workflow. That design supports PQC planning today and the next emergency algorithm transition without forcing the organization to rediscover its cryptography under pressure.