Pay Down Firmware Dependency Debt Before the CRA Catches Up

If you build connected devices on a ten year old board support package, the EU Cyber Resilience Act turns that dependency debt into a dated obligation: every new unit you place on the EU market from 11 December 2027 must ship without known exploitable vulnerabilities, with an SBOM and a vulnerability handling process that covers every integrated component for a support period of at least five years. Reporting of actively exploited vulnerabilities already applies, since 11 September 2026, to products you have on the market today. The way through is not a rewrite: inventory each shipped image, give every component a real identity, record the fixes you already backported, decide upgrade, backport, replace, isolate or retire per component, and set a support period your oldest dependencies can actually meet.

Key takeaways

• Main obligations apply from 11 December 2027, but Article 14 reporting has applied since 11 September 2026, and Article 69(3) extends it to products already on the market.
• Annex I Part I(2)(a) asks that products be made available "without known exploitable vulnerabilities". Old dependencies are not banned; known exploitable ones are, so the work is deciding exploitability per CVE, per build.
• Article 13(8) sets a support period of at least five years and tells you to weigh the support periods of third-party components that provide core functions. If your vendor kernel stops getting fixes in 2027 and you promise 2033, you own the gap.
• Article 13(6) requires you to report component vulnerabilities to the maintainer and share your fix where appropriate. Silent backports in a private fork do not do that.
• The fastest debt reduction is identity, not upgrades: package URLs or CPEs on every component, a ledger of backported patches, and VEX statements so your scanner stops reporting fixed issues as open.
• Safeguard works from the SBOM your build produces; it does not analyse firmware binaries. SBOM analysis, vulnerability management with EPSS and KEV, CSAF and VEX upload, license compliance, policies and gates, the compliance suite with its EU CRA framework, TPRM, Portal sharing and the CLI are GA. Autonomous remediation is GA and ships switched off, every category set to Manual.

The situation

The trigger is usually a sentence in a distributor contract or a customer's procurement questionnaire: "Confirm CRA conformity for all products shipped into the EU after 11 December 2027, and provide the SBOM and support period end date." It lands on whoever owns product security at the device maker, often a Head of Product Security or a firmware director who inherited the job.

That person knows what sits underneath. Three hardware generations still in production, each on a silicon vendor's board support package frozen at whatever kernel, bootloader and toolchain shipped when the chip was new. A real time operating system on the secondary microcontroller with a TLS library copied into the tree years ago. Patches cherry picked from upstream into a private branch, version string unchanged. A companion app and cloud backend that are modern by comparison and already scanned in CI.

A bad week: a customer scans the SBOM you sent and reports hundreds of critical findings, most for fixes you backported years ago, and you cannot prove which because backports were never recorded against CVEs. Meanwhile an advisory lands for a library somewhere in the RTOS image, and nobody can say within a day which firmware versions contain it. If it is actively exploited, Article 14's early warning clock is 24 hours from awareness.

The real question is not "how do we become compliant". It is "which of these old components block us, which can we defend with evidence, and what will the rest cost before December 2027".

What the CRA actually asks of an old dependency tree

Everything in this section comes from the text of Regulation (EU) 2024/2847. EUR-Lex returned a bot challenge when we fetched it on 25 October 2026, so the clauses below were read from an Internet Archive copy of the official EUR-Lex page for the regulation, captured on 28 December 2025, and cross checked against the European Commission's CRA policy page for dates. This is a reading of the regulation for engineering planning, not legal advice. Your notified body or counsel decides how it applies to your product class.

The dates

Article 13(5): due diligence on third-party components

Manufacturers "shall exercise due diligence when integrating components sourced from third parties", explicitly including open source components that were not placed on the market commercially. Recital 34 lists what due diligence can look like, scaled to the risk: checking whether the component carries a CE marking, checking that it "receives regular security updates, such as by checking its security updates history", checking it against the European vulnerability database or other public databases, or running additional security tests.

For an old dependency tree, the second test is the uncomfortable one. A component frozen in a vendor BSP fails "receives regular security updates" by definition unless someone, maybe you, is supplying them.

Article 13(6): report upstream and share the fix

When you identify a vulnerability in an integrated component, you must report it to the person or entity that makes or maintains it, and remediate it under Annex I Part II. Where you developed a fix, you "shall share the relevant code or documentation" with that maintainer, where appropriate in machine readable form.

