SBOM Delivery: Methods, Requirements & Setup

Creating a software bill of materials is only the first step. You also need to deliver the right SBOM to the right recipient, in the right format, for the exact product and firmware version they use. For connected and embedded products, that process must support long lifecycles, supplier dependencies, customer requests, and regulatory requirements such as the EU Cyber Resilience Act and US FDA rules. Common Criteria evaluations can also rely on detailed configuration and vulnerability evidence, making controlled SBOM delivery an important part of product security and compliance.

What Is SBOM Delivery?

SBOM delivery is the controlled process of making an SBOM available to an intended recipient or system. An SBOM itself is a structured inventory of software components and dependencies, while delivery covers where the file goes, who can access it, which version it represents, and how updates reach the recipient. CISA treats distributing and sharing an SBOM as part of the wider SBOM lifecycle, not as the same task as creating the inventory.

The distinction matters for product security because an accurate SBOM can still fail operationally if customers receive an old file, cannot identify the matching product version, or cannot import the format. In an SBOM cybersecurity workflow, delivery should preserve traceability between the SBOM, the product release, and any later vulnerability information. If you need a broader definition before focusing on distribution, What is an SBOM and why it matters covers the underlying inventory and security use cases.

What Is The Difference Between SBOM Delivery vs. SBOM Generation?

SBOM generation creates the inventory, SBOM delivery makes that inventory usable outside the system that created it. Generation can happen during a build, from source-code analysis, from a binary or firmware scan, or by importing supplier data. Delivery begins when you package, publish, transmit, expose, or otherwise provide the approved SBOM to a customer, regulator, evaluator, partner, internal team, or automated platform.

The two processes need separate controls because each can fail in a different way. A complete SBOM may be delivered to the wrong customer, while a well-designed API may distribute an incomplete inventory perfectly. ONEKEY’s SBOM management tool can generate, import, merge, monitor, and export SBOM data in standard formats such as CycloneDX and SPDX, which helps connect the inventory stage with repeatable downstream use.

Why SBOM delivery is under more scrutiny now

Regulators and buyers increasingly expect software transparency to work as an operating process rather than a one-time document. The CRA requires manufacturers to identify and document product vulnerabilities and components, including by drawing up an SBOM in a commonly used machine-readable format that covers at least top-level dependencies. FDA requirements for cyber devices go further in a different context by requiring an SBOM as part of specified premarket submissions.

Supply-chain risk also changes after release because new CVEs can affect components that were considered safe when a product shipped. Your delivery model should support refreshed data and, where appropriate, vulnerability status alongside the component inventory. SBOM & VEX workflows help separate the question “What is inside this product?” from “Does this vulnerability actually affect this product?”, which is important when customers use SBOMs for ongoing risk decisions.

NIS2 adds another reason to improve the process even though the directive does not create a blanket SBOM-delivery mandate. Article 21 requires covered essential and important entities to manage cybersecurity risk, including supply-chain security and relationships with direct suppliers and service providers. Reliable SBOM exchange can support that work by giving teams a version-specific view of software dependencies, but it does not replace the broader NIS2 controls.

4 Things to Clarify Before You Deliver an SBOM

A delivery process should start with four decisions, not with an email attachment or export button. These decisions prevent common disputes about scope, access, format, and timing. They also give product, PSIRT, engineering, compliance, and customer teams one definition of what “delivered” means.

1. Who is the recipient? Decide whether the SBOM is for a regulator, certification body, evaluator, enterprise customer, distributor, internal security team, or automated platform. The recipient affects access controls, required metadata, contractual obligations, and whether human-readable context is needed alongside the machine-readable file.
2. Which exact product does it describe? Tie the SBOM to a product identifier, firmware or software version, release date, hardware variant where relevant, and generation timestamp. Connected products often have multiple branches in the field, so “latest SBOM” is not enough if customers run older supported versions.
3. Which format and data fields are required? Agree on the schema, version, required component fields, dependency depth, identifiers, and any requested enrichment before delivery. CycloneDX and SPDX are widely used machine-readable formats, but a valid file still needs enough data for the recipient’s tools and policy.
4. How will updates and access work? Define whether delivery is one-time, release-based, scheduled, or continuously accessible through a portal or API. Set rules for authentication, retention, superseded versions, notifications, and evidence that a recipient received or could retrieve the correct artifact.

