Does the ENISA SBOM advisory add new CRA requirements?

No. The ENISA Technical Advisory for Software Bill of Materials, published October 2026, creates no legal obligation and defines no new SBOM fields. The CRA duty stays Annex I Part II(1), a machine-readable SBOM covering at least top-level dependencies.

The advisory still matters. It is the first ENISA document that describes how an SBOM should be produced, protected and kept current, and it reached its final form after a review by the SBOM workstrand of the CRA Expert Group. Market surveillance authorities and notified bodies will read it. A technical file that already follows it answers questions before they are asked.

Key takeaways

• The ENISA SBOM advisory is guidance for organisations at an early stage of SBOM adoption, and by its own terms it is not a legal interpretation of the Cyber Resilience Act.
• Table 1 of the advisory maps BSI TR-03183-2 onto the CISA 2026 Minimum Elements and adds no third field set, so no SBOM can "fail ENISA" on fields.
• The new material is process, with a seven-phase lifecycle from build to maintenance, 25 STRIDE threats, ten general risks and seventeen security controls.
• Four recommended practices show in the SBOM file itself, which are a signature, a hash that binds the SBOM to the artifact, declared known unknowns and the SBOM type.
• The ENISA survey behind the advisory found that 27 percent of organisations need SBOMs with declared known unknowns, and only 12 percent receive them.

What is the ENISA SBOM Technical Advisory?

The ENISA Technical Advisory for Software Bill of Materials is a 31-page guidance document from the EU Agency for Cybersecurity, published in October 2026 under CC BY 4.0 (doi 10.2824/2077129). It is written for micro, small and medium enterprises and for open-source stewards who are setting up their first SBOM capability.

The document has a short history. ENISA ran a call for feedback from 17 December 2025 to 23 January 2026 on a draft called "SBOM Landscape Analysis: Towards an implementation guide" and received 67 contributions. The survey results in the ENISA SBOM Adoption State of Play 2026, published on 9 June 2026, then pushed the draft from a landscape analysis to a technical advisory. Experts in the SBOM workstrand of the CRA Expert Group reviewed it between 31 July and 11 September 2026.

The scope is deliberately narrow. The advisory covers software bills of materials only. AI bills of materials, hardware bills of materials and cryptographic bills of materials are out of scope. It is sector-agnostic, and it does not give a maturity model.

Does the advisory change which fields an SBOM must contain?

No. Section 2.1.1 of the advisory puts the BSI TR-03183-2 data fields next to the CISA 2026 Minimum Elements and stops there. ENISA lists no field that appears in neither document, and it does not choose between them.

That leaves four layers that a manufacturer selling in the EU meets in practice. Only the first one is law.

Layer	Status	Format rule	What it asks for
CRA Annex I Part II(1)	EU law, applies from 11 December 2027	"Commonly used and machine-readable"	Components, at least the top-level dependencies
BSI TR-03183-2 v2.1.0	German federal technical guideline	CycloneDX 1.6 or SPDX 3.0.1 as a minimum	Fixed SBOM and component fields, SHA-512 hashes, file properties
CISA 2026 Minimum Elements	International guidance, 17 partner agencies	SPDX or CycloneDX, no version floor	17 data fields and 6 practices, transitive coverage
ENISA SBOM Technical Advisory	EU agency guidance, non-mandatory	CycloneDX or SPDX recommended	No fields of its own. Lifecycle, threats, risks and controls

The field mapping in Table 1 also shows where BSI and CISA disagree. BSI asks for an SBOM URI, the component filename and three file properties (executable, archive, structured), which CISA does not ask for. CISA asks for the SBOM version, the format name and version, the author signature, the tool name and version, the generation context and the hash algorithm, which BSI does not list. A file built for one of the two will usually miss something the other expects. We explain the CISA side in what changed in the 2026 Minimum Elements.

What does the advisory add?

The advisory adds a lifecycle, a threat model and a set of controls. Most of that content describes the pipeline that makes the SBOM, not the SBOM file.

Content	Where in the advisory	Size
SBOM lifecycle	Section 2.2.1, Figure 1	7 phases, from build to maintenance and update
CI/CD reference architecture	Section 2.2.2, Figure 2	Fail-and-alert gates after build, generation, validation and signing
Open-source tool stack	Section 2.2.3, Table 4	Tools for generation, validation, signing, storage and consumption, per format
SBOM threat model	Section 3.1, Table 5	25 threats across the six STRIDE categories
General risks	Section 3.2, Table 6	10 risks with mitigations
Pipeline integration	Section 4.1, Figure 3	6 steps, two integration patterns
Security controls	Section 4.2, Table 7	17 controls mapped to lifecycle phases

