Use case: CRA and global rule mapping for an IoT device maker

If you ship connected devices into the EU, the Cyber Resilience Act's reporting duty has applied since 11 September 2026: an actively exploited vulnerability in your product needs an early warning within 24 hours, a notification within 72 hours and a final report within 14 days of a fix being available. You can only meet that clock if you already know, per firmware build, which components you ship and which other rules (UK PSTI, ETSI EN 303 645, the RED cybersecurity requirements, US state and federal schemes) ask for the same evidence. This post shows a product security team how to build that map once and keep it current.

Key takeaways

• The clock is already running. Article 14 of Regulation (EU) 2024/2847 applies from 11 September 2026. The rest of the CRA, including the Annex I essential requirements, applies from 11 December 2027. Reporting goes through ENISA's Single Reporting Platform, which ENISA says is operational.
• One inventory, many rules. The CRA, ETSI EN 303 645, UK PSTI, the FCC's Cyber Trust Mark and California's connected device law ask overlapping questions: what is in the device, how long you will patch it and how people report bugs to you. Answer them from one per build inventory.
• The SBOM has to match the shipped firmware. CRA Annex I Part II(1) asks for a machine readable SBOM covering at least top level dependencies. A source tree SBOM that drifts from the device image will mislead you inside a 24 hour window.
• Support periods are a product decision with legal weight. Article 13(8) sets a default of at least five years, and Annex II asks you to tell users the end date.
• Safeguard capabilities used here: SBOM generation and analysis (GA), SCA with deep transitive scanning (GA), vulnerability management with EPSS and KEV (GA), reachability analysis (GA), policies and gates (GA), the Compliance and GRC suite (GA), CSAF and VEX upload (GA), Trust Center (GA), TPRM (GA), the CLI and local runner (GA), and autonomous remediation (GA, ships switched off with every category set to Manual).
• What stays yours: deciding whether a vulnerability is actively exploited, filing on ENISA's platform, signing the declaration of conformity and choosing the support period.

This post interprets regulations to explain an engineering workflow. It is not legal advice; confirm your obligations with counsel and your notified body where one applies.

The job and who owns it

The persona here is the product security lead at a company that designs and sells connected devices: cameras, hubs, locks, sensors, wearables or industrial gateways, built on embedded Linux or an RTOS, with a companion mobile app and a cloud backend. The company sells into the EU, probably the UK, and very often the US.

The trigger is a date. From 11 September 2026, Article 14 of the CRA turned "we patch when we can" into a reporting obligation with hour based deadlines, and the remaining obligations arrive on 11 December 2027.

The person who owns this is usually stretched across three groups:

• Firmware engineering, who own the build system (Yocto, Buildroot or a vendor SDK) and know what is in each image.
• Cloud and app teams, whose services and apps ship alongside the device.
• Compliance, who own the CE file, RED test reports and the UK statement of compliance.

What a bad week looks like: a widely used library in your firmware gets added to CISA's Known Exploited Vulnerabilities catalog on a Tuesday afternoon. Someone asks, "Are we affected, and does this start our 24 hour CRA clock?" Firmware engineering needs a day to work out which of the last forty builds contain the vulnerable version. By the time you have an answer, the first deadline has passed. The job here is preventing that week: one map from each shipped build to its components, and from those components to every rule that asks about them.

The rules behind it

Primary text first. EUR-Lex returned an empty HTTP 202 page for the CRA and the RED delegated act when we fetched them on 25 October 2026, so the quotations and clause numbers below come from Internet Archive copies of the official EUR-Lex pages, read in full and linked in Sources. Check the live EUR-Lex text before you rely on any clause.

The Cyber Resilience Act, Regulation (EU) 2024/2847

When it applies. Article 71(2) says the regulation applies from 11 December 2027, but Article 14 applies from 11 September 2026 and Chapter IV (notified bodies, Articles 35 to 51) from 11 June 2026.

What Article 14 asks for. A manufacturer must notify any actively exploited vulnerability in its product that it becomes aware of, simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform set up under Article 16. Article 14(2) sets three stages:

Severe incidents affecting product security follow a parallel track in Article 14(3) and (4), with the final report due within one month of the incident notification.

