An industrial gateway ODM somewhere in the APAC manufacturing belt receives a polite, two-page request from one of its larger European brand customers. The customer wants a Software Bill of Materials for the gateway product line. The format is specified: CycloneDX 1.5, with SPDX identifiers, dependencies enumerated to three levels, integrated into the ODM’s CI/CD pipeline. The deadline is two weeks. The engineering manager forwards the request to the software team and goes back to other work.
Two weeks later the software team comes back with what looks like a partial response. The first level of dependencies is enumerated cleanly. The second level is mostly there. The third level has a hole in it, and the hole is in the same place where the entire RTOS lives. The team explains: the RTOS comes from a partner as a binary blob. Nobody at the ODM has ever opened it. There is no source available, no licence inventory, no list of internal components. They can list the blob as a single line item, but they cannot list what is inside the blob, because they have never been told.
That meeting is the moment the SBOM stops being a document and becomes a mirror. The question the team had been asked was not really “produce a document.” The question was “tell us what is in the product you have been selling.” And the answer turned out to be “we do not entirely know.”
§ 01The SBOM is the measurement, not the report
Most introductions to SBOM treat it as a deliverable — a thing you produce, a file you hand over, an artefact that closes a checkbox in a procurement form. That framing is operationally convenient and intellectually wrong. The SBOM is not a deliverable. It is a measurement.
What is being measured is the manufacturer’s visibility into its own supply chain. A complete SBOM, with every component traced down to its constituent libraries and licence terms, is the artefact a manufacturer with full supply-chain visibility can produce. An SBOM that lists top-level components clearly but goes blank below the second level is the artefact of a manufacturer with second-level visibility. An SBOM that lists everything except a binary blob from a partner is the artefact of a manufacturer who can see everything except the part their partner refuses to open. The thing being measured does not change with how cleanly the document is formatted. The document is just the readout.
This is the structural insight that makes the CRA’s SBOM requirement different from a marketing exercise. The legislator could have required a generic statement of supply-chain hygiene, a checklist of vendor questionnaires, an attestation. The legislator chose, instead, to require a specific machine-readable artefact in a known format. The choice is deliberate. A statement is something you write. An attestation is something you assert. An SBOM is something you produce by examining what is actually in the product. The legislator picked the artefact that maps most directly onto reality, and the artefact that exposes most directly what the manufacturer does not know.
For an APAC ODM in particular, the implication is uncomfortable but precise. The SBOM the company can produce on demand is the measurement of how much of its own product it actually understands. A thin SBOM is not a documentation problem. It is a knowledge problem. Fixing the document, without fixing the knowledge underneath, just makes the document misleading. The CRA does not reward misleading documents.
This reframing also clarifies why so many APAC manufacturers initially treat the SBOM requirement as smaller than it is. Read as a deliverable, the SBOM looks like a few weeks of tooling work. Read as a measurement, it is the visible end of a multi-quarter supply-chain restructuring exercise. Both readings cost effort, but the second one costs the right kind of effort.
§ 02The “at the very least” trap in Annex I, Part II(1)
Annex I, Part II, point (1) of the CRA spells out the SBOM obligation in a way most readers misread on first pass. The text requires the manufacturer to identify and document vulnerabilities and components contained in the product, “including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.”
The phrase doing most of the work in that sentence is “at the very least.” A manufacturer reading the clause for the first time tends to treat “top-level dependencies” as the operative requirement and “at the very least” as decorative throat-clearing. The opposite is closer to the truth. “Top-level” is the floor; “at the very least” is the legislator signalling that the floor is exactly that — a floor, not a ceiling, not a default, not the answer.
The reason the floor is not the answer becomes clear when you read the SBOM clause in conjunction with Article 13(8) through (13), which set out the manufacturer’s vulnerability-handling obligations through the support period. The manufacturer must identify and address vulnerabilities effectively, must apply security updates, must coordinate with vulnerability disclosures. None of these obligations can be discharged with a top-level-only SBOM. A vulnerability in a transitive dependency — a library three layers down — is still a vulnerability the manufacturer is obliged to address, and the manufacturer cannot address what the SBOM does not surface. The top-level requirement is the minimum format compliance; the vulnerability-handling obligation is the actual depth requirement. They have to be read together.
Industry practice has converged, in the years since SBOM tooling matured, on a working depth heuristic. Most security teams and SBOM tooling vendors treat “top-level plus transitive close to a meaningful depth” as the working standard for being able to perform vulnerability analysis with reasonable coverage. The exact depth varies with the technology stack — firmware with embedded RTOS components is different from a Linux-based gateway, which is different from a containerised cloud service — and there is no single magic number. But the direction is consistent: top-level alone is the floor, transitive depth is where the analysis becomes operationally meaningful, and the CRA’s vulnerability-handling obligations land closer to the latter than the former.
What the legislator did not do is specify the exact depth. That decision sits with the manufacturer, who has to be able to defend it — against a market surveillance authority, against a customer audit, against a notified body in the conformity assessment for an important or critical product. The defence rests not on the floor but on whether the chosen depth actually supports the vulnerability-handling work the regulation requires. A manufacturer who picked “top-level only” because Annex I’s text appeared to permit it, and who cannot then show how it traces vulnerabilities in transitive dependencies, has answered the wrong question.
§ 03The SBOM is a live document, not a release snapshot
An SBOM is meaningful only in relation to the version of the product that is actually on the market. This is a sentence that sounds obvious and turns out, in operational practice, to be the source of a large fraction of CRA-compliance failures.
The pattern looks like this. The manufacturer ships firmware version 1.2.0 with SBOM A. A month later, a security patch updates an OpenSSL component, and the manufacturer ships version 1.2.1. The SBOM that accompanies version 1.2.1 must be SBOM B, reflecting the new OpenSSL version. Three months later, the firmware switches to a different RTOS subcomponent for unrelated engineering reasons; that becomes version 1.2.2 with SBOM C. Each version on the market needs its own SBOM, retrievable on demand, mapped one-to-one to the firmware artefact actually installed on customer equipment.
Most APAC ODMs do not have this discipline operationally. The SBOM, when it exists at all, tends to be produced once at major release, archived, and treated as static. Patch releases ship without an updated SBOM because the patch was “just a small change.” A market surveillance authority asking, twelve months later, for the SBOM of the version actually in field deployment receives an out-of-date document, and out-of-date documents are operationally indistinguishable from missing documents. The SBOM has to be a release artefact that ships every time anything ships, generated by the build pipeline and stored alongside the firmware binary. Tooling to do this exists in mature form: Syft, the CycloneDX generator family, SPDX tooling, language-specific dependency scanners. The tooling is not the bottleneck. The release process is the bottleneck.
Two structural changes follow from treating the SBOM as a live document. First, the release pipeline has to gate on SBOM generation. A firmware build that does not produce a current SBOM is not a release candidate. Second, the SBOM has to be archived against version identifiers in a way that supports query-by-version, because the question that arrives from a market surveillance authority or a customer is always “send us the SBOM for version X” — never just “send us your SBOM.” A manufacturer with thirty product lines and several hundred firmware versions in field deployment has a non-trivial archive problem to solve, and solving it after the first information request arrives is much more expensive than solving it in advance.
§ 04The black boxes APAC supply chains are full of
The most painful part of producing an honest SBOM, for most APAC industrial manufacturers, is not the parts the company wrote itself. It is the parts the company received from upstream as binary, with no source, no documentation of internal composition, and frequently no contractual right to ask for either. Three categories of these black boxes show up repeatedly.
Black box 1 — BMC firmware blobs. Server boards, industrial PCs, edge gateways, and a wide range of networked equipment carry baseboard management controllers. The BMC firmware on most of these comes pre-built from a small number of upstream vendors, integrated by the platform builder, and shipped as a binary image with limited or no visibility into its internal composition. When CVE-2024-54085 became public in March 2025, manufacturers across APAC discovered, in real time, that they did not have an answer to “is this CVE in our product” without going back to the BMC firmware vendor and asking. Some vendors answered quickly. Others took weeks. The CRA timeline does not allow weeks. The SBOM has to surface BMC firmware contents as a structural matter, not as something arranged in an emergency.
Black box 2 — UEFI BIOS images. The UEFI firmware on x86-based industrial platforms comes from independent BIOS vendors, with portions licensed and integrated from multiple upstream sources, and ships as a binary image carrying internal modules whose origins and versions are not always documented to the platform OEM. UEFI vulnerabilities are not theoretical: the LogoFAIL family of vulnerabilities in 2023, the BootHole vulnerabilities before that, and a steady stream of UEFI module CVEs in between have all required platform OEMs to trace components back through several layers of supplier relationships to identify exposure. A CRA-compliant SBOM cannot leave the BIOS image as one opaque line.
Black box 3 — chip-vendor SDKs and reference firmware. Connected products built on SoC platforms from major chip vendors typically integrate vendor-supplied SDK components for wireless stacks, cryptographic libraries, USB and networking drivers, and bootloader chains. These SDKs frequently incorporate open-source components whose versions, patch levels, and licensing are documented internally by the chip vendor but are not always exposed to the OEM in machine-readable form. The Realtek CVE-2021-35394 disclosure in 2021 exposed this category sharply: a vulnerability in chip-vendor SDK code propagated, silently, into hundreds of OEM products whose makers had no clear inventory of what SDK version they were shipping. SBOM compliance forces this inventory to be made explicit.
The pattern across all three categories is the same. The black box is comfortable, commercially, as long as nobody is asking what is inside. The CRA asks. The asking is now a regulatory obligation, not a customer’s preference. And the manufacturer cannot answer the question without contractual leverage on the upstream supplier — leverage which, in many APAC supply-chain relationships, has historically not existed.
§ 05The SBOM forces a contract rewrite, in two directions
The SBOM obligation is not just a technical obligation. It is a trigger for contract revision — upstream with component suppliers, and downstream with brand customers. APAC ODMs that have lived comfortably with informal supplier relationships need to revisit those contracts with specific clauses, and ODMs that have lived comfortably with informal brand-customer arrangements need to negotiate the SBOM ownership question explicitly.
Upstream — the ODM’s contracts with its component and firmware suppliers. The minimum clause set: each component supplier must deliver, alongside the component itself, an SBOM in CycloneDX 1.5 or SPDX 2.3 format covering the component to a specified depth; the supplier must deliver an updated SBOM whenever the component is updated; the supplier must respond to vulnerability notifications within a defined timeframe; the supplier must provide remediation timelines for confirmed vulnerabilities. The contract has to specify what happens when the supplier does not comply — rejection of delivery, payment hold, contract termination. None of this is exotic in mature software supply chains; it is exotic in many APAC industrial supply chains because the relationships predate the regulatory environment that now requires it.
Downstream — the ODM’s contracts with its European brand customers. The negotiation here turns on a question that is rarely surfaced explicitly: who is named as the manufacturer on the EU Declaration of Conformity for the integrated product? The party named there owes the Article 13 obligations, including the obligation to produce a current SBOM on demand. If the brand customer is named, the SBOM has to be assembled by the brand from the ODM’s SBOM plus the brand’s own integration layer. The contract has to specify the format the ODM delivers in, the update cadence, the licensing terms for redistribution, and the parties’ respective responsibilities when an Article 14 incident triggers a 24-hour reporting clock that requires SBOM lookup at speed.
The structural error most APAC manufacturers make in these conversations is to treat the SBOM as a technical artefact rather than as a contractual one. The SBOM is the evidence object that flows through three contractual relationships — supplier-to-ODM, ODM-internal, ODM-to-brand — and the regulatory obligations attach to specific parties at specific points in that chain. Getting the contracts right is the prerequisite to getting the document right; getting the document right without the contracts is, at best, a temporary arrangement.
§ 06What the SBOM obligation is really for
The engineering manager from the start of this essay is, by the time he understands the situation, looking at something larger than a two-week deliverable. He is looking at the visible portion of a years-long supply-chain restructuring exercise. The SBOM the European customer asked for is not the work. The work is becoming the kind of company that can produce the SBOM honestly — a company with contractual leverage on its component suppliers, with internal release processes that gate on SBOM generation, with archives that support version-specific retrieval, with vulnerability-handling pipelines that traverse the SBOM rather than guess about it.
The CRA, read at its most demanding, asks APAC manufacturers to make a transition that the European market has been moving toward, on its own, for a decade. That transition is from being an opaque assembler of components into a defined product, to being an explicable owner of a supply chain that someone else can audit. The transition is unglamorous. It involves contractual conversations with suppliers who have not historically had to answer these questions, internal process changes in release engineering, archive infrastructure that did not previously exist, and budget allocations that were not previously needed.
It is also, for APAC industrial manufacturing in particular, a structural upgrade. The companies that complete this transition will be measurably more capable than they were before — not just in CRA-compliant ways, but in ways that show up in customer trust, in incident response time, in the speed of integrating into critical-infrastructure procurement processes, in the simple ability to answer the question “what is in this product” in less than a day. The companies that do not complete the transition will, increasingly, be unable to ship into the European market at all.
The SBOM the European customer asked for is the readout. The work it forces is the becoming.