SBOMs and Cryptographic BOMs as Audit Artefacts

A software bill of materials used to be a nice-to-have security practice. It is becoming an audit artefact you are required to produce. The EU Cyber Resilience Act expects manufacturers to document the components in their products via an SBOM, and the ability to report a vulnerability under the CRA’s tight reporting clock depends on knowing, precisely and quickly, which of your products contain the affected component. The same logic is now extending to cryptography: a cryptographic bill of materials (CBOM) does for algorithms and keys what an SBOM does for software components, and it is becoming the evidence behind crypto-agility.

Why the SBOM is now a compliance artefact, not just good hygiene

The shift is driven by reporting duties. Under the CRA, when a vulnerability in a common component is disclosed, an in-scope manufacturer must determine within hours whether its products are affected and report accordingly. That is impossible without an accurate, current SBOM — you cannot report what you cannot find, and “we’re not sure if we use that library” is not an answer the clock allows. So the SBOM stops being a document you generate once for a customer and becomes a live operational capability that your vulnerability response and your regulatory reporting both depend on. Regulated and government buyers increasingly require SBOMs in procurement, adding a commercial driver on top of the regulatory one.

The cryptographic BOM: the same idea for algorithms

As crypto-agility and post-quantum migration become expectations, the question “which of our products use which cryptographic algorithms?” becomes as important as “which use which software components?” A CBOM captures the cryptographic assets in a product — algorithms, key sizes, certificates, protocols — so that when an algorithm is deprecated (as classical public-key algorithms will be), you can identify and remediate every affected product. It is the cryptographic equivalent of the SBOM, and it is the artefact that makes a crypto-agility claim auditable rather than aspirational.

Making them earn their keep

• Generate SBOMs automatically and keep them current. A stale SBOM is worse than none, because it gives false confidence. The value is in a pipeline that regenerates the SBOM as the product changes.
• Connect the SBOM to vulnerability monitoring. The point is to answer “are we affected?” fast; that requires the SBOM to feed a process that correlates components against new vulnerabilities.
• Build a CBOM alongside it. Inventory cryptographic assets the same way you inventory software components, so algorithm deprecation becomes a query, not an archaeology project.
• Treat both as audit evidence. Structure and retain them so they can be shown to a supervisor, an auditor or a customer, not just consumed internally.

The organisations that get ahead treat SBOMs and CBOMs as living operational artefacts wired into vulnerability response and regulatory reporting — not as documents produced under duress the week before an audit. Done that way, they turn a compliance obligation into exactly the capability that makes the firm faster and safer when the next vulnerability lands.

Who this is for

This reading is for:

• Product and security leads facing SBOM requirements under the CRA
• Compliance teams asked to evidence software and crypto components
• CTOs whose vulnerability response depends on knowing what is inside their products
• Firms selling software into regulated or government markets

Sixteen Pillars helps you wire SBOMs and CBOMs into vulnerability response and regulatory reporting, turning a compliance obligation into a capability that makes you faster and safer. Pricing is published at /pricing/. If this is live for your organisation and you would like an independent reading, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.