What Yocto Users Need to Know About the Cyber Resilience Act

If you’re building embedded Linux devices with Yocto and plan to sell in the EU, the Cyber Resilience Act (CRA) will soon become part of your daily reality.

Starting in 2026, vulnerability reporting becomes mandatory. By 2027, full CRA compliance is required for all connected hardware and software products sold commercially in Europe.

This blog is based on a talk Witekio gave at the Yocto Project Mini Dev Day, part of the Embedded Open Source Summit (EOSS). It distills key insights from the presentation into actionable takeaways for product teams working with Yocto.

The good news? Yocto gives you a head start. But CRA compliance doesn’t happen automatically. Here’s what Yocto users need to understand—and do—before enforcement kicks in.

CRA in a Nutshell (For Yocto Users)

The CRA is focused on product security and vulnerability management. That means:

• Your software must be designed securely.

• You must know what’s in your software.

• You must monitor, fix, and report vulnerabilities—over time.

For Yocto-based projects, this raises practical questions:

How do I generate a Software Bill of Materials (SBOM)? How do I identify CVEs? How do I track and report fixes?

Yocto has answers—but only if you use its tools intentionally.

1. SBOMs Are Not Optional—Use SPDX

The CRA requires you to document your software composition. In Yocto, this means SPDX.

Yocto supports SPDX 2.2 out of the box:

INHERIT += “spdx”

This generates an SBOM listing:

• Packages and dependencies

• Versions and patches

• Licenses and hashes

Future SPDX versions (2.3 and 3.0) offer more metadata, like build environment and reproducibility—but 2.2 is a solid starting point.

🟢 CRA Tip: Store and version-control your SBOMs. They’re the foundation for vulnerability tracking and are required for audits.

2. Activate CVE Checking

Yocto’s cve-check class helps you identify known vulnerabilities in your image:

INHERIT += “cve-check”

It compares your packages to public CVE databases and outputs a report. Expect some false positives—especially if your config disables unused features (e.g., a Bluetooth stack you don’t actually use). You’ll need to manually review, annotate, and filter those results.

🟡 CRA Tip: False positives still need to be reviewed and explained. Use Yocto’s built-in annotation mechanism to flag CVEs as “not applicable” with justification.

3. Annotate CVE Status in Recipes

Yocto lets you track how each CVE is handled by adding metadata in recipes:

CVE_STATUS[CVE-2023-1234] = “not-applicable: feature disabled”

You can:

• Mark vulnerabilities as patched, not applicable, under investigation, etc.

• Add reasons for audit traceability.

• Consolidate annotations into a single file for maintainability.

📝 CRA Tip: Your CVE tracking must be documented and transparent. This metadata will help satisfy that requirement.

4. Build a Secure, Reusable Yocto Platform

CRA compliance becomes a nightmare if you maintain a separate Yocto build for every product.

The better approach?

➡️ Create a shared Yocto platform distribution:

• Use long-term support (LTS) Yocto releases

• Modularize for reusability

• Centralize your security tools, patches, and documentation

Benefits:

• Shared CVE tracking across products

• Reuse of threat models and test processes

• Reduced maintenance effort over time

🛠 CRA Tip: Think platform-first. Build once, secure once, reuse often.

5. Embrace Documentation (Yes, Really)

CRA requires you to document:

• Your threat model and cybersecurity risk assessment

• The security mechanisms you use (e.g., secure boot, authentication)

• How you handle vulnerabilities (tools, processes, timelines)

This isn’t a “nice to have.” It’s part of compliance. But done well, it’s also incredibly useful—for development, onboarding, and certification efforts.