Article 14(7) says which CSIRT receives the report: the one in the Member State of your main establishment in the Union, defined as where cybersecurity decisions about your products are predominantly taken. A manufacturer with no EU establishment follows an ordered list that starts with the Member State of its authorised representative, then its importer. Work this out before the first incident.

Article 14(8) adds a duty that product teams often miss: after becoming aware of an actively exploited vulnerability or severe incident, inform the impacted users, and where appropriate all users, including mitigation steps, "where appropriate in a structured, machine-readable format". That phrasing is why CSAF advisories and VEX statements come up in CRA conversations.

What Article 13 asks for. Article 13(5) requires due diligence when integrating third party components, including free and open source components, so they do not compromise the product's cybersecurity. Article 13(8) requires vulnerabilities of the product, "including its components", to be handled effectively for the support period, and sets that period at a minimum of five years unless the product is expected to be in use for less. Article 13(13) requires the technical documentation and EU declaration of conformity to be kept for at least 10 years after market placement or for the support period, whichever is longer.

What Annex I Part II asks for. These are the vulnerability handling requirements. In summary, manufacturers must:

1. Identify and document vulnerabilities and components, including an SBOM in a commonly used, machine readable format covering at the very least the top level dependencies.
2. Remediate vulnerabilities without delay, including through security updates, separate from feature updates where technically feasible.
3. Test and review security regularly.
4. Publicly disclose fixed vulnerabilities once a fix is available.
5. Enforce a coordinated vulnerability disclosure policy.
6. Provide a contact address for vulnerability reports, including on third party components.
7. Distribute updates securely, automatically where applicable.
8. Ship security updates without delay and, in most cases, free of charge.

What Annex II asks for. User information must include a single point of contact for vulnerability reports and where the coordinated disclosure policy can be found, and "the end-date of the support period".

Which IoT products are "important". Annex III Class I includes, among others, routers and modems, smart home general purpose virtual assistants, smart home products with security functionalities (the annex names smart door locks, security cameras, baby monitoring systems and alarm systems), internet connected toys with social interactive or location tracking features, and certain personal wearables. These face stricter conformity assessment routes than default products; see our post on the CRA product class implementing regulation.

Penalties. Article 64(2) sets administrative fines of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, for non compliance with Annex I and with Articles 13 and 14.

Where reports go. The Commission says manufacturers report once through ENISA's Single Reporting Platform, operational from 11 September 2026. ENISA's page notes the platform was upgraded to version 1.2.1 on 20 October 2026. Our post on the Single Reporting Platform covers registration.

The RED cybersecurity delegated act, Regulation (EU) 2022/30

Most connected devices are also radio equipment. Delegated Regulation (EU) 2022/30 activates the essential requirements in Article 3(3)(d), (e) and (f) of the Radio Equipment Directive for internet connected radio equipment (network harm, personal data and privacy, and fraud protection for money transfers). Its original application date of 1 August 2024 was replaced with 1 August 2025 by Delegated Regulation (EU) 2023/2444. You may already hold RED evidence for a product that will need CRA evidence in 2027; treat them as one evidence file with two indexes.

ETSI EN 303 645

ETSI EN 303 645 (we read V3.1.3, dated September 2024) is the European baseline standard for consumer IoT security. Its provisions run from 5.1, no universal default passwords, through 5.2, a means to manage reports of vulnerabilities (provision 5.2-1 requires a public vulnerability disclosure policy), and 5.3, keeping software updated (provision 5.3-13 requires the manufacturer to publish the defined support period), to secure storage of sensitive security parameters, secure communication, minimised attack surface, software integrity (5.7), personal data security and resilience to outages. It is not a law by itself, but national schemes and retailer programs reference it, and its provisions line up closely with the UK PSTI requirements and with much of CRA Annex I.

UK PSTI regime

The UK government's guidance says the consumer connectable product security regime came into effect on 29 April 2024, under Part 1 of the Product Security and Telecommunications Infrastructure Act 2022 and the 2023 security requirements regulations. The three requirements are: passwords must be unique per product or set by the user; the manufacturer must publish how to report security issues; and the manufacturer must publish the minimum period for which the product will receive security updates. Our PSTI year one review goes deeper.

