An EN 18031 certificate is not quite the same as having an SBOM — they are different obligations under the Cyber Resilience Act
From the Cyber Resilience Act’s legal text and the prEN 40000 drafts to penalties and timelines — the SBOM obligation, broken down in one read.
Earlier in this series we covered the four-step test: confirming whether your product falls within CRA scope. That is only the starting point — the real homework is the series of concrete obligations that follows: risk classification, conformity assessment and module selection, reporting obligations, and the subject of this article, the SBOM.
The SBOM deserves an article of its own because it is not a one-off checklist item. It is a continuous obligation that spans the product’s entire support period and keeps reappearing across several different provisions and draft standards. When manufacturers first hear “the CRA requires an SBOM”, the instinctive reaction is often “haven’t we already done something like that?” — and that is exactly where mistakes are easiest to make.
The CRA’s essential requirements come in two parts. Annex I, Part I is about whether the product itself is designed securely enough — encryption, access control, secure default configuration and so on. Part II is about whether, once the product is on the market, the manufacturer is capable of handling vulnerabilities on an ongoing basis. The SBOM is written into the second part. Its role is not “making the product more secure” but “providing the baseline data that vulnerability handling can be matched against” — without an SBOM, there is no way to determine whether a newly disclosed vulnerability affects your product.
So the SBOM is part of the CRA’s vulnerability-handling obligations — not something you finish once, but something to be maintained and updated with every revision throughout the product’s support period. It follows that a manufacturer holding EN 18031 / RED certification who believes they “already have an SBOM” is covered only for Annex I, Part I (the product-property cybersecurity requirements); that certification does not touch Annex I, Part II (the vulnerability-handling requirements).
The legal basis for the SBOM is Annex I, Part II (Vulnerability handling requirements), item (1) of Regulation (EU) 2024/2847. The provision (in close translation) reads:
“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.”
Besides being a continuous vulnerability-handling obligation, the SBOM also appears within the scope of the technical documentation (Article 31, Annex VII) — the technical documentation must include the product description, risk assessment, the basis for determining the support period, test reports and so on, and “where applicable” the SBOM as well; the technical documentation and the SBOM must be kept, under Article 13, for at least 10 years or the support period, whichever is longer.
The CRA text itself states only the principle (“draw up a machine-readable SBOM covering at least the top-level dependencies”). How to actually do it depends on the draft harmonised standards still being written — the prEN 40000 series. The SBOM currently appears in two of the drafts, playing a different role in each:
prEN 40000-1-2 corresponds to CRA Annex I Part I (product-property requirements) and deals with general principles across the product-development lifecycle. The SBOM appears in two places:
This draft stays at the level of principle: the SBOM is a fixed step in the secure-development process, and third-party components must always be brought under management.
The document that truly spells the SBOM out — down to a level that can be audited clause by clause — is prEN 40000-1-3, which corresponds to CRA Annex I Part II. Its section 5.3.8, “[PRE-7] Identification of software components”, is devoted entirely to the SBOM.
The essentials come down to three things:
A summary of PRE-7-RQ-01 through 07 and the enhancement requirements is provided in the appendix at the end of this article for readers who want to dig deeper.
A reminder: prEN 40000-1-3 is still at the Draft for Public Comment stage (as of our verification, voting had closed but progression to Formal Vote was not yet confirmed, and it has not been published in the Official Journal of the EU). Clause numbers and content may still change before final adoption, and the draft cannot serve as a final basis of compliance. But because the underlying legal obligation comes from Annex I Part II of the Regulation itself, changes to the draft do not affect the answer to “is an SBOM necessary?” — only the details of “what counts as doing it right”.
The SBOM is an obligation requiring continuous maintenance — so what happens if you fail it? Violations of the Annex I essential requirements (including the Part II SBOM requirement) and of the Article 13 and 14 obligations carry administrative fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64) — the highest tier in the CRA’s penalty structure. The SBOM may sound like just a list, but in legal position it sits under the same penalty tier as product-property requirements like encryption and access control.
On the timeline, two dates deserve particular attention — and the gap between them is precisely where most manufacturers misjudge how much preparation time they have:
Here is the problem: meeting Article 14’s 24-hour / 72-hour reporting deadlines in practice depends on an SBOM to answer “is our product affected?” in time. In other words, although the SBOM formally takes effect as an Annex I requirement on 11 December 2027, the data needed to support the reporting obligation that takes effect on 11 September 2026 is exactly this SBOM. That is a gap of more than a year — wait until late 2027 to start preparing, and you will find the reporting obligation has already been live for over a year without the underlying data to support it.
Misconception 1: “We already have RED / EN 18031 certification, so the SBOM should be covered.” The EN 18031 trilogy (network protection, privacy protection, protection from fraud in financial transactions) corresponds to the RED’s security requirements, which are close in nature to CRA Annex I Part I (product-property requirements) — and contain nothing at all on software-component identification or SBOMs. The SBOM belongs to Annex I Part II (vulnerability-handling requirements). These are two different categories of obligation: your existing EN 18031 investment does not automatically cover the SBOM, which needs to be planned separately.
Misconception 2: “EN 40000 isn’t officially published yet, so we don’t need to prepare the SBOM yet.” Harmonised standards are only one route for demonstrating compliance (the presumption of conformity). The SBOM’s legal obligation comes directly from Annex I Part II of the Regulation itself, and whether the standard has been published in the Official Journal has no bearing on when the underlying legal obligation takes effect. More to the point, the Article 14 reporting obligations take effect on 11 September 2026 — in practice you need SBOM support well before the standards are finalised and well before full application at the end of 2027.
Misconception 3: “One SBOM covering top-level dependencies is enough.” The baseline requirement (PRE-7-RQ-03) indeed only demands top-level dependency coverage, but the draft already contains enhancement requirements calling for transitive dependencies to be covered where technically feasible — and a fresh SBOM should be generated for every new version and every new build. Whether an enhancement requirement applies is decided by the manufacturer based on its own product risk; it is not an automatic exemption. We recommend assessing this early rather than discovering at audit time that the baseline version is not enough.
The fact that the draft standards are still moving does not mean the SBOM can be pushed down the list. A more pragmatic ordering is:
If you have confirmed that your product falls within CRA scope but are still unsure how deep your SBOM needs to go or which format to target, or would like professional review of your overall CRA readiness, feel free to contact us — our consultants can help assess your specific case.
You are also welcome to join the in-person seminar in Taipei on Friday 18 September, where you can put questions directly to a CRA expert from Spain and learn more about planning for 2027 compliance and estimating the time and cost of implementation. Registration: Register for the seminar
prEN 40000-1-3 PRE-7 — the SBOM requirements, clause by clause (Identification of software components)
| Clause | What it requires (in plain language) |
|---|---|
| PRE-7-RQ-01 | All software components contained in the product shall be identified and documented. |
| PRE-7-RQ-02 | For each component, record at minimum: the software manufacturer, the component name, and the component version. |
| PRE-7-RQ-03 | An SBOM shall be drawn up covering at least the product’s top-level dependencies — this is the baseline threshold. |
| PRE-7-RQ-03-RE (enhancement) | Where technically feasible, all software components (not just top-level) shall be included in the SBOM, so that transitive dependencies can be detected. |
| PRE-7-RQ-04 | The SBOM shall be produced in a structured, machine-readable format (e.g. SPDX, CycloneDX). |
| PRE-7-RQ-05 | When a software component has a new version or a new build, a new SBOM shall be created to reflect it. |
| PRE-7-RC-01 (recommendation) | When new information about an existing component is discovered, or an SBOM error needs correcting, a revised SBOM should be published. |
| PRE-7-RQ-06 | SBOM metadata shall include: author, version, and timestamp. |
| PRE-7-RQ-07 | Beyond the basic information, each component shall include its dependency relationships and a unique identifier (e.g. CPE, PURL, SWHID). |
| PRE-7-RQ-07-RE (enhancement) | Where the supplier provides component hash values and the corresponding algorithm, they shall be included in the SBOM. |
Two practical details matter here. First, the two items marked “RE” (Requirement Enhancement) — transitive-dependency coverage and hash values — do not apply automatically. Under [APP-1-RQ-01], “the applicability of each enhancement requirement shall be determined according to product risk”: the manufacturer decides, based on its own product’s risk-assessment outcome, whether that depth is needed. Second, PRE-7 also surfaces upstream in the vulnerability-handling process — for example, [PRE-1-RQ-04] requires “a mapping of upstream dependencies, including open source, to support coordination and notification activities so that issues can be resolved in a timely manner” — which shows the SBOM is not a static document but the foundational data underpinning the whole vulnerability-response process.
One addition: the CRA text and the mandatory PRE-7 requirements are locked onto software components, but prEN 40000-1-3 notes that, where technically feasible, hardware components may also be included in the SBOM to make dependency tracing more complete. This is not a legal minimum — it is a value-added practice.
Q: How deep does the CRA’s SBOM have to go? The regulation requires a commonly used, machine-readable format (such as SPDX or CycloneDX), covering at least the product’s top-level dependencies; transitive dependencies may be added where technically feasible (an enhancement requirement, decided by the manufacturer based on risk). A corresponding SBOM should be regenerated for every new version and every new build.
Q: We have EN 18031 certification — does that mean we already have an SBOM? No. EN 18031 corresponds to the product-property requirements (Annex I Part I), while the SBOM is part of the vulnerability-handling obligations (Part II) — two different parts of Annex I. The technical work behind an existing certification can carry over, but the CRA’s SBOM still needs to be established separately.
Q: How long must the CRA SBOM and technical documentation be kept? Under Article 13 and Annex VII, the technical documentation (including the SBOM where applicable) must be kept for at least 10 years, or the product’s support period, whichever is longer.
The legal provisions and dates cited in this article are based on the following documents:
By the Secure Vectors Surveillance Inc. (SV Surveillance) × Applus+ Laboratories consulting team
* This article is regulatory commentary, not legal advice. As of writing, the prEN 40000 series remains a Draft for Public Comment, has not been published in the Official Journal of the EU, and its clause numbers and content may change before formal publication. Final compliance determinations for specific cases remain subject to official EU documents and the interpretations of the competent authorities.
