On July 27, 2026, the European Commission published its most substantial guidance yet on applying the EU Cyber Resilience Act (CRA). The guidance helps manufacturers, developers, and businesses of all sizes by working through questions that have caused the most confusion, from what counts as a product with digital elements to how open source, support periods, and vulnerability reporting are handled. 

The update shows how much there is for manufacturers, developers, and businesses to get right across scope, technical documentation, supplier due diligence, and reporting.

One of the earliest and most concrete of those obligations, and the one embedded teams tend to hit first, is the Software Bill of Materials (SBOM). While SBOMs are not fully required until December 2027, they underlie the reporting obligations that apply as of September 11, 2026.

Any manufacturer placing a product with digital elements on the EU market now has to identify and document the components inside it and keep that record current for the life of the device.

Most manufacturers are not ready. The 2026 CRA Awareness and Readiness Report from the Linux Foundation Research and OpenSSF describes continued structural unreadiness as the deadlines approach:

• Only 32% of manufacturers produce SBOMs for all of their products
• 51% still rely passively on upstream open source projects to release security fixes
• Just 34% regularly assess the security practices of the open source components they use
• 66% of respondents remain unfamiliar with the CRA, roughly the same as the year before

For embedded software teams managing custom build systems, static dependencies, and long product lifecycles, CRA readiness starts with one practical question. 

Can you reliably identify what is inside every product release, and act on it throughout the product’s supported life?

What the CRA Requires From an SBOM

The SBOM requirement sits in Annex I, Part II of the regulation, in the section on vulnerability handling rather than product design. That placement is the point. The CRA treats the SBOM as an operational security tool that vulnerability tracking and incident reporting depend on, so an inaccurate one causes problems well beyond the paperwork.

The core text asks manufacturers to document a product’s components in a format that is “commonly used and machine-readable … covering at the very least the top-level dependencies.”

In plain terms, that means:

• Machine-readable format. A spreadsheet a person maintains by hand does not qualify.
• No mandated standard. CycloneDX and SPDX both satisfy the requirement. SPDX is published as ISO/IEC 5962:2021, and CycloneDX carries structured component, dependency, and vulnerability data.
• Top-level dependencies are a floor, not a target. Most known vulnerabilities live deeper in the dependency tree, so a fuller inventory is the safer reading.

Where the SBOM lives:

• Inside your technical documentation, available to market surveillance authorities on request.
• Not required to be public. You only tell users where to find it if you decide to make it available.

The dates that matter:

• September 11, 2026: Manufacturers must begin reporting actively exploited vulnerabilities and severe incidents. The guidance confirms this obligation applies to every product in scope, including products placed on the market before full application, and that it continues even after a product is no longer supported.
• December 11, 2027: The regulation applies in full, including SBOM requirements.

The European Commission can still specify exact SBOM elements and format through implementing acts. As of the July 2026 guidance, none has been adopted, so many view Germany’s BSI TR-03183-2 as the most concrete technical reference to build against today.

Why SBOM Generation Is Harder for Embedded Teams

A team shipping a web application can often generate an SBOM straight from its package manager. It reads a manifest, exports the dependency graph, and the result reflects what actually ships. Embedded builds rarely work that cleanly.

Most embedded and firmware products are written in C and C++, languages with limited package manager support. Components arrive through many paths:

• Statically linked C and C++ libraries that merge into the final binary and erase the boundaries between components
• Source pulled in directly or vendored into the tree
• Board support packages, vendor SDKs, and hardware abstraction layers
• Bootloaders and firmware blobs
• Legacy code whose origin no one on the current team remembers

Long lifecycles compound the problem. The CRA sets a minimum support period, but that minimum is a safeguard rather than a default. The Commission’s guidance is explicit that products reasonably expected to be in use for longer than five years should carry proportionally longer support periods. 

Embedded and IoT devices commonly need five to ten years of support, so you may have to answer questions about firmware shipped years ago, after build environments, suppliers, and engineers have all changed.

Building SBOMs Into Your Development Workflow

The most effective SBOM program is part of the build and release process, not a periodic documentation exercise. The CRA reinforces why. It treats a substantially modified release as a new product placed on the market, and it requires the technical documentation that holds the SBOM to stay accurate and up to date whether or not a given update qualifies as substantial. 

The Commission’s guidance gives a full section to what counts as a substantial modification, which matters for software that ships continuously. A pipeline that generates the SBOM on every release keeps pace with that, where a periodic export does not.

Five steps get you to something durable.

1. Define the Product and Release Boundary

Decide exactly what the SBOM describes. For embedded products, the right unit is usually a firmware image, a device model, a hardware revision, a configuration, or a complete release, not an entire product family.

Tie every SBOM to a unique identity that includes, where applicable:

• Product name and model
• Software or firmware version
• Hardware target and build configuration
• Source commit and build identifier
• Release date
• Cryptographic hash of the released artifact

Assign ownership across the workflow, too. Engineering may own generation, product security may own vulnerability analysis, and compliance may own retention. Someone has to be accountable for the whole chain.

2. Generate the SBOM During the Build

Manual scans do not scale across product variants. SBOM generation should run automatically whenever a releasable artifact is built, because the build system sees resolved dependencies, configuration options, source locations, and patches that are hard to reconstruct afterward.

A workable first implementation:

• Capture component activity at build-time
• Normalize the output into CycloneDX or SPDX
• Validate it against the chosen schema
• Associate the SBOM with the resulting firmware or binary
• Store both as release artifacts

Not every development build needs to produce a compliance record. Generate SBOMs continuously, and treat the one from the controlled release build as authoritative.

3. Set SBOM Quality Gates

A valid JSON or XML document is not automatically useful. Before an SBOM becomes part of a release, verify that it supports component matching and vulnerability response. Useful fields to gate on:

• Component names and versions
• Supplier or manufacturer, where known
• Package URLs (PURLs), CPEs, or other persistent identifiers
• Cryptographic hashes
• Direct and transitive dependency relationships
• Source and provenance
• Generating tool and timestamp
• The identity of the product described
• Known gaps in coverage

You do not need to block a release over a single missing field. You do need a defined way to measure quality, record exceptions, and improve over time. The real acceptance test is simple. Can this SBOM reliably connect a vulnerability advisory to the correct product versions?

4. Preserve the SBOM as Release Evidence

The authoritative SBOM should be immutable and linked to the exact artifact customers receive. Store it alongside the firmware image, source revision, build logs, configuration, and test results. Consider signing the SBOM or folding it into a broader provenance attestation so later users can verify it has not been altered.

Given the CRA’s 10-year retention rule for technical documentation, this cannot depend on a developer’s workstation or a build system that gets retired before the product reaches end of life. Retention has to outlive the tooling that produced it.

5. Connect the SBOM to Vulnerability Operations

An SBOM earns its keep when it is used continuously. Once generated, monitor its components against relevant vulnerability sources. When a Common Vulnerabilities and Exposures (CVE) entry is published, run a repeatable process:

• Identify potentially affected components
• Determine which product versions contain them
• Assess whether the vulnerable code is present and reachable
• Document the analysis and decision
• Remediate, mitigate, or accept the risk through an approved path
• Notify affected users and authorities when required
• Update the product, the SBOM, and the documentation

A Vulnerability Exploitability eXchange (VEX) record can state whether a product is affected, not affected, fixed, or under investigation. VEX does not replace the SBOM, and the CRA does not mandate a format, but it preserves the analysis that turns a component inventory into a product-level decision.

Reachability is where that analysis carries real weight under the CRA. The Commission’s guidance clarifies, in its section on reporting, that a vulnerability in a third-party component is a reportable, actively exploited vulnerability in your product only where the vulnerable code is actually reachable and exploitable there. A component flaw that cannot be reached in your build does not, on that basis, start the mandatory reporting clock. 

The same logic applies at release. The CRA requires products to ship without known exploitable vulnerabilities, and the guidance stresses that not every reported flaw is exploitable under practical operating conditions. An accurate SBOM paired with reachability analysis narrows both your remediation queue and what you are obligated to report.

This operational link matters most once reporting begins. Under Article 14, manufacturers must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available. Reports go to ENISA, the European Union Agency for Cybersecurity, and the relevant national Computer Security Incident Response Team (CSIRT). You cannot hit that timeline if the first step is reconstructing which products contain the vulnerable component.

Bring Your Suppliers Into the Process

You remain responsible for the security of third-party components you integrate, including free and open source software. Article 13(5) requires manufacturers to exercise due diligence when selecting and integrating those components, and Article 13(6) requires you to report vulnerabilities upstream to the party maintaining the component and to share security fixes with them when appropriate.

The Commission’s guidance is direct on where responsibility sits. It cannot be transferred to users or third parties to cover a product’s shortcomings, and maintainers of open source that is not placed on the market carry no CRA obligations toward the companies that integrate it. Responsibility for those components sits with you, which is why passive reliance on upstream to release fixes leaves a real gap.

Build a supplier intake that captures:

• Exact component and version information
• Source and provenance
• Expected support and end-of-life dates
• Vulnerability disclosure contacts
• Available SBOMs and security documentation
• Update and remediation processes
• Any restrictions on sharing vulnerability information

Supplier-provided SBOMs improve visibility, but do not treat them as authoritative by default. You still have to verify which supplier components ended up in the final product and whether the supplied inventory is current and complete.

Getting Started Now

Accurate SBOM generation for embedded software is a challenging engineering task, which is part of why so many embedded teams have not started or are on the market for solutions to meet their needs. 

RunSafe Identify generates build-time SBOMs designed for embedded systems and C/C++ code, capturing components during compilation for higher accuracy than post-build analysis, and it pairs the inventory with vulnerability identification and reachability analysis so teams can see which components actually expose them. 

That reachability determination is the same one the Commission’s guidance now ties to what you must report and remediate. For teams facing CRA requirements, this turns the SBOM into something the security team uses rather than a file that sits in a compliance folder.

The December 2027 deadline is a forcing function, and the September 2026 reporting obligation is closer still. Teams that start generating SBOMs now, and wire them into the build rather than bolting them on later, will spend the intervening time refining a working process instead of scrambling to stand one up.

An accurate component inventory is the first piece of CRA readiness, and it is the one that makes every requirement that follows possible.

Learn how to generate accurate, build-time SBOMs for embedded software and turn component visibility into an ongoing vulnerability management process.

This post is part of RunSafe Security’s CRA Readiness series. Learn more about how RunSafe supports CRA compliance.