Software supply chain security is now a regulatory and commercial liability. The EU Cyber Resilience Act, the most consequential software security regulation in a generation, requires any vendor selling software or hardware with digital components on the EU market to meet mandatory cybersecurity standards across the full product lifecycle, with financial penalties for non-compliance. At the center of its technical documentation requirements, it states that vendors must have a Software Bill of Materials (SBOM), and it must have defined minimum content standards.
For ISVs, embedded software companies, and enterprise platform teams with EU market exposure, the compliance window for this documentation is narrower than it appears. This guide covers what SBOM requirements the CRA imposes, how to build the operational practices to meet them, and which tooling actually makes compliance sustainable.
Key Takeaways
A Software Bill of Materials is a machine-readable inventory of every component, dependency, and library in a software product, including open-source packages, third-party libraries, version numbers, licensing information, and component relationships. It's a complete, structured record at the component level rather than being a high-level summary.
To illustrate, consider that in the pharmaceutical industry, regulations state that all the ingredients in a medication must be clearly listed on the label. This is both for safety and transparency surrounding the use of the medication. Sometimes, a patient has a reaction to one brand of medication that uses a particular ingredient, but they don’t have the same reaction with another brand of the same medication that doesn’t use that ingredient. The ingredient list may be instrumental in helping medical professionals narrow down the exact cause of the patient’s reaction. With software, enterprise buyers and regulators are increasingly expecting the same kind of transparency from vendors. When a component of the software creates a vulnerability or liability, identifying, tracing, and acting on it requires a complete component inventory to understand what happened and why, making an inventory list a key line item in SBOM requirements.
Two formats have emerged as industry-standard SBOM requirements, and both are recognized under the CRA's technical documentation standards.
Both formats can meet CRA compliance standards for SBOM requirements. The choice typically comes down to your toolchain and whether your primary use case is license compliance, vulnerability management, or both.
One point worth emphasizing is that SBOMs are not static documents. A well-maintained SBOM reflects the current state of a shipping codebase. Every build that changes the component set should produce an updated SBOM. One that doesn't match the shipping product isn't just useless; under the CRA's technical documentation standard, it's also documented evidence of a known compliance gap.
The business case for SBOMs starts with incident response speed. Without a complete, accurate component inventory, a vendor has no reliable way to determine their exposure to a newly disclosed vulnerability. The infamous Log4Shell incident that occurred back in 2021 is a good example. Apache Log4j was embedded in thousands of commercial software products, often several layers deep in the dependency tree. A flaw was found in this framework and exploited by hackers, allowing them to run malicious code remotely. Vendors without component inventories spent days or weeks just figuring out whether they were affected before they could begin patching or notifying customers.
The revenue consequences of that delay were significant. Companies had to identify and patch affected applications, which of course took IT teams a lot of time. There were also service disruptions and downtime, ransomware and exploitation costs, and lingering technical debt that persisted for years because of the cascading effects of remediation. In addition, companies that failed to patch systems faced legal action from regulatory bodies like the Federal Trade Commission (FTC), resulting in having to pay millions in fines.
A known, undisclosed vulnerability in a shipped product can trigger breach liability, activate indemnification clauses, and generate reputational damage that persists well past the incident itself. The cost of SBOM tooling is modest relative to that risk exposure.
In defense, healthcare, and critical infrastructure, the ability to produce a complete, accurate SBOM on demand is increasingly a prerequisite for enterprise procurement. Vendors who can produce one immediately, rather than scrambling when asked, close enterprise deals faster and with less friction at the security review stage.
SPDX | CycloneDX | |
|---|---|---|
Governing body | Linux Foundation | OWASP |
Current version | 3.0 | 1.6 |
Output formats | JSON, RDF, XML, Tag-Value | JSON, XML, Protobuf |
Primary design focus | License compliance and component identification | Security vulnerability management and supply chain integrity |
Transitive dependency support | Yes | Yes |
Vulnerability data fields | Limited native support | Native VEX (Vulnerability Exploitability eXchange) support |
CRA technical documentation compatibility | Yes — meets required data field standard | Yes — meets required data field standard |
Best suited for | Open-source-heavy codebases; license audit workflows; environments with existing Linux Foundation tooling | Security operations workflows; container-centric environments; teams integrating with CVE feeds and vulnerability management platforms |
Tooling ecosystem | SPDX Tools (Linux Foundation), Syft (with SPDX output), FOSSology | cdxgen, Syft (with CycloneDX output), Dependency-Track, Anchore |
The EU Cyber Resilience Act is a regulation requiring manufacturers and vendors of products with digital elements, both hardware and software sold in the EU market, to meet mandatory cybersecurity standards throughout the entire product lifecycle, from initial design through end-of-life support. It entered into force in October 2024 and establishes legally binding obligations for vulnerability management, security documentation, incident reporting, and SBOM maintenance.
The CRA is not a guidance framework that vendors opt into. It is a market access regulation. Products that don't meet its requirements cannot legally be placed on the EU market.
The CRA applies to any manufacturer or vendor placing a product with digital elements on the EU market, regardless of where that manufacturer is headquartered. A software company based in the United States or Canada that sells licenses, subscriptions, or hardware-embedded software to EU customers falls within scope. Geographic location does not provide an exemption, rather market access is what triggers the obligation.
The regulation covers standalone commercial software, embedded software in hardware products, IoT devices, remote data processing solutions with client-side components, and software components supplied as part of hardware. Exceptions are limited to software developed exclusively for national security or defense purposes, non-commercialized open-source software, and custom software developed under individual contracts not made available on the open market. The CRA classifies products into four risk tiers, which are explained in the table below.
Classification | Examples | Conformity Assessment Route | SBOM Required |
Default | General business software, productivity tools, standard desktop applications, most commercial off-the-shelf software | Self-declaration against CRA essential requirements | Yes |
Important — Class I | Identity management software, password managers, VPN products, network traffic management tools, SIEM systems, patch management tools, application firewalls | Self-declaration using harmonized EU standards or common specifications; third-party assessment required if standards not followed | Yes |
Important — Class II | OS and hypervisors for industrial use, PKI and certificate issuance software, hardware security modules (HSMs), industrial control system components, tamper-resistant microprocessors | Mandatory third-party conformity assessment by a notified body | Yes |
Critical | Defined by EU implementing acts; likely to include core internet infrastructure components, certain government-facing security software | European cybersecurity certification scheme or notified body assessment | Yes |
The CRA's obligations phase in over a three-year window following its December 2024 entry into force.
A functional SBOM practice should be operational well ahead of the late-2026 reporting deadlines. This provides time to validate the practice against real release cycles before the 24-hour clock starts ticking on live exploits, and ensures a smooth transition before full enforcement in late 2027. If you haven’t implemented a functional SBOM practice yet, the best time to do so is now.
The CRA's essential requirements span the full product lifecycle. To meet these requirements, products must be designed with security in mind, vulnerabilities must be actively managed and disclosed on defined timelines, and the technical documentation required to assess compliance must be maintained and available.
The CRA requires vendors to demonstrate that security was a design consideration from initial product development. This includes documented processes for identifying vulnerabilities in shipped components, patching them in a timely manner, and communicating security updates to customers.
The 24-hour active exploitation notification requirement is the most operationally demanding timeline in the regulation. When a vendor becomes aware that a vulnerability in their product is being actively exploited, they must notify ENISA within 24 hours. That's the notification deadline, not the patching deadline. Meeting it reliably requires knowing, within hours of a CVE disclosure, whether the affected component is present in a shipping product. That's only possible if an accurate, current SBOM already exists.
Vendors must produce and maintain an SBOM as part of the technical documentation required to affix CE marking to products sold in the EU market. The CRA specifies minimum required data fields: supplier name, component name, component version, unique component identifiers (CPE and PURL), dependency relationships between components, license information, and hash values for integrity verification.
The dependency relationship field deserves particular emphasis. A CRA-compliant SBOM must capture the full dependency graph, including transitive dependencies. In modern software, the transitive dependency tree frequently contains more components than the direct dependency list by an order of magnitude. An SBOM that documents only top-level dependencies is an incomplete inventory and will not meet the CRA's technical documentation standard.
Vendors are also responsible for the security posture of components they ship. Including a component with a known, unpatched vulnerability is a CRA compliance issue, which is why automated vulnerability correlation against a live CVE feed is a required operational practice.
Requirement Category | Obligation | Readiness Status |
SBOM generation | Produce a machine-readable SBOM (SPDX or CycloneDX) for every shipping build, containing all required data fields: supplier name, component name, version, CPE/PURL identifiers, dependency relationships, license information, and hash values |
|
SBOM maintenance | Keep SBOMs current and matched to the specific build they describe; update with every release that changes the component set |
|
SBOM retention | Maintain SBOM documentation for the full product support lifecycle (potentially 10+ years for industrial and embedded software) |
|
Vulnerability management process | Document internal processes for identifying, triaging, and remediating CVEs in shipped components |
|
Active exploitation notification | Establish a workflow to notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability in a shipped product |
|
Secure-by-design documentation | Document how security requirements were addressed during product design and development |
|
Product classification determination | Determine whether the product falls under Default, Important Class I, Important Class II, or Critical classification |
|
Conformity assessment | Complete the appropriate conformity assessment route (self-declaration, harmonized standards, or notified body) based on product classification |
|
CE marking and declaration of conformity | Affix CE marking and prepare the EU Declaration of Conformity with supporting technical documentation |
|
Security update commitment | Document the supported security update period and communicate it to customers |
|
Customer-facing SBOM delivery | Define a process for providing SBOMs to enterprise customers on request, in their required format |
|
The short answer is to treat SBOM generation as a build artifact and SBOM management as a long-term operational practice. The sections below cover both.
SBOM generation should be treated as a build artifact, meaning that they’re produced automatically every time a release build runs, stored alongside the binary or container image it describes, and versioned hand-in-hand with the release.
The conceptual workflow is as follows:
For containerized applications, build-time generation may not capture the complete runtime component picture. Dynamic SBOMs, which inspect running container instances including all layer content, are necessary when the runtime dependency graph diverges materially from the build-time graph. For traditional software packages and embedded software, build-time generation is generally sufficient.
Generating SBOMs is largely a solved problem for modern build environments. Managing them across product lines, customer deployments, and support lifecycles that may span a decade or more is the genuinely hard problem. For industrial and embedded software vendors, the CRA's requirement to maintain technical documentation for the full product lifecycle may mean SBOM records retained for 10 or more years.
Five operational practices that define a mature SBOM program:
The SBOM tooling ecosystem spans three functional layers: generation, deep component analysis, and compliance management. A program that addresses only one of these layers will not be sufficient to meet the 2027 deadline, nor will it build the infrastructure that positions vendors for the next wave of requirements. The vendors who treat this as a capability will be the ones who have it operational when it matters.
LicenseSpring helps software vendors manage the entitlement infrastructure that sits alongside these compliance requirements.
If your product ships to regulated industries or EU markets, contact the LicenseSpring team to discuss how your licensing architecture supports your broader compliance posture.
Most modern package managers also have SBOM generation plugins or native dependency export capabilities in standard formats. For vendors with straightforward dependency structures, these may be a sufficient starting point.
The distinction between a surface-level SBOM and a CRA-compliant one often comes down to transitive dependency coverage. Tools that only capture declared dependencies miss the majority of components actually present in a shipping product.
FOSSA provides deep component analysis, including transitive dependency mapping, license compliance, and audit-ready reporting. Black Duck (Synopsys) offers binary scanning capable of identifying components in compiled artifacts where package manager metadata is no longer present, which is critical for embedded software vendors whose final artifact is a binary image rather than a bundle overseen by a package manager. For vendors shipping compiled software in C, C++, or similar systems languages, binary analysis tooling is necessary to produce a genuinely complete inventory at the level the CRA requires.
Generation tools produce SBOMs. Compliance programs require infrastructure that manages them: storage, versioning, ongoing vulnerability correlation, policy enforcement, and the audit trail that regulators and enterprise procurement teams will expect from a mature program.
The operational maturity distinction is between vendors who generate SBOMs and vendors who manage them. A collection of SBOM files in an artifact repository without active vulnerability correlation, policy enforcement, and audit trail generation meets the letter of the generation requirement but will not support the incident reporting and documentation obligations the CRA demands.
Layer | Tool | Type | Primary Function | CRA Relevance |
Generation | Syft (Anchore) | Open source | SBOM generation for containers, filesystems, and broad package formats; SPDX and CycloneDX output | Strong for container-centric builds; direct CI/CD integration |
Generation | cdxgen (OWASP) | Open source | CycloneDX-native generation across Java, Python, JavaScript, Go, Rust, .NET, Ruby, and others | Strong for multi-language codebases requiring a single generation tool |
Generation | SPDX Tools (Linux Foundation) | Open source | Generation, validation, and format conversion; license compliance focus | Suitable for open-source-heavy environments; strong SPDX validation |
Deep Analysis | FOSSA | Commercial | Deep transitive dependency mapping, license compliance, audit-ready reporting | High; addresses transitive dependency coverage gap that surface-level tools miss |
Deep Analysis | Black Duck (Synopsys) | Commercial | Binary scanning for compiled artifacts where package manager metadata is absent | Critical for embedded and compiled software vendors shipping binary images |
Management | Dependency-Track (OWASP) | Open source | SBOM ingestion, CVE correlation, risk tracking, policy enforcement, audit trail | High; provides the ongoing vulnerability management and audit trail the CRA demands |
Management | Anchore Enterprise | Commercial | Unified generation, analysis, policy enforcement, and compliance reporting | High; enterprise-grade platform for multi-team deployments with regulatory reporting requirements |
Vendors who build mature SBOM practices before the September 2027 enforcement date are building a business capability with measurable commercial returns.
In enterprise sales cycles, the security review stage is where deals slow down. Enterprise procurement teams in regulated industries routinely request SBOM documentation, vulnerability management evidence, and proof of active CVE disclosure processes. Vendors who can respond immediately with accurate, current documentation move through procurement faster. Vendors who scramble to produce documentation on request, or who can't produce it at all, create risk flags that extend sales cycles or end deals at the finish line.
The breach liability framing is equally direct. Vendors who can demonstrate a complete component inventory, timely CVE identification, and ENISA notification within the required window are in a fundamentally better legal and reputational position than vendors who can’t. The CRA's documentation requirements create a clear evidentiary standard that’s better to meet proactively.
The CRA is also not the ceiling. US federal supply chain security requirements, sector-specific regulations in healthcare and defense, and customer-driven contractual requirements are all moving in the same direction: toward mandatory software transparency. The SBOM practice built to meet the 2027 deadline is the same infrastructure that positions vendors for the next wave of requirements. The vendors who treat this as a capability will be the ones who have it operational when it matters.
LicenseSpring helps software vendors manage the entitlement infrastructure that sits alongside these compliance requirements.
If your product ships to regulated industries or EU markets, contact the LicenseSpring team to discuss how your licensing architecture supports your broader compliance posture.