SBOM Delivery Methods, Compared

There is no single delivery channel that fits every product or customer. A medical-device submission, an OEM supplier exchange, a public open-source release, and an internal PSIRT workflow can all need different controls. The best method gives the recipient reliable access without losing product-version traceability or exposing information that your policy treats as restricted.

Public delivery is not automatically wrong, and private delivery is not automatically secure. Your decision should reflect the sensitivity of the component data, regulatory obligations, customer agreements, and the purpose of the SBOM. A public URL can work well when transparency is intended, while authenticated access is often better when the file contains product details that should only reach approved parties.

Machine-to-machine methods become more valuable as your product range grows. APIs and repositories can reduce manual handling, but they need strong identity, authorization, logging, and version controls so automation does not distribute the wrong artifact faster. The delivery method should also let you preserve older SBOMs for supported firmware versions rather than overwriting history.

How to Set Up Automated SBOM Delivery

Automation works best when delivery is tied to a product event such as a release, approved firmware build, regulatory submission, or customer entitlement. The workflow should validate the SBOM before publication and keep enough evidence to show exactly what was delivered. That turns SBOM delivery from an ad hoc request process into a repeatable product-security control.

A practical automated flow can use these steps:

1. Create or import the SBOM. Generate the inventory from the relevant build or analyze the firmware binary, then merge trusted supplier data where needed.
2. Validate structure and scope. Check the schema, required fields, component relationships, product identifier, firmware version, and timestamps before release.
3. Apply release policy. Confirm that the SBOM belongs to an approved product version and meets the recipient’s required format and disclosure rules.
4. Publish through the approved channel. Export to the portal, repository, API endpoint, secure transfer location, or submission package selected for that recipient.
5. Notify or expose machine-readable status. Tell human recipients that a new version is available, or let downstream tools identify the new artifact through an API or repository event.
6. Record delivery evidence. Retain the SBOM version, product mapping, publication time, destination, access status, and any checksum or release identifier your process uses.
7. Monitor and redeliver when needed. Trigger a new SBOM when software composition changes, and keep vulnerability status in a separate but connected process when new security information appears.

ONEKEY can generate SBOMs from compiled binaries without requiring source code, merge SBOM inputs, export standard formats, and continuously monitor the resulting product inventory for vulnerabilities. That is useful for embedded environments where the delivered firmware can differ from what source repositories alone suggest. Automation should still follow your approval and disclosure policy, especially when different customers or authorities have different delivery requirements.

Delivery Requirements by Regulation

SBOM requirements are not identical across the CRA, NIS2, and FDA rules. Some laws require creation, some require submission in a defined regulatory process, and some create broader supply-chain duties where an SBOM is useful evidence rather than a named universal deliverable. Your firmware compliance process should map each product and market to the requirement that actually applies instead of treating every SBOM request as the same obligation.

The CRA point is easy to misread. Annex I requires manufacturers to draw up the SBOM, while Annex II specifically addresses user access only if the manufacturer chooses to make the SBOM available to the user. The regulation also requires manufacturers to maintain technical documentation and demonstrate conformity, so your internal SBOM still needs to be controlled, current, and retrievable even when you do not publish it openly.

FDA creates a clearer submission event for cyber devices. Section 524B(b)(3) requires an SBOM for relevant premarket submissions, and FDA’s current 2026 guidance recommends machine-readable SBOMs consistent with recognized minimum information plus component support details. Product teams should distinguish that regulatory submission from ongoing customer access, because FDA also recommends giving users current SBOM information and keeping online links accurate when a portal is used.

Does Common Criteria (ISO/IEC 15408) Require SBOM Delivery Too?