A private fork with backported patches is how most device makers handle frozen dependencies. The CRA does not forbid it, but expects your fixes to go back upstream where appropriate.

Annex I Part I(2)(a): no known exploitable vulnerabilities

On the basis of the risk assessment, products shall "be made available on the market without known exploitable vulnerabilities". The wording carries two qualifiers that matter for dependency debt. It says known, and it says exploitable. A CVE in a function your build never compiles, or behind an interface your product does not expose, is a different case from one in the network facing TLS stack. Your job is to show which is which, per CVE, per product version.

Recital 38 adds an operational point that catches series production: for a product type, "each individual product" placed on the market should have received the available security patches. Check stock that still carries old firmware.

Annex I Part II: vulnerability handling for the whole support period

Part II lists eight requirements. Four of them land directly on dependency debt:

• Part II(1): identify and document vulnerabilities and components, including an SBOM "in a commonly used and machine-readable format covering at the very least the top-level dependencies".
• Part II(2): address and remediate vulnerabilities without delay, including by security updates, and where technically feasible ship security updates separately from functionality updates.
• Part II(3): apply effective and regular tests and reviews of the product's security.
• Part II(8): disseminate available security updates without delay and free of charge, with advisory messages.

The separation in Part II(2) matters: if your only release train bundles BSP upgrades with features, every security fix waits for the next feature release.

Article 13(8) and 13(9): the support period and how long updates stay available

The support period "shall be at least five years", unless the product is expected to be in use for less. When you set it, you may take into account "the support periods of integrated components that provide core functions and are sourced from third parties". Article 13(9) then requires each security update to remain available for at least ten years after issue, or for the rest of the support period, whichever is longer. Article 13(19) requires the end date of the support period, at least month and year, to be clear at the time of purchase.

Read together, these turn your dependency tree into a calendar. The kernel, bootloader, TLS library and RTOS in each product have their own end of upstream support. Where those end before your declared support period ends, the remainder is your patching cost.

Articles 13(3), 13(7) and Annex VII: write it down

The risk assessment must be documented and kept updated, and Article 13(7) requires you to document vulnerabilities you learn about. Annex VII point 2(b) puts the SBOM, the coordinated vulnerability disclosure policy and the vulnerability handling process into the technical documentation, and Article 13(13) requires that documentation to be kept for at least ten years after placing on the market or for the support period, whichever is longer.

Article 14 and Article 69(3): reporting already applies to your installed base

Article 14 requires notification of any actively exploited vulnerability in your product, through the single reporting platform, to the coordinating CSIRT and ENISA: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. Article 69(3) applies this to all in scope products placed on the market before 11 December 2027. If a ten year old library in a product you shipped in 2021 is being exploited, the clock is already live.

The US frame for the same work

Most of this engineering is already in US guidance. NIST IR 8259A sets a baseline of device cybersecurity capabilities for IoT manufacturers, and NIST SP 800-218, the Secure Software Development Framework, sets secure development practices that apply equally to firmware. CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, which replace the NTIA 2021 minimum elements. The CISA Known Exploited Vulnerabilities catalog and FIRST's EPSS scores are the two most common inputs for deciding what "exploitable" means in practice. One SBOM and triage process that meets both is one process instead of two.

Germany's BSI publishes TR-03183-2 for SBOMs, now at version 2.1.0, with a mapping of its fields to SPDX and CycloneDX; a useful field checklist if you sell into Germany.

Where dependency debt hides in an embedded product

Each shape of firmware dependency debt has a different cheapest fix.

Teams forget the last row: removing an unneeded component is often cheaper than patching it.

Step by step, with or without Safeguard

The steps below work with whatever tools you have. They are ordered so the cheapest, highest yield work comes first.

1. Fix the scope: one SBOM per shipped image, per firmware version

List every product and every firmware version currently sold into the EU or likely to be sold after December 2027. For each, identify the exact build that produced the image you ship. Debt is per build, not per product family. Two firmware versions of the same device can differ by dozens of components.

Write down which builds you can still reproduce. An image you cannot rebuild from source has to be made reproducible before it can be fixed, often the largest hidden cost in the programme.

2. Generate the SBOM from the build system, not from the binary