United States

• FCC Cyber Trust Mark. The FCC adopted rules in March 2024 for a voluntary cybersecurity labelling program for wireless consumer IoT products. The archived FCC page we read describes a "U.S. Cyber Trust Mark" logo with a QR code linking to a registry that shows details such as the product's support period and whether updates are automatic, and names a lead administrator. The live FCC page refused our fetch (HTTP 403), so check it for the program's current status before you plan a label.
• NIST IR 8425. NIST's profile of the IoT core baseline for consumer IoT products, developed as part of NIST's response to Executive Order 14028, describes the cybersecurity capabilities commonly needed for home and personal IoT products.
• California Civil Code 1798.91.04 (SB 327). Since 1 January 2020, a manufacturer of a connected device sold in California must equip it with reasonable security features appropriate to its nature and function. For devices with authentication outside a local network, a unique password per device, or forcing a new credential before first access, is deemed reasonable. See our SB 327 enforcement update.
• CISA's 2026 SBOM minimum elements. CISA, with NSA, FBI and international partners, published the 2026 Minimum Elements for a Software Bill of Materials, which updates and replaces NTIA's 2021 minimum elements. If a US customer asks for an SBOM, this is the current reference, not the 2021 list.

Germany's BSI TR-03183

BSI describes Technical Guideline TR-03183 as its interpretation of cyber resilience requirements, written to prepare for the CRA. Part 2 sets formal and technical SBOM requirements (version 2.1.0 adds a mapping to SPDX and CycloneDX fields) and Part 3 covers vulnerability reports and notifications. It is a detailed public reading of what a CRA grade SBOM looks like.

How teams do it today and where it breaks

Common approaches look like this. Each works up to a point.

A spreadsheet per regulation. Compliance keeps a CRA tab, a PSTI tab and a RED tab. It breaks because the rows describe the company, not the build, so when a CVE lands it cannot tell you which firmware versions are affected.

A source tree SBOM. Someone runs an SBOM tool against the application repository and calls it done. It misses the kernel, bootloader, C library, BusyBox, vendor blobs and whatever the board support package pulled in.

An SBOM per release, stored as a file. Better: the build produces an SBOM and it goes into an artifact store. It breaks when nobody re-matches old SBOMs against new advisories. A 2026 build still on shelves in 2030 needs the same scrutiny as today's.

Supplier components as a black box. If you never asked the module or SDK vendor for an SBOM, Article 13(5) due diligence is hard to show.

A disclosure inbox, not a process. Triage is ad hoc and nobody owns the "actively exploited" call. Article 14's clock starts at awareness, so define it in writing.

Support period as a marketing number. The UK statement of compliance says five years, the website says "regular updates", and engineering has no plan to keep the 2026 kernel branch alive until 2031. Annex II and PSTI both make that number public.

The common failure is that each rule is answered separately, by a different person. Invert it: build evidence from the product outward, then map it to each rule.

Step by step: build the map, with or without Safeguard

These steps work with any tooling. Where a step has a template, copy it.

1. List what you ship, as products and versions

Start with a product register: one row per product and firmware line, with markets and CRA category (default, Annex III Class I or II, or Annex IV critical).

Template:

2. Produce an SBOM from the build that ships

Generate the SBOM from the image build, not from a source tree. If you build with Yocto, its documentation says the OpenEmbedded build system generates SPDX output by default through the create-spdx class, with an SPDX JSON file for each image in the deploy directory. Buildroot and vendor SDKs have their own routes. For containers in your cloud backend, generate SBOMs from the images you deploy.

Then check the SBOM against the CRA's minimum (top level dependencies at least) and against the 2026 CISA minimum elements or BSI TR-03183-2 if a customer asks for those. Validate format conformance with a schema validator before you store it.

Keep one SBOM per shipped firmware version, tied to the version string a device reports. During an incident, that join is what you will query; our post on SBOMs in incident response shows why, and IoT firmware SBOM requirements goes deeper on firmware.

3. Map each rule to evidence you already produce

This is the core of the job. The crosswalk below maps common asks across the rules covered above to one piece of evidence each. Use it as a starting point and check every row against the primary text for your products.