The seven lifecycle phases

The lifecycle starts at phase 0, the build, and runs through generation, validation, cryptographic signing, storage and consumption to maintenance and update. ENISA names four principles for the result. The SBOM must be continuous, trustworthy, actionable and up to date.

Phase 6 is the one most pipelines skip. ENISA lists seven triggers that should start a new SBOM. They are a new build, a new release, a dependency update, a security patch, an operating system package update, a library addition or removal, and a build configuration change. A firmware team that regenerates the SBOM only for a major release misses five of the seven.

The six SBOM types

ENISA adopts the CISA SBOM types, which classify an SBOM by the development phase in which it was made. The type tells a consumer what the SBOM can show and what it cannot.

SBOM type	Made from	Typical use	CycloneDX metadata.lifecycles	SPDX 3 software_sbomType
Design	The planned architecture	Licence planning, threat modelling	design	design
Source	Source files and manifests	Early vulnerability detection	pre-build	source
Build	The build process	Regulatory compliance, vulnerability assessment	build	build
Analysed	Analysis of a finished artifact	Provenance, supplier risk, third-party review	post-build	analyzed
Deployed	The installed system	Asset inventory, patch management	operations	deployed
Runtime	Instrumentation of the running system	Threat detection, attack surface	operations	runtime

CycloneDX has one phase, operations, for inventory that is running, so a CycloneDX file cannot tell a Deployed SBOM from a Runtime SBOM. The CycloneDX phases discovery (network discovery) and decommission have no CISA type.

For a technical file under the CRA, the Build SBOM is the usual anchor, because it lists what the manufacturer actually shipped. An Analysed SBOM from a binary scan is a useful cross-check, but heuristics can add components that are not there and miss components that are. Table 6 lists that as its own risk, "Insufficient SBOM Accuracy".

Which ENISA practices can one SBOM file show?

Four of the recommended practices leave a trace in the SBOM document. Everything else in the advisory is a property of the pipeline, and a file cannot prove it.

Practice	Where ENISA recommends it	What the file can show	What the file cannot show
Cryptographic signature	Lifecycle phase 3, Table 5 tampering threats	An embedded CycloneDX JSF signature	Whether the signature is valid. A detached Cosign or Sigstore signature is not in the file
Binding to the artifact	Table 6 "Weak SBOM-to-Artifact Binding", Table 7 "Artifact Binding"	A hash or digest on the component the SBOM describes	Whether the hash matches the shipped artifact
Declared known unknowns	Table 6 "Incomplete SBOM", section 4.1.2	CycloneDX compositions with an aggregate, SPDX relationship completeness	Whether the parts declared complete really are
SBOM type	Section 2.1.3, Table 3	CycloneDX metadata.lifecycles, SPDX 3 software_sbomType	Whether the stated phase is correct

The known unknowns practice deserves the most attention, because the survey gap is widest there. In the ENISA SBOM Adoption State of Play 2026, 27 percent of respondents said they need SBOMs with depth analysis that declares known unknowns, and only 12 percent said they receive them. A declaration such as "first-party components complete, third-party components incomplete" turns a silent gap into a stated one. A reviewer can work with a stated gap.

Format support is uneven. SPDX has no field for an embedded document signature, so SPDX files are signed outside the file. SPDX 2 has no field for the SBOM type, which arrived with SPDX 3. CycloneDX added metadata.lifecycles in version 1.5, so a CycloneDX 1.4 file cannot declare its type at all.

Why does ENISA treat the SBOM as an attack surface?

The threat model covers the whole SBOM ecosystem, not only the document. Six of the 25 threats are information disclosure, and they share one mitigation, controlled sharing with access control.

STRIDE category	Threats	Example from Table 5
Spoofing	6	A malicious tool generates an SBOM that appears to be valid
Tampering	5	PURLs or CPEs are altered, so vulnerability matching runs against the wrong component
Repudiation	2	The producer denies having distributed an SBOM
Information disclosure	6	Exact versions make it faster to map the product to known CVEs
Denial of service	3	A very large or deeply nested SBOM exhausts the parser
Elevation of privilege	3	A compromised signing infrastructure makes a malicious SBOM look trusted

The disclosure threats answer a question we hear often, whether the CRA forces a manufacturer to publish the SBOM. It does not. Annex II point 9 asks only for information on where to access the SBOM, if the manufacturer decides to make it available to users. A manufacturer can keep the SBOM in the technical file and share it under access control with customers and authorities, which is what the ENISA mitigation describes.