On Yocto Project builds, the create-spdx class produces SPDX output when an image is built. The Yocto documentation describes the output as an IMAGE-MACHINE.spdx.json file under tmp/deploy/images/MACHINE/, with options such as SPDX_INCLUDE_SOURCES, SPDX_INCLUDE_KERNEL_CONFIG and supplier fields such as SPDX_IMAGE_SUPPLIER. Include the kernel configuration: many kernel CVEs sit in code your configuration does not build.

On Zephyr, west spdx generates SPDX documents for a build. The Zephyr documentation shows the sequence: enable CONFIG_BUILD_OUTPUT_META, build, then run the command against the build directory.

# From the Zephyr documentation (not run for this post)
west build -d BUILD_DIR
west spdx -d BUILD_DIR
# SPDX 2.3 tag-value by default; for SPDX 3.0 JSON-LD:
west spdx -d BUILD_DIR --spdx-version 3.0

Zephyr writes separate documents for the application, Zephyr sources, build output and module dependencies; keep the last one, where vendored libraries show up.

For hand rolled Make or CMake builds, generate CycloneDX or SPDX from a manifest kept next to the source: one entry per vendored library with upstream name, exact version, supplier, license and path.

Check which SPDX version your tooling emits; some consumers do not yet read SPDX 3.0 JSON-LD.

3. Give every component an identity a database can match

A component without a resolvable identifier cannot be matched to an advisory, or shown free of known exploitable vulnerabilities. Each entry needs:

• a package URL where one exists (Yocto and Linux distribution packages, Rust crates, Python packages in build tooling);
• a CPE where no package URL fits, which is common for C libraries vendored into an RTOS tree;
• the exact upstream version, not "latest" or a branch name;
• the supplier, meaning the project or vendor that maintains the component;
• a hash of the artifact where your tooling can produce one.

These fields also make VEX possible: a "not affected" statement must point at a specific component and version.

4. Build a patch ledger for every fork and backport

This is the single most valuable artefact for a team with deep dependency debt. For each component where you carry patches on top of an upstream release, record what you changed and which CVE it addresses. A plain YAML file in the repository is enough.

# patch-ledger.yaml (template; one entry per backported fix)
component: zlib
upstream_version: 1.2.11
local_version: 1.2.11-acme3
supplier: zlib project
identifier: cpe:2.3:a:zlib:zlib:1.2.11:*:*:*:*:*:*:*
fixes:
  - cve: CVE-YYYY-NNNNN
    upstream_commit: abc1234
    local_commit: def5678
    applied_in_firmware: ["2.4.1", "2.5.0"]
    verified_by: unit test test_inflate_bounds
    shared_upstream: "not needed, upstream fix exists"

The ledger answers customer scanner output with evidence, feeds your VEX documents in step 6, and shows how much debt is already paid, usually more than anyone expects.

Use a local version suffix such as -acme3 so readers see the component differs from upstream, and keep the upstream version in its own field for matching.

5. Triage findings with exploitability, not just severity

Run the SBOM through a scanner, then sort findings into decisions. CVSS alone will not do it: a critical score in code your build never compiles is a smaller risk than a medium one in your exposed network stack.

Use three inputs per finding:

1. Known exploitation. Is the CVE in the CISA KEV catalog? If yes, treat it as the top of the queue for every product that ships the component.
2. Likelihood of exploitation. FIRST's EPSS gives a probability that a vulnerability will be exploited in the next 30 days. Use it to order the long tail, not to dismiss anything on its own.
3. Exposure in your product. Is the vulnerable code compiled into this build? Is it reachable from an interface an attacker can touch: a network port, a Bluetooth service, a USB descriptor, a file parser fed by user data? Your kernel configuration and build options answer the first question; your threat model answers the second.

Then make one decision per finding, per product version:

Do not add "accepted risk" as a seventh column: under Annex I Part I(2)(a) a known exploitable vulnerability needs one of these decisions, not a waiver.

6. Publish VEX for what you fixed and what does not affect you

VEX lets you state, in machine readable form, the exploitability status of a vulnerability in a specific product. CycloneDX, OpenVEX and the CSAF VEX profile are the common formats. A statement says which product and version it covers, which vulnerability, the status (such as not affected, affected, fixed or under investigation) and, for "not affected", a justification such as "vulnerable code not present" or "vulnerable code not in execute path".

