EU CRA SBOM Requirements: The Continuous Component Inventory Security Teams Need
EU CRA SBOM: the facts
Short version: Trent can help you produce your SBOM and keep it current as you ship.
Two EU regimes now ask product security teams for a component inventory. The EU Cyber Resilience Act (EU CRA, Regulation (EU) 2024/2847) asks manufacturers for a software bill of materials as part of vulnerability handling. DORA asks financial entities to track the third-party libraries inside the ICT services they run. Different actors, different duties, different dates. The same inventory, if it is built once and kept current, can serve both.
Our article fits security engineers, PSIRT leads, and security directors at companies of 200 people and up, including financial entities under DORA. We answer four questions the EU CRA SBOM discussion keeps skipping:
- Do we need an SBOM by 11 September 2026?
- Which product is the unit of inventory?
- How deep does the inventory go, and how current must it be?
- What goes in the supplier contract?
This is engineering guidance, not legal advice. Commission guidance C(2026) 5252 is the interpretive reference used here.
What the EU Cyber Resilience Act says about the SBOM
The CRA SBOM requirements are one sentence long. Annex I, Part II, point (1) requires manufacturers to:
identify and document vulnerabilities and components contained in products with digital elements, 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 products;
Article 3(39) defines the term: a software bill of materials “means a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements.”
Three points follow from the text.
It is a process duty, not a product label. The SBOM belongs to the vulnerability-handling process. Annex VII point 2(b) puts it in the technical documentation, which must include “necessary information and specifications of the vulnerability handling processes … including the software bill of materials”. Annex VII point 8 adds that the file holds, “where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority provided that it is necessary … to check compliance”. The SBOM sits in your technical file, and an authority can ask you for it.
It does not have to be public. Recital 77 states: “Manufacturers should not be obliged to make the SBOM public.” Annex II point 9 applies only if you choose to share: “If the manufacturer decides to make available the software bill of materials to the user, information on where the software bill of materials can be accessed.”
No format is named. Article 13(24) says the Commission “may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials referred to in Part II, point (1), of Annex I.” That is a “may”. As of 28 September 2026 no such act has been adopted, and none has appeared as a draft. Implementing Regulation (EU) 2025/2392, which some vendor blogs cite as the SBOM act, describes important and critical product categories and says nothing about SBOM format. The Commission’s CRA FAQ has no SBOM entry. The Commission has asked the European standards bodies for harmonised standards, but a harmonised standard is not the Article 13(24) act. If your internal policy names a format, that is your choice, not the regulation’s.
The SBOM is not required by 11 September 2026. The SBOM duty is an essential requirement in Annex I Part II of the regulation, and Part II applies from 11 December 2027 under Article 71(2). What starts on 11 September 2026 is Article 14 reporting, the 24-hour reporting duty for actively exploited vulnerabilities and severe incidents. Reporting is a different duty and needs no SBOM, though a team that already knows which components sit in which product will file faster.
One more date question comes up in every PSIRT planning session: products already on the market. Article 69(3) reaches only products placed on the EU market before 11 December 2027, and it extends the reporting duty to them. Per Commission FAQ 5.3 and C(2026) 5252 paragraph 210, Part II vulnerability handling, SBOM included, is not required for unmodified units placed before that date. A substantial modification changes that answer.
What DORA expects from the same inventory
DORA does not require an SBOM. The word does not appear in Regulation (EU) 2022/2554 or in its technical standards. What DORA requires is library tracking, and the rule sits in the delegated regulation, not in DORA itself.
Delegated Regulation (EU) 2024/1774, Article 10(2), point (d), point (i), says the vulnerability management procedures of a financial entity shall:
track the usage of: (i) third-party libraries, including open-source libraries, used by ICT services supporting critical or important functions;
The follow-on text adds that financial entities shall, where appropriate with the ICT third-party service provider, “monitor the version and possible updates of the third-party libraries.” For off-the-shelf ICT assets that support functions which are not critical or important, the duty softens: they “shall track the usage to the extent possible of third-party libraries, including open-source libraries.”
Two citation traps sit here. First, “DORA Article 10” is protection and prevention in Regulation 2022/2554; the library rule is Article 10 of Delegated Regulation 2024/1774. Second, DORA Article 8 is often quoted as the library inventory. It is not. Article 8(1) asks financial entities to identify, classify and document ICT-supported business functions, information assets and ICT assets, with their roles and dependencies, reviewed at least yearly. Article 8(4) asks for all information and ICT assets, mapped, with “the links and interdependencies between the different information assets and ICT assets.” Article 8(5) covers processes that depend on ICT third-party service providers. Article 8(6) says the entity shall “maintain relevant inventories and update them periodically and every time any major change as referred to in paragraph 3 occurs.” Libraries appear only in the delegated regulation.
A third trap: the Article 28 register of information. That register lists contractual arrangements with ICT third-party service providers. It is a register of contracts and services, never the library list.
The CRA duty falls on the manufacturer placing a product on the market. The DORA duty falls on the financial entity running the service. A component list built to the CRA floor is a good input to DORA tracking, but if you are the financial entity you must still track the libraries in the services you actually run, including the vendor’s product as deployed.
That creates a buyer-side gap. Banks report receiving “applications, modules” from core vendors, not open-source libraries (American Banker, August 2026). A supplier’s SBOM feeds a financial entity’s tracking but does not do that tracking for it, and the CRA does not require the manufacturer to ship the SBOM to customers. The financial entity has to ask for it. On the manufacturer’s side, due diligence on integrated components is Commission FAQ 4.4; it does not create a duty to hand the list downstream.
Which product is the unit of inventory
Unit comes before depth. You cannot decide how deep to go until you can say what “the product” is, and if you run microservices that is the harder question.
Article 3(1) of the CRA defines a “product with digital elements”. It does not say how to aggregate services, containers or repositories into one product for SBOM purposes. Commission guidance C(2026) 5252 adds one useful rule: variants that differ in the components they include are not the same product. Beyond that, no authority has published an aggregation rule, and nobody has confirmed what a market surveillance authority will ask for: one aggregated product SBOM, or a tree of linked per-service BOMs.
Our reading, flagged as ours: one product placed on the market, one body of SBOM evidence, assembled from per-service or per-container BOMs. Build the small BOMs where the code lives; assemble them where the product is defined. That keeps the evidence honest.
The practical sub-questions, with the answer that follows from that reading:
| Question | Answer under the “one product, one body of evidence” reading |
|---|---|
| Which SKU? | The unit is what you place on the market under one name and one EU declaration of conformity. Two SKUs with different component sets are two products (C(2026) 5252). |
| Who signs the declaration of conformity? | The manufacturer of that product. The signer’s product boundary is the SBOM boundary. |
| Release or every build? | The SBOM in the technical file describes what shipped. Rebuild per release at minimum; per-build BOMs are useful evidence but are not what the law asks for. |
| SaaS and on-prem variants? | If the on-prem variant includes components the SaaS variant does not, treat them as different products for the SBOM (C(2026) 5252). |
Standalone SaaS is generally outside the CRA product rules (Recital 12; Commission FAQ 1.2), while remote data processing that a product depends on is in scope. Whether a SaaS operator owes DORA library tracking depends on whether it is a financial entity or an ICT third-party service provider to one. Whether it owes NIS2 duties depends on whether it is an essential or important entity. None of those are automatic; each is a scoping call your team must make and write down.
How deep, and how current
The legal floor is the top level. Annex I Part II point (1) says “at the very least the top-level dependencies.” It does not say all transitive dependencies, and no EU authority has published a depth test that goes further.
The benchmark most European teams use is Germany’s BSI TR-03183-2, version 2.1.0, dated 20 August 2025. It is a national technical guideline. BSI’s own page says it is not binding and does not give presumption of conformity under the CRA. Its depth rule is a path rule: resolve each dependency path recursively up to and including the first component outside the scope of delivery. BSI defines a “top-level SBOM” as one level deep and says one level cannot support vulnerability handling. It asks for JSON or XML, in CycloneDX 1.6 or later or SPDX 3.0.1 or later. Those format names come from BSI and market practice, not from the regulation.
The US pull runs deeper. CISA’s 2026 Minimum Elements ask for all components including transitive dependencies and set “no minimum depth”, which means no cap on how far down the list goes, not a shallower baseline. It is US guidance and non-binding in the EU, but if you sell on both sides of the Atlantic, you will feel it.
The recommendation: treat the top level as the floor the law names, adopt the BSI path rule as your working practice, and never write into an internal policy that the regulation mandates transitive depth, because it does not.
Vulnerability data stays out
An SBOM lists components. It does not list vulnerabilities. BSI TR-03183-2 section 3.1 says the SBOM must not contain vulnerability information; keep your exploitability data beside it, as VEX or CSAF, and note that BSI prefers CSAF. The CRA requires neither.
What an SBOM cannot say
An SBOM cannot say whether the vulnerable function is ever called. A vulnerable library in the list is a question, not a finding. Answering it needs reachability analysis and threat modeling of the paths that reach the component. Start there once the list exists.
False positives cost more than time
Every false alarm teaches developers to ignore the next one. Trent checks each finding against how your application actually works before it reaches them.
Keep it current
A list made for the audit is stale on export. The SBOM exists to support vulnerability handling, and a static file stops doing that once the next release ships. ENISA’s SBOM adoption survey, June 2026, shows how far most teams are from a current list: 62% rate a high degree of SBOM completeness as “quite a lot or extremely difficult”, and 28% still use non-standard formats. Rebuild your inventory at every release at minimum, from the lockfile or the image, and keep the previous versions so you can answer “which shipped versions contain this component” on the day a vulnerability lands.
AI-selected packages
If a coding assistant picked the package, resolve your component list from the lockfile or the image, not from the prompt or the assistant’s transcript. A package with a hallucinated name that an attacker has since registered exists at its recorded source, so checking that a package exists is not the same as trusting it. The Cloud Security Alliance documented this “slopsquatting” pattern in May 2026. The CRA has no AI-package rule.
What one component record holds
Depth decides how many records you keep. Currency decides how often you rebuild them. This is what each record holds, whether your own build produces it or a supplier sends it. The file format is a publish-day question, because the Article 13(24) act has not settled it; the fields are not.
| Field | Why it is there |
|---|---|
| Name | The identifier the supplier uses; package name or module path |
| Type | Library, runtime, container base, firmware blob |
| Version | The exact resolved version, not a range |
| Vendor or supplier | Who maintains it; “community” is a valid answer if named |
| Transitive note | Whether it is a direct or transitive dependency, and of what |
| System grouping | Which service or container of the product pulls it in |
| Evidence | A lockfile line, manifest entry, or image layer that proves the version |
| Timestamp (for the SBOM as a whole) | When the list was produced; the time of the scan is enough |
| Creator (for the SBOM as a whole) | Who produced the list; the person who ran the scan |
BSI TR-03183-2 also expects a hash for each component. Your scan may not produce one, so you may need to source component hashes from other systems.
What to ask a supplier for
Your supplier clause is short.
- A component list with the fields above, versions included, refreshed at each release of the supplied software.
- Machine-readable, in a commonly used format; name one in the contract so the argument happens before delivery.
- A named contact for the list, so a question about a component reaches a person.
- A statement of coverage gaps: which parts of the delivery the list does not describe, and why.
If you are the manufacturer, that list feeds your technical file. If you are the financial entity, it feeds your Article 10(2)(d)(i) library tracking.
Where Trent supports the inventory
Trent’s inventory can contribute component evidence to this work. Trent can create an SBOM from many different sources like code, design documents, etc.
The boundary, as observed on 9 September 2026: no CVE or KEV matching; transitivity noted in the component description, not drawn as a tree; on the two projects we have observed, components appeared where a lockfile or manifest existed, and coverage on a project without one is unconfirmed. The technical documentation, the DORA register of information, the legal scoping and the conformity assessment stay with the manufacturer or the financial entity.
Two things to do this month
Write down the product unit. One page: the name on the declaration of conformity, the services and containers inside it, the variants that differ in components. Every depth and supplier decision hangs off that page.
Then get one supplier’s component list under contract, with versions, a refresh at each release, a named contact and a coverage statement.
If the component inventory is the missing piece, Request access to Trent. You can also Book a demo.
Reviewed by Julien Brouchier, Security Engineer at Trent AI and Eno Thereska, Co-founder & CEO at Trent AI
FAQ
Is an SBOM required by 11 September 2026 under the EU Cyber Resilience Act?
No. The SBOM duty is an Annex I Part II essential requirement and applies from 11 December 2027 under Article 71(2). The date of 11 September 2026 starts Article 14 reporting for actively exploited vulnerabilities and severe incidents. Reporting is a separate duty and does not require an SBOM, though a current component inventory makes the 24-hour early warning easier to scope.
Does the SBOM have to be public?
No. Recital 77 states that manufacturers should not be obliged to make the SBOM public. The SBOM lives in the technical documentation (Annex VII point 2(b)), and a market surveillance authority can request it on a reasoned basis (Annex VII point 8). If you choose to share it with users, Annex II point 9 only requires saying where it can be accessed.
Which SBOM format does the EU Cyber Resilience Act require?
None. The regulation asks for “a commonly used and machine-readable format” and names no standard. Article 13(24) lets the Commission specify format and elements by implementing act, and as of 28 September 2026 no such act exists. CycloneDX and SPDX come from BSI TR-03183-2 and market practice. ENISA’s June 2026 survey found 44% of respondents using CycloneDX and 29% SPDX.
Does DORA require an SBOM?
No. DORA never uses the word. Delegated Regulation (EU) 2024/1774, Article 10(2)(d)(i), requires financial entities to track the usage of third-party and open-source libraries in ICT services supporting critical or important functions, and to monitor their versions and updates. An SBOM is one way to do that tracking, not the duty itself.