Four rows (SBOM, disclosure policy, support period, update mechanism) answer most of every regime. Build those well and the rest is indexing.

4. Re-match old builds every day

Store the SBOMs somewhere that re-matches them against new advisories continuously, including KEV additions and EPSS changes. The question "which of our shipped builds contain this version" must be answerable in minutes. If you do this by hand, schedule it daily and keep the query script under version control.

5. Write down the Article 14 runbook

Define, in writing:

• Who decides "actively exploited". Article 3 of the CRA defines an "actively exploited vulnerability" as one for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. Record the evidence you relied on.
• What counts as "becoming aware". A KEV listing, a credible researcher report with evidence of exploitation, a customer incident, your own telemetry.
• Which CSIRT receives your reports under Article 14(7), worked out now.
• Who holds the ENISA platform accounts, including backups.

Clock template, filled at the moment of awareness:

6. Decide, per finding, whether it affects the device

Not every CVE in a component is exploitable in your product. A vulnerable function may be compiled out, the service may not be enabled, or the attack may need local access to a sealed device. Record those decisions as VEX statements (OpenVEX or the CSAF VEX profile) so customers, retailers and regulators can see why you did or did not ship a fix. CSAF 2.0, published by OASIS, defines both the advisory format and a VEX profile; see our VEX guide.

Be careful with "not affected". An unreachable function in today's configuration may become reachable after a feature update. Re-check VEX decisions on every release.

7. Gate releases on the evidence

Add release checks that fail when the evidence is missing or a rule is broken: no SBOM for the build, an unresolved critical or KEV listed vulnerability without a recorded exception, a copyleft license where your policy forbids it. A release gate is the cheapest way to make sure the four evidence rows exist for every build.

8. Ask suppliers for what you cannot see

For modules and SDKs delivered as binaries, ask the supplier for an SBOM and their vulnerability handling commitments, and record the answer. That record is part of your Article 13(5) due diligence.

9. Publish what the rules ask you to publish

Disclosure policy and contact, support period, and fixed vulnerability information under Annex I Part II(4). One common pattern is a single product security page linked from the product documentation.

Which products are in scope?

Under the CRA, "products with digital elements" made available on the EU market are in scope unless a sectoral regime excludes them (for example medical devices and certain vehicles). For an IoT maker, assume the device, its firmware and the companion app are in scope, and check whether your cloud backend counts as remote data processing tied to the product. Annex III and IV decide whether a product needs more than self assessment.

What goes in a CRA grade SBOM for firmware?

The legal minimum is top level dependencies in a machine readable, commonly used format. For firmware, aim higher: kernel, bootloader, C library, crypto libraries, vendor blobs (named even if opaque) and application packages, with package URLs or CPEs where available. BSI TR-03183-2 and CISA's 2026 minimum elements give field level detail. Include hashes to tie the SBOM to a specific image.

Illustrative scenario: a smart home maker's first CRA report drill

This is a composite example, not a customer. The company and every number below are invented example inputs you can replace with your own.

Company A makes three products sold in the EU, UK and US: an indoor camera, an outdoor camera and a home hub. The cameras run embedded Linux built with Yocto; the hub runs an RTOS plus a Linux companion processor. Example inputs: 3 firmware lines, about 40 firmware builds a year, 6 hardware suppliers, a product security team of 2.

The trigger. In September 2026, Company A's head of product security sets a goal: run a CRA reporting drill this quarter, using an already patched library vulnerability as the test case.

Week 1: register and SBOMs. The team builds the product register from step 1. Both cameras map to Annex III Class I as security cameras; the hub needs a legal read against Annex III item 16. They enable create-spdx in the Yocto builds and regenerate SBOMs for every firmware version still in support. For the RTOS image, the vendor SDK does not emit an SBOM, so they start with a manually maintained component list and a supplier request.

Week 2: the crosswalk. Compliance and product security fill the step 3 table together. Two gaps appear: the support period published in the UK statement of compliance (five years) differs from the one on the website (none stated), and the disclosure contact on the website is a general support address.