VEX is how the patch ledger reaches customers' scanners. Generate one per firmware release from the ledger and triage decisions, ship it with the SBOM, and re-evaluate when build configuration changes, because "not compiled in" stops being true the day someone enables the driver.

7. Do the support period arithmetic

Build a worksheet per product. One row per core component, with the upstream end of support date you can find, and the end of the support period you intend to declare.

Article 13(8) lets you weigh core components' support periods; it does not let yours end when theirs does if users reasonably expect longer. Where the gap is large, budget the backports, migrate components at a hardware revision, or set a shorter period that still meets the five year floor and user expectations, stated at purchase per Article 13(19).

8. Ask your silicon and module suppliers for what you cannot see

Binary blobs and vendor BSPs are your components under Article 13(5) even though you did not write them. Send each supplier a short written request:

• an SBOM for the BSP, firmware blobs and SDK libraries you ship, in SPDX or CycloneDX;
• the supplier's support end date for each, and how security fixes are delivered;
• their coordinated vulnerability disclosure contact and policy;
• whether they will issue VEX or CSAF advisories for their components;
• how they will notify you of an actively exploited vulnerability, and how fast.

Keep the replies with your technical documentation; a supplier who cannot answer is a finding for the risk assessment.

9. Turn the decisions into rules that stop new debt

Paid down debt returns unless something checks new builds. Run a few rules on every shippable build:

• no component in the CISA KEV catalog without a ledger entry or VEX statement;
• no new component without a package URL or CPE, a version and a supplier;
• no component whose upstream has had no release for a period you choose, unless approved with an expiry date;
• no copyleft license your distribution model cannot meet.

Approvals for exceptions should carry a reason and an expiry date, so a frozen BSP item is reviewed on a schedule rather than forgotten.

10. Rehearse Article 14 on the installed base

Pick a component in your oldest shipped product and time three answers: which products and firmware versions contain it, which member states they were sold into, and what users can do today. If that takes more than a few hours, the 24 hour early warning is at risk; the fix is steps 1 to 4 applied to firmware already in the field.

Does the CRA apply to products we already ship?

Partly. Under Article 69(2), products placed on the market before 11 December 2027 are subject to the regulation only if they are substantially modified from that date. Under Article 69(3), Article 14 reporting applies to all of them. So the installed base needs a reporting process now. Article 3(30) defines a substantial modification as a change that affects compliance with the Part I essential requirements or modifies the intended purpose. Recital 38 adds that each individual unit placed on the market should carry the available patches.

Can we ship a product with a known CVE in an old library?

The text says products shall be made available without known exploitable vulnerabilities, on the basis of the risk assessment. A known CVE that you can show is not exploitable in your build, because the code is not compiled in, not reachable, or already fixed by a backport, is defensible with evidence. A known exploitable one is not. The evidence is the patch ledger, the build configuration and a VEX statement. Your notified body or market surveillance authority decides whether your evidence is good enough; build it so a stranger can follow it.

What counts as top-level dependencies for firmware?

Annex I Part II(1) requires an SBOM covering "at the very least the top-level dependencies". The regulation does not define the term for firmware, and Article 13(24) lets the Commission specify SBOM format and elements by implementing act. A practical reading for embedded products is every package, library and blob that goes into the image directly: the kernel, bootloader, root filesystem packages, RTOS and its modules, vendored libraries and vendor binaries. Most build system SBOMs also include transitive dependencies, which you want anyway.

What do we do about an abandoned upstream?

You have four honest options: replace the component, isolate it so the vulnerable interfaces are unreachable, carry your own fixes and offer them to the project or its successor as Article 13(6) expects, or retire the product at the end of a support period you declared in advance. What you cannot do is leave it unexamined; recital 34's due diligence explicitly asks whether a component receives regular security updates.

A worked example (illustrative)

The numbers below are invented and rounded to show the arithmetic. Redo it with your own.

A device maker has three product generations still shipping into the EU. Their SBOMs, once generated from the builds, list about 1,200 components in total, and a first scan reports about 900 vulnerability findings, 150 of them rated critical or high.

In weeks one to three the team builds the patch ledger from fork histories. 40 of the critical and high findings are already fixed by backports, and 50 sit in kernel code the configuration does not build. Both become VEX statements, "fixed" and "not affected, vulnerable code not present".

