The European Union Agency for Cybersecurity (ENISA) is at the heart of strengthening cybersecurity across the EU, from shaping policy to helping organizations implement best practices. This includes the emerging area of SBOM (software bill of materials) management.
ENISA's SBOM Landscape Analysis — Towards an Implementation Guide (v1.20), published in December of 2025, provides a blueprint for how organizations can effectively adopt SBOM practices. The publication is particularly timely in light of SBOM compliance requirements like DORA and the CRA, plus the way private enterprises are increasingly using SBOMs as a software supply chain security tool.
While ENISA's document is currently in the draft phase (it finished accepting comments on Jan. 23, 2026) and will not include any mandatory requirements, it does provide an actionable set of recommendations that we think organizations at every stage of their SBOM journey will find useful. (This is particularly important in light of the fact that several European regulations do include SBOM requirements, including the aforementioned DORA and CRA.)
ENISA's guide is 84 pages long, so it would be impractical to provide a detailed summary of each and every recommendation in this blog. Rather, we'll focus on some of the takeaways that we think are particularly important for SBOM stakeholders in Europe and around the globe (plus our own insight from supporting numerous SBOM programs), especially those in the early stages of building SBOM initiatives.
Initiation Phase: Getting Started
The first phase of the publication (found on Page 13) offers a framework to help organizations build momentum and clarity around what it takes to get an SBOM program up and running.
It covers the why (business drivers, objectives, and value analysis), who (key stakeholders involved), and what (software/product scope).
This section also highlights the tradeoffs and consequences of deciding not to implement an SBOM program, such as software supply chain security blind spots and regulatory risk. (This may come in handy if and when you need to get executive-level buy-in on SBOM initiatives.)
A few of the specific recommendations and pieces of analysis include:
SBOM Scope
ENISA rightly emphasizes the mission-critical step of identifying the software components/assets that an SBOM program should represent. This is something we’ve seen as a stumbling block for organizations getting started with SBOMs.
Additionally, ENISA smartly provides a phased approach to getting SBOM coverage across assets. Phase one includes customer-facing applications and services, phase two includes internal systems and third-party dependencies, and phase three rounds out the remainder of in-scope assets, such as containers and microservices.
Success Metrics
This is another area that we've seen separate successful SBOM initiatives from ones that have trouble getting off the ground. ENISA recommends setting specific objectives to gauge SBOM program maturity and efficacy. It highlights four in particular: coverage percentage, automation rate/response time reduction, and compliance score.
The coverage percentage measure is particularly interesting in that it is somewhat multifaceted. There’s the notion of the percent of assets represented by an SBOM, but there’s another type of coverage that’s arguably even more foundational for larger organizations that use automation to enable SBOM generation/management.
This is whether your SBOM tool can cover all of the programming languages and ecosystems across your digital assets. If not, you may find your SBOMs are incomplete (even if it appears on the surface that all assets are represented).
Planning Phase: Blueprint for Implementation
Once you're committed to SBOMs, the planning phase translates that intent into action. Beginning on Page 14 of its publication, ENISA provides a comprehensive analysis of different SBOM formats, data fields, SBOM generation methods, validation approaches, and automations that you might consider in your SBOM program.
The materials in this section range from foundational — such as whether to choose CycloneDX or SPDX as your specification — to quite advanced, such as cryptographic signing automation.
Some of the highlights include:
SBOM Specification and Format Comparison
Page 14 offers a side-by-side comparison of SPDX and CycloneDX, including the origin and benefits of each. At FOSSA, we’re mostly format-agnostic, though we have observed that some license compliance-minded teams prefer SPDX, while security-minded teams prefer CycloneDX. Our primary recommendation is that teams ensure they have the capability (generally through some sort of automated tooling) to produce and ingest SBOMs in either format, which is important to meet the needs of SBOM consumers and to ensure maximum SBOM utility in vulnerability management initiatives.
SBOM Elements
Another foundational part of the SBOM conversation is which data fields to include in your document. The United States government’s 2021 “Minimum Required Elements” publication served as a universal starting point for this conversation, and its 2025 update expanded on it (with the addition of several new mandatory fields, including licenses). ENISA provides useful summaries of each element covered in the 2025 update on Page 17 of its guidance — these include component name, component version, unique identifier, and several others.
SBOM Tooling Recommendations
Starting on Page 19, ENISA lays out a specific set of open source tools organizations can use together to generate, validate, sign, and store SBOMs. (And enrich SBOMs with vulnerability data.)
At the same time, while smaller organizations and those that use relatively few programming languages/ecosystems may be able to automate the end-to-end SBOM workflow with open source tools, more mature enterprises may prefer more comprehensive solutions (such as FOSSA's). ENISA adds a caveat along those lines: “It should be noted that interoperability between different tools handling SBOMs is not currently guaranteed, due to varying interpretations of the SBOM specifications.”
The remaining parts of the implementation section cover best practices for SBOM validation and signing (Page 20) and monitoring and observability (Page 22). Once organizations have the foundations of an SBOM program implementation in place (a decision on format, data fields, and tooling), they might consider these more advanced capabilities.
Execution Phase: Building and Using SBOMs
The next part of ENISA's guide covers the shift from planning an SBOM program to executing it, starting with SBOM generation strategies.
Approaches to SBOM Generation
The section begins with a look at three different SBOM generation methods — manual, automated, and hybrid. Our view is that nearly every mature SBOM program will benefit from automating as much of the end-to-end lifecycle as possible, but ENISA correctly notes that, particularly in the early days, human involvement is essential.
SBOM Production in the SDLC
Next, ENISA addresses one of the most common questions we hear from organizations early in their SBOM journeys: When is the right time in the SDLC to create your SBOM?
Table 6 on Page 28 describes the characteristics of generating SBOMs at different pipeline stages, starting with pre-build and concluding with runtime (and via scheduled batches). We generally recommend to our customers that producing SBOMs during build times is the best way to ensure your SBOM is as accurate and complete as possible, and ENISA echoes that sentiment.
SBOM Generation Frequency
Another foundational question organizations must answer is how frequently to update their SBOMs. Page 29 of ENISA’s publication covers six different models, ranging from the very frequent (SBOM generation triggered by every commit) to the infrequent (at quarterly or annual intervals).
Common practice among our customers is an approach that aligns with ENISA’s “Continuous” model. Since FOSSA’s SBOM management tool is tightly integrated with CI/CD processes, our customers are easily able to produce an updated SBOM that’s triggered any time a new commit is made.
Organizations without this level of automation may find it impractical to update SBOMs at such a frequent cadence, but we would encourage teams to work toward a process where new SBOMs are automatically triggered after every new commit.
In addition to the sections highlighted above, the “Execution Phase” chapter also touches on SBOM sharing and storage (Page 29), optimizing SBOM programs for different use cases, such as vulnerability management and regulatory compliance (Page 31), SBOM quality (Page 33), security controls (Page 37), and integration methods (Page 38).
Monitoring and Controlling Phase: Keeping SBOMs Healthy
On Pages 41 - 44, ENISA covers several additional areas that roll up into the broader practice of healthy SBOM management. Fundamentally, this phase is about the evolution from SBOMs as compliance artifacts that can be generated occasionally to continuously updated, actionable documents.
Highlights include recommendations to:
- Version and update SBOMs as software evolves (with metadata that enables tracking).
- Consider enriching SBOMs with information on component health; interestingly, this is actually a concrete mandate in the FDA (United States Food and Drug Administration) SBOM requirement. Organizations are required to include information on end-of-life and level-of-support status for each component in their SBOM. (This can certainly be tricky to do manually and at scale, but it is an area where tools like FOSSA can help.)
- Implement KPIs to track the percent of SBOM coverage across different asset categories, level of automation, regulatory adherence, and more.
Closure Phase: Addressing Roadblocks
The final phase (starting on Page 45) of ENISA's implementation guide calls out several potential barriers to SBOM program success. These include emerging technological challenges, concerns over whether sharing an SBOM will expose sensitive intellectual property, and nuances around open source license compliance, among others.
The specific topic in this section that we hear the most about from our customers is the concern over exposing IP. The fear is that transparency, as it relates to an application’s software composition, risks giving competitors an edge and bad actors a roadmap for taking advantage of security threats.
However, as the ENISA guide highlights, determined actors (whether competitors or attackers) can already reverse-engineer your dependency lists using standard scanning tools; they don't need your permission to see what open source libraries you use. The difference is that without an SBOM, you remain blind to your own risks while external actors are not. An SBOM simply allows your defenders and customers to identify and patch vulnerabilities faster than adversaries can exploit them.
At FOSSA, we believe the benefits of supply chain trust far outweigh the theoretical risk of IP leakage — provided you control the data. There is a critical distinction between sharing your "ingredients" (open source components) and revealing your "recipe" (proprietary algorithms and business logic).
We'd also note that “transparency" does not mean "public disclosure." Tools like FOSSA help govern SBOM distribution with granular access controls, ensuring that sensitive component metadata is shared only with authenticated customers or partners who require it for compliance.
The Bottom Line on ENISA’s SBOM Guide
Ultimately, ENISA's SBOM Implementation Guide is one of the most comprehensive and practical documents on creating and managing an SBOM program that’s been published to date. We hope this blog gives you a sense for some of its key points, but we would encourage SBOM program managers to consider viewing the full publication.
And, if your organization is looking for additional support with SBOM management (including preparations for the CRA), we welcome you to get in touch with our experts.
Author's Notes:
- The ENISA guide is structured in such a way that it provides several different reading pathways so different types of SBOM stakeholders (executives, security teams, software producers, software procurement professionals, and software operators) can focus on the most relevant sections. The document also provides similar pathways categorized by objective (regulatory compliance, supply chain security, development workflows, security posture). These pathways are laid out on Pages 10-12.
- Pages 49-53 of the guide include several practical examples of SBOM management across deployment scenarios. This material highlights technical challenges, solutions, and success metrics for various types of SBOM implementations (such as legacy systems, monorepo architectures, container applications, and more). It's worth reviewing, particularly if your organization is facing a complex SBOM implementation.