Week 3: the drill. The team picks an example vulnerability in a crypto library that affected older builds and treats the day of the drill as the awareness date. Their own targets, as example inputs: affected builds identified in one hour, early warning drafted in four.

What they learn, in qualitative terms. Affected build identification is fast for the Yocto lines and slow for the RTOS hub, because its component list is manual. The early warning needs the Member States where each product is sold, which sales operations owns. The hub's VEX statement needs a firmware engineer to confirm a function is compiled out.

What they change. Sales operations adds a market field to the product register. Firmware engineering adds an SBOM check to the release pipeline. Compliance aligns the support period across all published documents.

The scenario reports no outcome numbers because none exist; the point is what to rehearse and where gaps tend to hide.

How Safeguard does this

Everything in this section comes from Safeguard's offering documentation and docs.safeguard.sh. Each step links the docs page it relies on. Snippets are shown as the docs print them; we did not run them for this post.

1. Turn on the frameworks you sell under. In Compliance (GA), open Compliance › Manage, then the Frameworks tab, and switch on the frameworks that apply. Safeguard's framework library has pages for the EU Cyber Resilience Act, ETSI EN 303 645 and IEC 62443-4-2, among many national and industry frameworks. The frameworks page notes that choosing a framework "does not certify compliance".

2. Connect the builds as products and projects. In ESSCM, Integrations lets you connect source repositories (GitHub, GitLab, Bitbucket, generic Git), container registries (Amazon ECR, Docker Hub, OCI registries and others) and file uploads, per the Generate SBOM docs. SBOM generation and analysis (GA) and software composition analysis with deep transitive dependency scanning (GA) build the inventory. For firmware, bring the SBOM your image build already produces, such as a Yocto SPDX file; the docs do not describe unpacking firmware binaries.

3. Scan an SBOM you already have, or a directory or image, from the CLI. The CLI usage page shows these forms for the Safeguard CLI (GA):

   # An SBOM you already have (SPDX or CycloneDX, detected automatically)
   safeguard scan --sbom sbom.json
   
   # A local directory
   safeguard scan --dir .
   
   # A container image
   safeguard scan --image nginx:latest
   

   Results are written as JSON files under ./output by default. The docs say that scanning from the interactive terminal while signed in uploads the SBOM and findings to the platform, "never your source". The local runner (GA) suits teams that will not grant repository access.

4. Validate the SBOM format before you store it. The same CLI page documents a validator for CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents:

   safeguard validate sbom.json --strict -o report.json
   

5. Read the CRA scan requirements against each product. On the EU CRA framework page, Safeguard lists the requirements a scan decides for each product: an SBOM of top level dependencies (Annex I Part II(1)), a documented component set, vulnerability remediation without delay with exact component versions (Part II(2)), a coordinated disclosure contact carried in the composition documents, component integrity hashes, supplier attribution per component (Article 13 due diligence) and identifiable, timestamped technical documentation (Article 31 and Annex VII). The Controls tab adds catalog controls you evidence with uploads, policies or attestations, and the Policies tab offers CRA templates, including coordinated vulnerability disclosure, SBOM management and incident reporting. The ETSI EN 303 645 page does the same for provisions 5.2, 5.3 and 5.7. A framework's readiness score, the frameworks page says, is "Safeguard's assessment of what it can see. It is not an audit opinion or a certification."

6. Re-match every build daily and rank what matters. Vulnerability management (GA) re-evaluates projects daily as new CVEs are published, per the Vulnerabilities docs, drawing on NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. Each shows CVSS, EPSS, exploitation status, affected and fixed versions and reachability. Reachability analysis (GA) weighs call paths, runtime context and configuration. The Exploitable category flags known active exploitation: the first input to your "actively exploited" decision, not the decision itself.

7. Record "not affected" and "accepted" decisions with expiry. From a vulnerability, Mark False Positive takes a justification and goes for approval where policy requires it; Accept Risk takes a business justification and an expiration date and goes for approval. CSAF and VEX upload (GA) lets you bring CSAF or VEX files into the platform through Integrations › Upload, per the Generate SBOM docs, so your own VEX statements and supplier advisories sit next to the SBOMs they describe.