That leaves 60 needing a decision. Five are in the KEV catalog and go first; two of those sit in a web configuration interface that can be removed from the production image. The rest split between upgrades, backports, and one TLS library on the oldest RTOS that must be replaced.

The worksheet shows the oldest generation's vendor kernel gets no upstream fixes after 2027. The team either budgets backports through a 2032 support end or declares a shorter period and moves new orders to the next generation. The worksheet makes that business decision visible.

None of this needed a firmware binary: only the SBOM, the build configuration and the fork history.

How Safeguard does this

Safeguard starts where step 2 above ends: with the SBOM your build system produces. It does not take a firmware image apart. Everything below is from Safeguard's documentation and offering; screens and commands are named only where the docs show them, and none of the commands were run for this post.

1. Check the SBOM locally with the Safeguard CLI (GA). The docs show safeguard validate sbom.json to check the document against its specification and safeguard scan --sbom sbom.json to scan it, writing results under ./output. The docs are explicit that the CLI does not upload SBOMs to the platform.

# From docs.safeguard.sh, Existing SBOM page (not run for this post)
safeguard validate sbom.json
safeguard scan --sbom sbom.json

2. Upload the SBOM as a product version (SBOM generation and analysis, GA). In the web app, go to Integrations and click Connect on the Upload SBOM card. Enter a project name and the firmware version, choose the format or let it be detected, and upload the file. The docs list CycloneDX 1.3 to 1.6 in JSON and XML and SPDX 2.2 and 2.3 in JSON, tag-value and RDF, with a 100MB file limit. That covers Zephyr's default SPDX 2.3 tag-value output; if your build emits SPDX 3.0 JSON-LD, check the current docs before you rely on it. Upload one SBOM per firmware version.

3. Let the platform validate and enrich it (vulnerability management, GA). After upload, the docs describe schema and required field validation, then enrichment of every component with CVE matches, EPSS scores, CISA KEV status, license data and supplier data, then analysis that includes risk scoring, attestation scoring and dependency health. A component with no package URL or CPE cannot be matched by any tool.

4. Measure SBOM quality before you trust the findings (compliance and GRC suite, GA). In Compliance, the Component Health framework checks for package URLs, names and versions, supplier attribution, hashes, licenses, dependency relationships, and SBOM author and timestamp. VEX Readiness checks whether the SBOM can carry VEX: package URLs or a fallback such as a CPE, exact versions, a document identifier and dependency relationships. Run both on the oldest product first to see where step 3's identity work is missing. Note that Safeguard's Component Health page still cites the NTIA minimum elements, which CISA's 2026 minimum elements replaced in July 2026.

5. Map the work to the CRA (compliance and GRC suite, GA). The EU Cyber Resilience Act framework in Compliance checks each product's SBOM against scan requirements mapped to the clauses above: top-level dependencies and a documented component set (Annex I Part II(1)), exact versions for remediation (Part II(2)), a disclosure contact, integrity hashes, supplier attribution (Article 13) and timestamped documentation (Article 31, Annex VII). Its Controls tab covers the rest, such as security updates through the support period and reporting to ENISA, evidenced by uploads, policies or attestations. CRA policy templates cover product security, disclosure, SBOM management and incident reporting.

6. Upload your VEX and CSAF documents (CSAF and VEX upload, GA). Go to Integrations, filter by Upload, and click Connect on the Upload CSAF/VEX card. The docs list CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. This is how the patch ledger from step 4 reaches the findings view: upload the VEX document for a firmware version and its "not affected" and "fixed" statements are recorded against that product. You can also upload CSAF advisories your silicon vendor publishes, so their statements sit next to your own.

7. Check licenses on vendored code (license compliance, GA). The Suppliers and Licenses tab groups components by supplier type (open source project, commercial vendor, internal or unknown) and license category, and flags issues such as strong copyleft in a proprietary product or missing attribution. For embedded products that ship a Linux root filesystem, this is the same inventory you need for your source offer and notices.

