A worked CBOM example: owners, lifespan, and risk

The first CBOM from Example Corp arrives as a scanner export: several hundred components, sorted alphabetically, each with an algorithm, a key size, and a file path. Someone asks the obvious question — which of these do we fix first — and the file has no way to answer it. At the level of the algorithm field, every RSA-2048 entry is the same finding.

Example Corp is fictional. The payments platform, its assets, its owners, and its dates are illustrative; none of this is a customer, a benchmark, or a survey result. What is not fictional is the shape of the problem. A scanner sees cryptography. Prioritization needs two things a scanner does not have: who owns the asset, and how long the data it protects has to stay secret.

A flat list sorts by the wrong field

Sort an inventory by algorithm and you get groups that look actionable and are not. RSA-2048 protects a ninety-day session log and a twelve-year firmware signing chain. Both rows read “RSA-2048, quantum-vulnerable.” One has a migration window measured in quarters, the other in hardware generations, and the algorithm column cannot tell them apart.

Owner and data lifespan fix that, and they do different jobs. Owner because an asset with no owner cannot be scheduled, funded, or retired, however it scores. Data lifespan because it decides whether the exposure is already happening: traffic captured today can be decrypted later, so an asset protecting data with a ten- to fifteen-year confidentiality requirement is exposed now, while an asset protecting a session token is not.

Every other field in a CBOM describes the asset. These two describe the decision.

Eight assets from one system

The table below is the CBOM for one system at Example Corp, the payments platform’s signing and edge estate. Eight entries, deliberately not the whole company.

Asset	Owner	Environment	Data lifespan	Quantum status	Migration state
External TLS termination (merchant API)	Edge Platform	Prod, internet-facing	Session key; payload retained 7 years	Vulnerable: ECDHE P-256, RSA-2048 certificate	Hybrid ML-KEM in one region
Payments API key (HMAC-SHA256)	Payments Platform	Prod	Credential 12 months; requests retained 7 years	Adequate at 256-bit	No algorithm change; rotation review
Firmware signing key (terminal fleet)	Device Security	Offline HSM	12-year device field life	Vulnerable: ECDSA P-256	Dual-sign designed; verifier generation unshipped
Internal issuing CA (service mesh)	PKI Team	Prod	10-year root	Vulnerable: RSA-4096	Re-issue planned 2028; no ML-DSA profile
Agent gateway identity (mTLS)	Agent Platform	Prod	24-hour certificate	Vulnerable: ECDSA P-256	Rotation automated; swap is config-only
HSM data-at-rest keys (AES-256)	Crypto Services	Prod	10 years at rest	Adequate, but wrapped with RSA-2048 OAEP	Key wrap migration unscheduled
Vendor payments SDK (bundles TLS stack and CA store)	Unassigned	Prod and build	Inherited, roughly 5 years	Unknown: vendor CBOM requested	Blocked
Orphaned certificate (expired last year, still trusted)	Unassigned	Prod trust store	None, but still trusted	Vulnerable: RSA-2048	Cleanup decision pending

Three things stand out before any analysis. Two rows have no owner, and both of them are exposure: the vendor SDK and the orphaned certificate. One row is a dependency rather than an asset in its own right — the AES-256 keys are fine, the RSA-2048 key wrap around them is not, which a scanner records as two findings and a spreadsheet tends to merge into one. And one row is honestly unknown. The vendor SDK’s algorithms, bundled trust store, and post-quantum support are all unanswered, which is worse than vulnerable because you cannot schedule a question mark.

The same assets in CycloneDX

The table is a management artifact. The file is what you ship, diff, and attach to a review. CycloneDX 1.6 added the cryptographic-asset component type, and its properties array is where the two fields that matter actually live.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "cryptographic-asset",
      "bom-ref": "asset/terminal-firmware-signing-key",
      "name": "terminal-firmware-signing-key",
      "cryptoProperties": {
        "assetType": "related-crypto-material",
        "relatedCryptoMaterialProperties": { "type": "private-key", "state": "active" }
      },
      "properties": [
        { "name": "owner", "value": "device-security" },
        { "name": "data-lifespan-class", "value": "L4-field-life-12y" },
        { "name": "migration-state", "value": "dual-sign-designed" }
      ]
    },
    {
      "type": "cryptographic-asset",
      "bom-ref": "asset/vendor-payments-sdk",
      "name": "vendor-payments-sdk",
      "cryptoProperties": { "assetType": "algorithm" },
      "properties": [
        { "name": "owner", "value": "unassigned" },
        { "name": "data-lifespan-class", "value": "L3-retained-5y" },
        { "name": "migration-state", "value": "blocked-vendor-cbom" }
      ]
    }
  ]
}

This excerpt is illustrative, not normative. Validate anything you emit against the spec version you claim, and keep the value vocabulary closed: a lifespan class that means something different in two teams produces a CBOM you cannot sort. The migration-state field is worth more than it looks. It turns each export into a diff, and a diff is the only progress metric an auditor will accept for work that spans years.

The order the table implies

Read the table with two questions. Can an attacker reach it today? How long does what it protects have to stay secret? For signing assets, add a third: how long does the signature have to verify?

Externally reachable, long retention. The merchant API terminates sessions in milliseconds and the payload is retained for seven years. That combination is the harvest-now case: the session is short, the data is not, and an adversary recording traffic today is buying the 2030s. It is also the asset with the most peers you do not control, which makes hybrid the practical first move rather than pure post-quantum. The vendor SDK sits at the same priority for a different reason. It touches production and the build, it is inherited rather than chosen, and nobody can currently say what it does.

Signing, next, because of field lifetime. The firmware signing key and the internal CA protect no session at all. Their output has to verify years after it is produced, on verifiers Example Corp cannot update. The firmware key’s binding date is not December 31, 2031. It is the last date the terminal hardware roadmap allows a verifier change, which is earlier and outside the security team’s control. The internal CA belongs here too: a ten-year root that gets embedded in more trust stores every quarter becomes more expensive to replace each quarter you wait.

Short-lived identity, third. The agent gateway certificate lives 24 hours and rotates automatically. The algorithm is a configuration value, so the work is small and the deadline is soft. Doing it early is fine as a rehearsal for the pipeline you will need elsewhere, as long as nobody mistakes it for progress on the harder rows.

Symmetric, last. AES-256 is not the problem and never was. The migration item hiding in that row is the RSA-2048 key wrap around the data keys, and it belongs to the key-establishment track, not the signing track. The payments API key is HMAC-SHA256 with a 12-month credential life and needs no algorithm change at all — say so explicitly in the record, or someone will budget for it.

The orphaned certificate is not a migration. It is cleanup, and it should happen this week, because it is cheap and because it names the ownership gap that produced it.

Three decisions the table enables

What to migrate first. One region of merchant TLS to hybrid ML-KEM, with the exception list published monthly. Not the firmware estate, which needs a hardware generation, and not the HSM symmetric keys, which need a schedule rather than a pilot.

Who owns it. The owner column converts a finding into a work item with a name attached. Two blank cells are the most valuable output of the exercise, because an unassigned asset is the one that will still be running RSA in 2032 with nobody accountable for the exception.

What evidence to produce. The CycloneDX export, with owner, lifespan class, and migration state as properties, and a signed trust-store inventory to prove the orphan is gone. That artifact answers the vendor questionnaire in March 2027 and the audit question after it, without a new project.

A CBOM is not a security deliverable in the abstract. It is the thing that lets a platform lead refuse a non-compliant vendor, schedule a hardware generation, and tell an auditor which algorithm protects which interface. Eight rows and two columns is enough to start.