8. Gate releases on the evidence. Policies and gates (GA), per the Policies and Gates docs, let you write conditions such as no critical CVEs, no actively exploited CVEs or license rules, and attach an action. Block fails the gate, Warn passes with a warning naming the policy, and Notify passes and sends a notification. Approval runs through exceptions: a developer requests one with a business justification and an expiration date, approvers decide, and the audit trail records it. In CI, the docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   which fails the CI job when the named gate fails, with policy outcomes switched on for your workspace. License compliance (GA) can sit in the same gate.

9. Ask suppliers for SBOMs and track the answers. TPRM (GA), the Third Party Risk Manager, sends SBOM requests to vendors singly or in bulk, tracks status from Sent to Validated or Rejected, sends reminders, and on receipt validates format and completeness and runs a vulnerability scan, per the SBOM requests docs. That record supports Article 13(5) due diligence.

10. Open fix pull requests where you own the code. Autonomous remediation (GA) can open tested, policy gated pull requests that move a dependency to a fixed version, one repository or in bulk. It ships switched off, with every category set to Manual. For firmware, this helps on application layers and companion services built from package manifests. Kernel, bootloader and vendor SDK updates still go through your build system and your suppliers.

11. Publish what the rules ask you to publish. Trust Center (GA), configured on Compliance › Trust Center per the Trust Center setup docs, publishes a public page with the frameworks you choose and their status, live control status, a security contact email for vulnerability reports, and dated updates that can be posted as a Security advisory. Publishing is always an explicit action.

The matching use case page is Comply with global regulations.

What to measure

A checklist to track your own program. These are things to measure, not results we claim.

• Share of firmware versions still in support that have a stored, validated SBOM tied to the device version string.
• Time from a KEV listing or credible exploitation report to a list of affected products and builds, measured in your drills.
• Time from awareness to a drafted early warning, measured in drills.
• Share of supplier modules with an SBOM or a recorded refusal.
• Number of open Accept Risk and "not affected" decisions past their expiry date (target zero).
• Consistency of the published support period across the CE file, UK statement of compliance, Annex II user information, website and any FCC registry entry.
• Date of the last Article 14 drill and the gaps it found.

What Safeguard does not do

• It does not decide whether a vulnerability is actively exploited. It shows KEV status, EPSS and an Exploitable category. The legal judgement under Article 14, and the evidence behind it, is your team's.
• It does not file reports with ENISA or national CSIRTs. You submit through the Single Reporting Platform under your own registered representatives.
• It does not analyse firmware binaries according to the docs we read. Bring the SBOM your build system produces, or scan source directories and container images. Opaque vendor blobs stay opaque unless the supplier tells you what is inside.
• It does not sign your EU declaration of conformity, choose your conformity assessment route or certify compliance. Readiness scores are Safeguard's view of what it can see, not an audit opinion.
• It does not set your support period or ship your over the air updates. Those are product and engineering decisions and infrastructure.
• It does not replace a notified body or a test lab for RED, CRA Class II or Annex IV products, or for an FCC label.
• It does not fix code it cannot reach. Kernel and bootloader patches, vendor SDK updates and module firmware come from your build system and suppliers.

Common mistakes

1. Starting the 24 hour clock at confirmation instead of awareness. Write down what "aware" means and log the timestamp the moment the trigger arrives.
2. Using a source repository SBOM as the product SBOM. The device ships an image; the SBOM must describe the image.
3. Forgetting builds that are still on shelves. The support period, not the release calendar, decides which SBOMs you must keep re-matching.
4. Different support periods in different documents. Annex II, PSTI and the FCC registry each publish it. Pick one number and generate every document from it.
5. Treating KEV as the definition of "actively exploited". It is strong evidence. Your own telemetry, a customer incident or a credible researcher report can also make you aware.
6. Letting VEX "not affected" decisions live forever. Re-check them each release; add an expiry.
7. Ignoring the user notification in Article 14(8). The regulator is not the only audience.

FAQ

What are the CRA reporting deadlines for an actively exploited vulnerability?

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. Severe incidents have a final report due within one month of the incident notification.

Where do I submit CRA notifications?