8. Write rules that stop new debt (policies, gates and guardrails, GA). Under Settings, Policies, Create Policy, the docs list conditions that fit dependency debt directly: vulnerability severity, CVSS score, EPSS score, license, component age ("no components older than 2 years" is the docs example) and maintenance ("no abandoned packages"). Templates include No Critical Vulnerabilities and No Abandoned Packages. Each policy has an action: Block fails the gate, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. Approval runs through exceptions: a developer requests an exception with a business justification and an expiration date, an approver decides, and the audit trail records it. That is the right home for a frozen BSP item you have decided to carry for now. Policy outcomes are switched on per workspace by Safeguard; if you do not see an Outcome column, ask your Safeguard contact.

9. Gate the parts that build from repositories (Safeguard CLI, GA). Your companion app, cloud backend and any Rust, Python or Go tooling in the firmware build can be connected as repositories. For those, the docs show safeguard ci scan --wait --fail-on-gate with a gate name, id or all, which fails the CI job when a Block policy fails and passes on Warning. For firmware SBOMs uploaded by hand, policies are evaluated when new assessment data arrives for the product, so a new upload is the trigger.

10. Request SBOMs from your silicon and module suppliers (TPRM, GA). In Third Party Risk Manager, open the vendor, click Request SBOM, choose the products, a template and a deadline, and send. Status moves through Sent, Viewed, In Progress, Submitted, Validated or Rejected, with reminders before and after the deadline. Received SBOMs are format checked, completeness checked and scanned automatically. That turns step 8 into a tracked due diligence record under Article 13(5).

11. Share the SBOM with customers (Portal, the SBOM publish and share product, GA). Share with named recipients at View, Download or Full permission, or by expiring, password protected links, with optional NDA acceptance and an access log. If you choose to make the SBOM available to users under Annex II point 9, this is a controlled way to do it.

12. Fix what has a fixed version in the ecosystems Safeguard patches (autonomous remediation, GA, ships off). For code built from package ecosystems, such as the companion app, backend and Rust or Python tooling, Griffin can open tested fix pull requests, singly or in bulk. It ships switched off, with every category set to Manual. It does not patch C libraries inside a vendor BSP; those stay with your backport process.

13. Keep it on your own infrastructure if needed (on premises and air gapped deployment, Zero AI mode, GA). SBOMs can reveal unreleased hardware. Safeguard deploys as SaaS, in a private VPC, on premises or fully air gapped, and can run with no language model in the loop or with your own model.

One SBOM per firmware version becomes the single record for scanning, VEX, policy, supplier evidence and sharing.

What Safeguard does not do

• It does not analyse firmware binaries. Safeguard works from the SBOM you bring. If a component never made it into your SBOM, because it was copied into the tree without a manifest entry or arrived as a blob, Safeguard cannot see it. Step 2 and step 3 above are your job.
• It does not generate the SBOM from your Yocto, Zephyr or custom build. Your build system does that. The CLI validates and scans an SBOM file locally; it does not upload one, and uploads happen in the web app.
• It does not decide exploitability for your device. Enrichment gives you EPSS, KEV and dependency context, and reachability analysis (GA) applies where Safeguard can see code. Whether a CVE is reachable through your product's Bluetooth stack or a disabled kernel option is your engineers' judgement, recorded in your VEX.
• It does not backport fixes into vendor BSPs or vendored C code. Autonomous fix pull requests cover package ecosystems, not patches to a frozen kernel branch or an RTOS source tree.
• It does not file your Article 14 notifications. The CRA framework includes a control for reporting to ENISA, and Safeguard can hold the evidence, but submitting through the single reporting platform within 24 and 72 hours is your process and your decision.
• It does not perform conformity assessment, sign your EU declaration of conformity or set your support period. Those are the manufacturer's obligations under Articles 13 and 28, and for important and critical product classes they may involve a notified body.
• It does not make your supplier answer. TPRM tracks and validates; a vendor who will not send an SBOM is a risk you document.
• The documented /v1 REST endpoints are not available yet. Several docs pages show API upload examples with a banner that every path under the /v1 API returns 404 today. Use the web app and CLI flows above.

Common mistakes