Common Criteria is an international framework for evaluating the security properties of IT products against stated functional and assurance requirements. The current ISO editions are published as the ISO/IEC 15408:2026 family, while ISO/IEC 18045:2026 defines the evaluation methodology. The term iso 15408 is often used for the same standards family, while CC:2022 remains the corresponding Common Criteria release used within the international certification framework.

SBOM Delivery Is Not a Universal Common Criteria Requirement

The core common criteria framework does not impose one blanket rule saying every evaluated product must provide an SBOM to every customer. Evaluation evidence depends on the Security Target, applicable Protection Profile, selected Security Assurance Requirements, scheme rules, and the exact Target of Evaluation (TOE). Current certification reports show that some evaluations do use SBOMs as evidence for software composition and vulnerability analysis, so an accurate component inventory can still be valuable to common criteria certification.

One important naming trap is the Common Criteria assurance family ALC_DEL, which covers delivery procedures for the TOE. That “delivery” concerns protecting the evaluated product as it moves from the developer to the downstream user, it is not a general requirement to deliver an SBOM. Treating ALC_DEL as an SBOM distribution rule would mix two separate controls.

How an SBOM Can Support Common Criteria Evaluation

SBOM evidence can strengthen an evaluation when software components and dependencies matter to the evaluated configuration. It can help teams map third-party libraries to the TOE, support configuration management, reproduce the evaluated software set, and give evaluators a clearer basis for vulnerability searches. A 2026 Australian certification report, for example, records an SBOM assessment under a specific Application Software Protection Profile, while a 2026 NIAP validation report states that an SBOM was used during vulnerability analysis.

Evaluation Assurance Levels add another layer of context. A common criteria EAL is a predefined assurance package, with levels EAL1 through EAL7 representing increasingly demanding assurance activities, it is not a score for how complete an SBOM is. Your SBOM should support the evaluation evidence actually requested by the applicable profile, scheme, evaluator, and assurance package rather than trying to “meet an EAL” on its own.

For connected products, the practical overlap is evidence reuse. A well-controlled SBOM can support CRA vulnerability documentation, customer software-transparency requests, internal PSIRT work, and parts of a Common Criteria evidence set without claiming that one artifact satisfies every framework. This can reduce duplicated evidence work when you prepare for common criteria certification while maintaining separate requirements for each framework.

Common SBOM Delivery Mistakes

Most delivery problems are not caused by the SBOM format alone. They come from weak product mapping, unclear ownership, and processes that stop after a file is exported. A strong SBOM cybersecurity process should make it hard to send an obsolete or mismatched SBOM and easy to prove which artifact belongs to each release.

Common mistakes include:

• Sending “the latest SBOM” without a product-version match. A customer may be running firmware that is two releases behind, so the newest inventory can give a false view of exposure.
• Treating an SBOM as a vulnerability report. An SBOM lists components and dependencies, vulnerability findings and exploitability decisions need connected data and may be communicated through VEX or other security records.
• Overwriting old SBOMs. Long-lived devices require historical inventories because older supported or deployed firmware can remain in the field for years.
• Using email as the default distribution system. Attachments are difficult to revoke, update, and track across many customers, even when email is acceptable for an exceptional handoff.
• Publishing without a disclosure policy. Public SBOM access can be appropriate, but the decision should be deliberate and consistent with contracts, product-security policy, and the data you include.
• Generating once and never refreshing. Composition changes when dependencies, firmware, or supplier components change, so delivery must be connected to release and lifecycle processes.
• Ignoring supplier SBOM quality. Imported files may use different identifiers, dependency depth, or naming conventions, which can create gaps when they are merged into product-level inventories.
• Confusing regulatory evidence with customer delivery. A file prepared for an FDA submission or evaluation package may not be the same artifact, access model, or context needed by a customer.

A final control is ownership. Product teams should know who approves release of an SBOM, who maintains the delivery channel, who answers recipient questions, and who triggers a replacement when product composition changes. Without those roles, even technically valid SBOM files can become stale compliance artifacts instead of useful security data.