The denial of service threats apply to every SBOM consumer, including us. A validator that accepts uploads has to cap size and nesting depth, or a hostile file takes it down. Our public validator limits files to 5 MB for that reason.

What do the survey numbers say about SBOM practice today?

The advisory quotes the ENISA SBOM Adoption State of Play 2026 throughout. The figures below come from that survey as the advisory reports them. The survey method is described in the ENISA publication.

Finding	Share of respondents
Use CycloneDX or SPDX	73 percent
Aim to fully automate SBOM generation for each release or build	41 percent
Expect to fully automate SBOM updates across the support period	26 percent
Rely on open-source SBOM tools	33 percent
Need all primary components and direct dependencies with declared known unknowns, and receive them	36 percent need, 29 percent receive
Need full-depth SBOMs, and receive them	24 percent need, 14 percent receive
Need full-depth SBOMs with declared known unknowns, and receive them	27 percent need, 12 percent receive

The gap between generation and maintenance is the number to watch. The CRA vulnerability handling duties run for the whole support period, so an SBOM that is correct on release day and never updated becomes wrong at the first dependency patch. Table 6 names this risk "Outdated SBOM", and Annex I Part II(1) does not stop at the release date.

What should a manufacturer do with the advisory?

Start with the four practices that show in the file, because they cost the least and a reviewer sees them first. Then work through the pipeline controls in the order of the lifecycle.

1. Declare the SBOM type. Set metadata.lifecycles in CycloneDX 1.5 or later, or software_sbomType in SPDX 3. For the technical file this is usually build.
2. Declare what you do not know. Add CycloneDX compositions with an aggregate value such as incomplete_third_party_only, or set completeness on SPDX 3 relationships. A statement of a gap is better than silence.
3. Bind the SBOM to the artifact. Put a hash of the shipped artifact on the primary component, or reference a container image by digest. The CRA does not fix a hash algorithm. BSI TR-03183-2 asks for SHA-512 on components.
4. Sign it, and keep the signature with it. An embedded JSF signature in CycloneDX travels with the file. A detached Cosign or Sigstore signature is stronger in many pipelines, but it has to be stored and shipped next to the SBOM, or the binding is lost.
5. Regenerate on the seven triggers. Wire SBOM generation to dependency updates and security patches, not only to releases. Retain each version per release, with the build identifier, the artifact digest, the signature and any VEX documents. Table 6 lists missing retention as its own risk.
6. Combine the SBOM with VEX. Table 6 lists "Lack of vulnerability prioritization" as a risk and points to VEX for exploitability and reachability. We explain when the CRA needs VEX in do you need VEX documents for CRA compliance.

Steps 1 to 4 change the SBOM file. Steps 5 and 6 change the process around it, and they are where the CRA support-period duty is met.

How can you check an SBOM against the four practices?

The free SBOM validator checks a CycloneDX or SPDX JSON file against four frameworks in one run. It runs in the browser, and the file is not uploaded or stored.

Section	What it reports	Score
CRA Annex I Part II(1)	Format, components, top-level dependencies, with an optional manifest check	Verdict of meets, does not meet, or cannot confirm
BSI TR-03183-2 v2.1.0	Format version floor and required fields	Required fields present, out of the total
CISA 2026 Minimum Elements	17 data fields and 6 practices	Assessable fields present, out of the assessable total
ENISA SBOM advisory	The four practices in this article	No score

The ENISA section has no score because the advisory defines nothing to score against. Each practice shows as observed, not observed, or not assessable from the format. A missing practice is never shown as a failure, because the advisory is non-mandatory. The checks report presence only. The validator does not verify a signature and does not compare a hash with the artifact, and every result says so.

CVD Portal runs the BSI and CISA checks on every SBOM uploaded to the platform and monitors each component against OSV and the EU Vulnerability Database. For a broader view of where the SBOM sits in the CRA work, see SBOM as a security foundation.

Primary sources

• ENISA Technical Advisory for Software Bill of Materials, October 2026, CC BY 4.0. Tables 1 to 7 and Figures 1 to 3 as cited above.
• ENISA SBOM Adoption State of Play 2026, published 9 June 2026. The source of the survey percentages.
• Regulation (EU) 2024/2847, the Cyber Resilience Act, CELEX 32024R2847. Annex I Part II(1) and Annex II point 9.
• BSI TR-03183-2 v2.1.0, Cyber Resilience Requirements for Manufacturers and Products, Part 2, Software Bill of Materials.
• CISA 2026 Minimum Elements for a Software Bill of Materials, version 2.1.