ENISA's SBOM advisory: what it asks beyond the CRA, and what app teams should do
· 5 min read · CRA news
In short: on 22 October 2026 ENISA published a Technical Advisory on Software Bills of Materials. It is non-binding, written for small companies new to SBOMs, and goes further than the CRA text does.
- This is not breaking news: it is three weeks old, and we had not covered it yet. It matters because SBOMs are a CRA documentation duty.
- ENISA recommends generating the SBOM at build time in CI, in SPDX or CycloneDX, signing it and tying it to the exact artifact.
- It says it is not a legal interpretation of the CRA. Treat it as a good-practice target, not a checklist for conformity.
- It does not discuss mobile apps or app stores, so the mapping to apps is ours.
What ENISA published
The ENISA Technical Advisory for Software Bill of Materials appeared on 22 October 2026. ENISA describes it as hands-on guidance for organisations, especially micro, small and medium-sized enterprises, that are starting to use SBOMs. According to the document, it follows a call for feedback that drew 67 contributions and a review by the CRA Expert Group. It covers an SBOM life cycle, a threat model for the SBOM pipeline and measures to secure it. It leaves out AI, hardware and cryptographic bills of materials.
Its status matters. The advisory says its recommendations are non-mandatory, create no legal obligations, and should not be read as a legal interpretation of the CRA. It also says some of its practices may go beyond what the regulation requires.
What the CRA itself says about SBOMs
The legal text is short. As reproduced on cyberresilienceact.eu (the EUR-Lex text is the authentic version), Annex I, Part II, point (1) asks manufacturers to identify and document vulnerabilities and components, including by drawing up an SBOM in a commonly used, machine-readable format. Annex VII, point 2(b) puts the SBOM into the technical documentation, and point 8 adds that it is handed to a market surveillance authority on reasoned request. Annex II, point 9 only applies if you choose to give users access: then you must tell them where to find it.
The consultancy Security & Standards, in its own comparison, reads the CRA as asking for top-level dependencies and stresses that this is its interpretation. By that reading, ENISA recommends considerably more than the regulation: a pipeline with signing, controlled sharing and retention. Our guide to CRA technical documentation shows where the SBOM sits in the file.
The advisory's main recommendations
| Topic | What ENISA recommends |
|---|---|
| Formats | A common, machine-readable standard: SPDX (3.0.1 is listed) or CycloneDX (1.7), in JSON, XML or similar. |
| When | Start at build time as a CI stage, and regenerate on commits, releases and other defined triggers. |
| Identifiers | Package URL or CPE with the exact version, plus hashes, so each SBOM is bound to the exact artifact. |
| Trust | Validate, sign, store in a tamper-evident place and keep historical SBOMs. |
| Vulnerabilities | Scan against vulnerability databases in the pipeline and use VEX to say what is actually exploitable. |
| Gaps | Write down "known unknowns", such as binary-only components you cannot fully analyse. |
| Sharing | Controlled access, because an SBOM reveals your technology stack and versions. |
The advisory also maps the data fields of the German BSI guideline TR-03183-2 against the US CISA minimum elements in a single table. The fields include the SBOM creator, a timestamp, the tool used, the generation context, component name and version, hashes, licences and dependency relationships. If a customer or authority is based in Germany, that BSI guideline is the more likely yardstick.
A telling statistic
ENISA's survey found that 24% of respondents need full-depth SBOMs from their suppliers, but only 14% receive them. That gap is the practical reason to document known unknowns: your own SBOM will only be as complete as what your SDKs and vendors tell you.
What it means for app teams
The advisory does not mention mobile apps or app stores. These points are our reading:
- Build time suits apps. Lockfiles and the resolved dependency graph are known during the CI build. Generating the SBOM per release build, for each platform, is the natural fit. See our guides for Flutter and React Native.
- Bind it to the shipped build. An SBOM for "the app" is less useful than one tied to a specific version and build number, because users stay on old versions for months.
- Closed SDKs are the known unknowns. Analytics, ads and payment SDKs often ship as binaries. Record what you know, name the supplier and ask for their SBOM or support period.
- Keep SBOMs private by default. Nothing in the CRA text quoted above forces publication, and ENISA favours controlled sharing. Decide deliberately before you promise users access.
- Do not over-build first. Signing and attestation are recommended by ENISA, not required by the CRA text. A working, regenerated, machine-readable SBOM per release is the first goal.
What we would do this week
- Add an SBOM step to the release pipeline and store the output next to each build artifact.
- Pick one format (CycloneDX or SPDX) and stick to it across apps.
- List third-party SDKs you cannot analyse and note the supplier for each.
- Scan the SBOM for known vulnerabilities on every release, and keep the results.
- Decide who may receive the SBOM, and under what conditions.
This follows ENISA's secure update advisory from earlier this month, which we covered here: both documents describe a pipeline that produces evidence, not only software.
Drop a lockfile and get an SBOM plus known vulnerabilities in seconds, or add it to your CI with the free GitHub Action.
Open the free scannerSources
- ENISA: Technical Advisory for Software Bill of Materials, publication page (22 October 2026).
- ENISA: Technical Advisory for Software Bill of Materials, v1.10, PDF.
- cyberresilienceact.eu: Annexes of Regulation (EU) 2024/2847 (Annex I, II and VII wording).
- Security & Standards: ENISA SBOM Advisory, more than the CRA requires (comparison with the CRA and BSI TR-03183-2).
- sbomify: This Week in SBOMs, 23 October 2026.
This article summarises a non-binding ENISA document and parts of EU law for practical use. It is not legal advice. Related: CRA technical documentation for mobile apps · Does the CRA apply to mobile apps?