• Treating the SBOM as a one off deliverable. Generate and rescan it on every build that produces a shippable image.
• Scanning the product family instead of the firmware version. Findings that are not tied to a specific shipped version cannot be fixed, VEX'd or reported accurately.
• Leaving version strings unchanged on forks. It guarantees every scanner, yours and your customers', reports fixed issues as open. Add a local suffix and keep the upstream version in its own field.
• Writing "accepted risk" against a KEV listed vulnerability. Annex I Part I(2)(a) is about known exploitable vulnerabilities. A waiver is not a remediation.
• Declaring a support period without checking component end dates. The worksheet takes an afternoon; the gap, found later, takes years.
• Bundling security fixes with feature releases. Annex I Part II(2) asks for separate security updates where technically feasible.
• Ignoring blobs because they cannot be scanned. They are still integrated components under Article 13(5). Ask, record the answer, and document the residual risk.
• Keeping silent backports to yourself. Article 13(6) expects you to report vulnerabilities to the component's maintainer and share your fix where appropriate.

FAQ

Does the Cyber Resilience Act apply to embedded and IoT devices?

Yes, if they are products with digital elements made available on the EU market and not covered by one of the regulation's sector exclusions, such as type approved vehicles and certified aviation products. Connected consumer and industrial devices are squarely in scope. Some product classes listed in Annexes III and IV face stricter conformity assessment.

What is dependency debt in firmware?

The gap between the component versions your firmware ships and the versions maintainers still fix, plus undocumented local patches that hide what you already fixed.

Do I need an SBOM for every firmware version?

In practice, yes. The CRA's SBOM sits in vulnerability handling and the technical documentation, and components and vulnerabilities differ between versions.

Can a VEX statement satisfy the "no known exploitable vulnerabilities" requirement?

VEX records that a known vulnerability is fixed or not exploitable in your product. It is evidence, not a pass: back it with the build configuration or the patch, and keep it current when the build changes.

What if my silicon vendor will not provide an SBOM?

Record the request and the refusal, inventory what you can from your own build, and treat the gap as a risk in your cybersecurity risk assessment. Article 13(5) puts due diligence on you as the manufacturer either way.

Do I have to share my firmware patches with open source projects?

Article 13(6) says that when you identify a vulnerability in an integrated component you must report it to the maintainer, and where you developed a fix you shall share the code or documentation with them, where appropriate. Talk to counsel about what "where appropriate" covers for your product.

Does the 2026 CISA SBOM guidance matter if I only sell in the EU?

It is not a CRA requirement, but it describes the fields that make an SBOM usable for vulnerability matching, so meeting it lets one SBOM serve EU and US customers.

Can Safeguard scan my firmware image directly?

No. Safeguard analyses SBOMs your build produces, in SPDX or CycloneDX, along with VEX and CSAF documents you upload. It does not unpack or analyse firmware binaries.

When your oldest component has no fixed upstream release, or the fix sits in a dependency you build from a package ecosystem rather than a vendor BSP, the remediation paths below apply. They cover the open source dependencies and images you build yourself; fixes inside a silicon vendor's binary still have to come from that vendor.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session: you install the CLI, run safeguard to open the interactive terminal, and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. For a device maker, the same flow applies to the companion app and backend code that ship with the device, where a fixed version exists in a package ecosystem.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. That matters for firmware teams whose build servers sit on an isolated network: the SBOM can be validated and scanned where it is produced, before anything leaves the building.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• SBOM for embedded systems
• Securing IoT device firmware supply chains
• CRA Article 14 vulnerability reporting in 72 hours
• How to find end of life components in your SBOM
• Find vulnerabilities in vendored or copied code
• Support period and end of life dates: what buyers expect

Sources

• Regulation (EU) 2024/2847, the Cyber Resilience Act, EUR-Lex page as archived by the Internet Archive on 28 December 2025
• European Commission: Cyber Resilience Act policy page
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Software Bill of Materials
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System
• NIST IR 8259A: IoT Device Cybersecurity Capability Core Baseline
• NIST SP 800-218: Secure Software Development Framework
• BSI: Technical Guideline TR-03183, Cyber Resilience Requirements
• Yocto Project: Creating a Software Bill of Materials
• Zephyr Project: west spdx and other Zephyr extension commands
• CycloneDX: Vulnerability Exploitability Exchange
• OpenVEX
• OASIS: Common Security Advisory Framework 2.0
• Package URL specification
• Safeguard docs: Existing SBOM
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: EU Cyber Resilience Act framework
• Safeguard docs: Component Health framework
• Safeguard docs: VEX Readiness framework
• Safeguard docs: Suppliers and Licenses
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: Portal Sharing

Download Safeguard at safeguard.sh/download, and read the product documentation at docs.safeguard.sh.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.