Through ENISA's CRA Single Reporting Platform, addressed to the CSIRT designated as coordinator in the Member State of your main establishment in the EU, or under the fallback order in Article 14(7) if you have no EU establishment. The Commission says the platform has been operational since 11 September 2026.

Does the CRA require an SBOM to be published?

Annex I Part II(1) requires you to draw up an SBOM covering at least top level dependencies, in a commonly used machine readable format. It is part of the technical documentation. The regulation does not require you to publish it to the public; check with counsel whether customers or authorities in your case will ask for it.

Are smart cameras and smart locks "important products" under the CRA?

Annex III Class I lists "smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems". Class I products have stricter conformity assessment options than default products. Confirm your product's classification against the Commission's implementing regulation.

How long must an IoT maker support a device under the CRA?

Article 13(8) sets a support period of at least five years unless the product is expected to be in use for less, in which case it matches the expected use time. Security updates must remain available for at least 10 years after issue or for the rest of the support period, whichever is longer.

How does UK PSTI compare with the CRA for connected devices?

PSTI, in effect since 29 April 2024, has three requirements: unique or user set passwords, a published way to report security issues, and a published minimum security update period. All three overlap with CRA Annex I and Annex II, which go much further, including SBOMs and Article 14 reporting.

Do US rules require an SBOM for consumer IoT?

Not for consumer devices generally. California's connected device law requires reasonable security features, and the FCC's Cyber Trust Mark is voluntary. CISA's 2026 SBOM minimum elements are the reference when a US customer or contract asks for one.

Does a Safeguard readiness score mean we comply with the CRA?

No. Safeguard's docs say a readiness score is its assessment of what it can see, not an audit opinion or a certification. Conformity is established through the CRA's assessment procedures and your declaration of conformity.

Where fixes come from

Most of the CRA's vulnerability handling burden lands on the open source components you compile into firmware, apps and backend services. Where you own the build, the faster you move a component to a fixed version, the shorter the window you have to report and explain.

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 Safeguard CLI session. It installs the CLI, opens the interactive terminal, asks it to fix a lodash CVE in a repository, and shows it reading the finding and advisory, asking before any command that changes something, editing package.json, running npm install and npm test with approval, and printing a summary without pushing anything. For a device maker, the same flow fits the companion app and cloud services.

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, then scans from the terminal. This is the route for firmware teams whose source cannot leave the build network: the scan runs locally and only results go to the platform.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. During an Article 14 drill, that lets someone on the compliance side ask plain questions about which products contain a component, without learning the console first.

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

Quick check

Sources

• Regulation (EU) 2024/2847, Cyber Resilience Act, Internet Archive copy of the EUR-Lex page (EUR-Lex returned an empty 202 on 25 Oct 2026)
• European Commission: Cyber Resilience Act reporting obligations
• European Commission: Cyber Resilience Act policy page
• ENISA: Cyber Resilience Act and the Single Reporting Platform
• Delegated Regulation (EU) 2022/30, RED cybersecurity, Internet Archive copy of the EUR-Lex page
• Delegated Regulation (EU) 2023/2444, Internet Archive copy of the EUR-Lex page
• UK government: The UK Product Security and Telecommunications Infrastructure (PSTI) product security regime
• FCC: Cyber Trust Mark, Internet Archive copy
• NIST IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products
• California SB 327, Civil Code 1798.91.04, Internet Archive copy
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: SBOM resources
• BSI: Technical Guideline TR-03183, Cyber Resilience Requirements
• OASIS: Common Security Advisory Framework Version 2.0
• Yocto Project: Creating a Software Bill of Materials
• ETSI EN 303 645 V3.1.3, Internet Archive copy of the ETSI PDF (etsi.org returned 403)
• Safeguard docs: EU Cyber Resilience Act framework
• Safeguard docs: ETSI EN 303 645 framework
• Safeguard docs: IEC 62443-4-2 framework
• Safeguard docs: Compliance frameworks
• Safeguard docs: Compliance
• Safeguard docs: Generate SBOM
• Safeguard docs: Vulnerabilities
• Safeguard docs: Policies and Gates
• Safeguard docs: CLI usage
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: Trust Center setup
• Safeguard: Comply with global regulations use case

To try the flow yourself, download Safeguard or read the Safeguard docs.

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