Does the Cyber Resilience Act apply to products you already sell?

Partly. Products you placed on the EU market before 11 December 2027 do not have to meet the Cyber Resilience Act's essential requirements unless you substantially modify them after that date (Article 69(2)). But the Article 14 duty to report actively exploited vulnerabilities and severe incidents has covered them since 11 September 2026 (Article 69(3)), and new units of an old model shipped after 11 December 2027 must comply in full.

This post is a practical reading of Regulation (EU) 2024/2847 (the Cyber Resilience Act, or CRA), the European Commission's guidance on its application (C(2026) 5252, published 27 July 2026) and the Commission services' CRA FAQ (version 1.4, 4 September 2026), as of 23 October 2026. It is not legal advice. The guidance and FAQ are non binding, only the Court of Justice of the EU can interpret the Regulation authoritatively, and your counsel should have the final word on your products.

Key takeaways

• The cut off is per unit, not per model. The Commission's FAQ (entry 7.2) says the CRA applies to individual products, not product types. Units placed on the market before 11 December 2027 are outside the essential requirements; units of the same model placed after that date are not.
• Reporting has no grandfather clause. Article 69(3) applies Article 14 to "all products with digital elements" in scope, including those placed on the market before 11 December 2027. Since 11 September 2026 you owe a 24 hour early warning, a 72 hour notification and a final report for those products too.
• Reporting outlives the support period. The Commission's guidance (paragraph 210) says reporting continues after a product is no longer supported, while the vulnerability handling duties in Annex I Part II do not apply to pre December 2027 products or to products past their support period.
• Security updates are generally not substantial modifications. Recital 39 and guidance paragraph 108 say an update whose purpose is to reduce risk, and which does not change the intended purpose or add new risk, does not pull an old product into scope. Feature updates that change intended functions can.
• A substantial modification to a legacy product is assessed proportionately. Guidance paragraph 124 says the original manufacturer's obligations are limited to the modified parts unless the change affects the product's cybersecurity as a whole.
• No legal SBOM duty for legacy units, but you need one anyway. The SBOM requirement in Annex I Part II point (1) attaches to products under the CRA. Without a per version inventory, you cannot meet a 24 hour clock on an old product line.
• Remote back ends count. A product includes its remote data processing solutions (Article 3(1)), and the guidance says this is also true for reporting under Article 14.

The CRA timeline in one table

The two dates people mix up are 11 September 2026 and 11 December 2027. The first switched on reporting for everything already in the field. The second switches on the design, documentation, vulnerability handling and conformity duties, but only for units placed on the market from that day.

What "placed on the market" means for a product you already sell

Everything in this post turns on one definition. Article 3(21) defines placing on the market as "the first making available of a product with digital elements on the Union market". Article 3(22) defines making available as supply "for distribution or use" in the course of a commercial activity, paid or free.

Hardware: every unit has its own date

The Commission's FAQ entry 7.2 applies the Blue Guide principle that EU product legislation applies to individual products, not to types. Its example is a manufacturer that builds 10,000 routers to a type that does not comply with the CRA and places them on the market before 11 December 2027. Those units can keep moving through distribution, even if they have not reached an end user. But the manufacturer "may not produce another 5 000 copies" of that router and place them on the market after 11 December 2027.

FAQ entry 6.4 says the same thing from the other side: "legacy types or models are not exempted" if new units are placed on the market after the date of application. And FAQ entry 7.5 confirms distributors do not have to bring pre December 2027 stock into compliance unless they substantially modify it.

So for a hardware maker the question is never "is this model covered?" It is "when did this specific unit leave my control onto the EU market?" Your shipping records, not your product catalogue, answer it.

Software: copies share a date, variants do not

Standalone software is handled differently. The Commission's guidance (paragraph 14) says a software product is placed on the market when its manufacturing phase is complete and it is first supplied in the EU, and that multiple copies of the same software are placed on the market at the same time, whenever each copy is later sold or downloaded. Variants that differ in included components, configuration or enabled features, such as builds for different operating systems, are distinct products with their own dates.

Paragraph 15 adds that later iterations are only newly placed on the market if they are substantial modifications. Its Example 2 has version 1.0.0 released on 1 January 2028 and a non substantial 1.0.1 a fortnight later: both count as placed on the market on 1 January 2028.

Read together, a desktop application first released in 2025 and maintained with ordinary patch and minor releases keeps its 2025 placing date indefinitely, until a release qualifies as a substantial modification. That is why the substantial modification test matters so much for software vendors.

Hardware with embedded software

The guidance limits the software rules in paragraphs 13 to 15 to standalone software. Where software ships combined with hardware, such as a router's firmware, the unit rules apply. The FAQ adds a footnote that firmware may fall in scope on its own when it is placed on the market separately, for example as a downloadable image sold or distributed independently.

Which CRA duties already apply to products placed on the market before 11 December 2027?

Article 69(2) is the general rule: products placed on the market before 11 December 2027 "are subject to the requirements of this Regulation only if, from that date, those products are subject to a substantial modification." Article 69(3) is the exception for Article 14.

Here is what that means duty by duty for a unit placed on the market before 11 December 2027 and never substantially modified.

FAQ entry 5.3 states the practical consequence directly. For pre December 2027 products, manufacturers "are required to notify the vulnerability or incident but are not required by the CRA to comply with other obligations, e.g. in relation to vulnerability handling." The Commission even acknowledges why: tooling to scan old software may no longer exist, build environments may be impossible to recreate, and the people who knew the codebase may have left.

That is a relief and a trap at the same time. You are not legally obliged to patch a 2024 product under the CRA. But you are obliged to tell your CSIRT and ENISA, within 24 hours of becoming aware, that it is being exploited, and to tell your users what to do about it. Telling users "there is no fix" is a hard message to send, and other laws (product liability, contract, consumer law) still apply.

What does "within scope" exclude?

Article 69(3) only reaches products that "fall within the scope of this Regulation". The CRA's scope covers products with digital elements whose intended purpose or reasonably foreseeable use includes a data connection to a device or network. Products already covered by certain sector rules, such as medical devices and motor vehicles, are carved out by Article 2. If a product line was never in scope, Article 69(3) does not pull it in. Check scope first, then dates.

Do reporting duties cover legacy products still in the field today?

Yes. This is the part of the CRA that is already live for every in scope product you have ever placed on the EU market.

What the duty is

Article 14(1) requires a manufacturer to notify "any actively exploited vulnerability contained in the product with digital elements that it becomes aware of", simultaneously to the CSIRT designated as coordinator and to ENISA, through the Single Reporting Platform. Article 3(42) defines an actively exploited vulnerability as one with "reliable evidence that a malicious actor has exploited it in a system without permission of the system owner".

Article 14(3) adds severe incidents having an impact on the security of the product. Article 14(5) treats an incident as severe if it affects, or is capable of affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it led or could lead to malicious code being introduced or executed in the product or in a user's systems.

The clocks

For a legacy product, the final report trigger is worth thinking about. The 14 day window starts when a corrective or mitigating measure is available. If you never ship a fix for a 2023 device, the mitigating measure may be a configuration change, a firewall rule, or advice to disconnect, and that is what you report.

No date limit going backwards, and none going forwards

The text of Article 69(3) sets no earliest placing date. A product first sold in 2015 that is in scope and still in use is covered. Going forwards, the Commission's guidance (paragraph 210) says reporting obligations "continue to apply after a product with digital elements is no longer supported", unlike the vulnerability handling duties that end with the support period.

When the clock starts

FAQ 5.3 notes that the duty applies upon becoming aware after the reporting requirements entered into application. The guidance (paragraph 213) puts "becoming aware" at the point where, after an initial assessment, you have "a reasonable degree of certainty" that a vulnerability in your product is being actively exploited or that a severe incident compromised its security. Something you learned in March 2026 and did nothing about is not retroactively reportable on 11 September, but the first new piece of reliable evidence after that date can start the clock.

Who receives it and what happens if you are late

Article 14(7) routes notifications to the CSIRT coordinator in the Member State of your main establishment in the EU, with fallbacks for manufacturers established outside the Union (authorised representative, importer, distributor, then where most users are). ENISA says the platform's initial operating capability went live on 11 September 2026, with submissions made by Assigned Representatives you register in advance.

Article 64(2) sets fines for breaching Article 14 of up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Article 64(10) exempts microenterprises and small enterprises from fines for missing the 24 hour early warning deadlines in Article 14(2)(a) and 14(4)(a). It does not exempt them from the 72 hour notification or the duty itself.

The sibling post on whether you must report an exploited flaw in an open source component covers the third party component question in depth. For the platform itself, see the ENISA Single Reporting Platform, and for the general clock, CRA Article 14 reporting.

What counts as a "substantial modification", and does a security update count?

This is the question that decides whether an old product stays outside the essential requirements.

The definition

Article 3(30) defines a substantial modification as a change to the product after its placing on the market which either affects its compliance with the essential cybersecurity requirements in Annex I Part I, or results in a modification to the intended purpose for which it was assessed.

For a pre December 2027 product, there was no CRA assessment. The guidance deals with this through the general concept in recital 41 and Section 2.1 of the Blue Guide: a product that has been significantly changed is treated as new if its original performance, purpose or type is modified, the nature of the hazard has changed or the level of risk has increased.

What recital 39 says about updates

Recital 39 gives three categories:

1. Security updates. A security update "designed to decrease the level of cybersecurity risk" that does not change the intended purpose is not a substantial modification. The recital says this "usually includes situations where a security update entails only minor adjustments of the source code."
2. Minor functionality updates. A visual enhancement or "the addition of new pictograms" should not generally be a substantial modification.
3. Feature updates. Where a feature update modifies the original intended functions or the type or performance of a product, it may be substantial, because new features "typically" broaden the attack surface. The recital's example is adding a new input element that requires input validation.

How the Commission's guidance tests it

Section 4.3 of the guidance turns recital 39 into a working test. Paragraph 107 makes the key point: the assessment is not about the scale or complexity of the change but about "its potential adverse impact on the cybersecurity risk profile". A one line feature can be substantial; a large refactor can be not substantial.

Paragraph 110 gives four questions to ask of any update. Does it:

• introduce new threat vectors, such as additional interfaces, communication channels, execution environments or external dependencies;
• enable new attack scenarios;
• change the likelihood of previously identified attack scenarios, for example by lowering the effort to exploit or weakening safeguards;
• change the potential impact of previously identified attack scenarios?

If none apply, and the assumptions in your risk assessment remain valid, paragraph 111 says the update is "likely" not a substantial modification.

The guidance's examples, as a decision table

Two patterns stand out. First, the "security reasons" label does not protect an update that changes data flows or adds new external dependencies (paragraph 109, Examples 49 and 50). Second, for products assessed under the CRA, anything you foresaw and assessed in advance is much less likely to be substantial (Examples 42, 43 and 48). For legacy products with no CRA risk assessment, you have less to point to, so document the reasoning for each update now.

What happens if you substantially modify a legacy product

The guidance (paragraph 122) says the substantially modified product is treated as newly placed on the market, and the original manufacturer stays the manufacturer. For products placed on the market before 11 December 2027, paragraph 124 adds an important limit: such a modification "does not, in itself, require the manufacturer to bring the entire product" into full compliance, unless the modification negatively affects the cybersecurity of the product as a whole. Where it does not, obligations are limited to the substantially modified parts.

Paragraph 123 also lets you reuse existing documentation and tests for unchanged parts, with conformity assessment focused on what changed.

When someone else modifies it

Article 22 says any person, other than the manufacturer, importer or distributor, who substantially modifies a product and makes it available is a manufacturer for the purposes of Articles 13 and 14, limited to the affected part unless the change affects cybersecurity "as a whole". Article 21 does the same for importers and distributors. The guidance (paragraph 120) separates this from integration: if you buy components and build a new product, you are simply that new product's manufacturer, in full.

For refurbishers and repairers, the guidance (paragraphs 93 to 95) says repair, maintenance and refurbishment do not necessarily create a substantial modification, and replacing a worn part with a better performing one does not in itself trigger one.

What about software updates and SaaS components for older devices?

Keep shipping security fixes, and keep them separate

Nothing in the CRA stops you patching a legacy product, and the guidance is clear that patching normally does not change its status. The practical risk is the bundled release, where a security fix rides along with a new feature. If the feature passes the substantial modification test, the whole release is a substantial modification, and the modified parts come into scope.

For products under the CRA, Annex I Part II point (2) already requires that "new security updates shall be provided separately from functionality updates" where technically feasible. For legacy products it is not a legal duty, but it is the simplest way to keep the security channel clean. Run two release trains: a security branch that only carries fixes, and a feature branch whose changes you assess against the paragraph 110 questions before release.

Remote data processing is part of the product

Article 3(1) defines a product with digital elements as a software or hardware product "and its remote data processing solutions". Article 3(2) defines remote data processing as data processing at a distance, designed by or under the responsibility of the manufacturer, "the absence of which would prevent the product with digital elements from performing one of its functions". The companion app's API that a smart lock needs to unlock is a typical case.

The guidance (paragraph 178) says the manufacturer must consider the product as a whole including its remote data processing solutions, and explicitly includes reporting under Article 14. So an exploited vulnerability in the cloud back end of a 2022 device can be a reportable event for that device today.

The guidance also narrows the concept (paragraph 182): internal systems such as HR, payroll, CRM, CI/CD pipelines and the distribution of security updates to edge locations are not remote data processing, and neither are penetration testing or red teaming systems.

Rearchitecting the back end can be a substantial modification

The guidance's Example 55 describes a manufacturer that rearchitects the cloud back end of an industrial machine, adding new APIs and data flows, in a way that qualifies as a substantial modification. That example is about the support period of a product already under the CRA, but the logic carries over. If you plan a platform migration that changes how older devices talk to your cloud after 11 December 2027, run it through the substantial modification test before you ship, not after.

Do you need an SBOM for products already on sale?

What the law requires

Annex I Part II point (1) requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products." Article 3(39) defines an SBOM as a formal record of components and their supply chain relationships. Article 13(25) lets market surveillance authorities request SBOMs, and Article 13(24) lets the Commission specify the format and elements by implementing act.

Because Annex I Part II does not apply to units placed on the market before 11 December 2027 (Article 69(2), FAQ 5.3, guidance paragraph 210), there is no CRA duty to produce an SBOM for those units. New units of the same model placed afterwards are a different matter, and so is any substantially modified version.

Why you need one anyway

Article 14 is the reason. If a customer reports that attackers are exploiting a flaw in a library, you have 24 hours to decide whether any of your products contain that library and whether the evidence shows exploitation in your product. Without an inventory per shipped version, you spend those hours rebuilding old firmware and grepping vendored directories.

The guidance (paragraph 39) also expects manufacturers placing pre CRA designs on the market after December 2027 to evidence vulnerability handling under Annex I Part II, which starts with that component inventory. If you plan to keep selling a model, you will need its SBOM by then.

For the format question and what tooling outputs, see EU CRA SBOM requirements.

What support period must you declare, and what happens to products past it?

For units placed on the market from 11 December 2027

Article 13(8) requires a support period that reflects how long the product is expected to be in use, and it "shall be at least five years", unless the product is expected to be in use for less, in which case it matches the expected use time. Article 13(9) requires each security update to remain available for a minimum of 10 years after issue, or for the rest of the support period if longer. Article 13(19) requires the end date, "including at least the month and the year", to be clearly specified at the time of purchase, and, where applicable, requires the product to display a notification telling users it has reached the end of its support period.

FAQ 4.5.3 shows how this works across a production run. A model placed on the market in January 2028 with five years of support can keep being sold by distributors after January 2033. But if the manufacturer makes 5,000 more units in 2030, those units need their own support period.

For legacy units

Units placed on the market before 11 December 2027 do not need a CRA support period. In practice, many customers will start asking for one in procurement anyway, and publishing an honest end of support date for older lines is good practice.

Substantial modifications and the support period

The guidance (paragraph 133) says a substantial modification requires a reassessment of the support period but "does not automatically result in the support period being reset, or even extended." If the expected use time was driven by hardware durability, as in the guidance's robot vacuum example (Example 54), a software feature update leaves the remaining support period where it was.

Which versions you must patch

Article 13(10) and recital 40 let a software manufacturer that has released substantially modified versions provide security updates only for the latest version, provided users of earlier versions can move to it free of charge without new hardware or software costs. Recital 40 also says that where a device cannot run the latest operating system it shipped with, security updates must continue for at least the latest compatible version. Article 13(11) lets you keep public archives of old versions as long as users are clearly told the risks of unsupported software.

After the support period ends

Two things stay true. Distributors can keep selling units already placed on the market (FAQ 4.5.3). And reporting under Article 14 continues (guidance paragraph 210). What ends is the Annex I Part II vulnerability handling duty.

How do you inventory which shipped versions are still in use and in scope?

This is the operational core. The aim is a register that answers, for any component and version, "which products and releases that we placed on the EU market contain it, how many units or installs are still active, and which are under the full CRA versus reporting only?"

Step 1: Build the product and release register

Start with a spreadsheet or database. One row per product variant and release, with these columns:

Step 2: Recover the source for each shipped release

Use your version control tags. This lists release tags with dates, oldest first:

git tag --list 'v*' --sort=creatordate \
  --format='%(refname:short) %(creatordate:short)'

Check out each release into its own directory without disturbing your main working copy:

for t in $(git tag --list 'v*'); do
  git worktree add "../releases/$t" "$t"
done

If your firmware or appliance builds were never tagged, start from the artifacts you actually shipped, such as images on your update server, and work backwards.

Step 3: Generate an SBOM per release

Use the OWASP CycloneDX generators for each ecosystem, from inside each release directory. These are the documented invocations:

# npm (uses package-lock.json)
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json

# Python, from a requirements file
cyclonedx-py requirements requirements.txt --output-file sbom.cdx.json

# Maven, aggregate for multi module builds (writes target/bom.json)
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

# Go modules
cyclonedx-gomod mod -json -output sbom.cdx.json

Old releases sometimes do not build anymore, which is exactly the problem the FAQ describes. Manifest and lockfile based generation often still works when a full build does not. For container based products, scan the shipped image itself. With the Safeguard CLI, the equivalent is:

safeguard scan --dir ./releases/v2.3.1
safeguard scan --image registry.example.com/gateway:2.3.1
safeguard scan --sbom ./releases/v2.3.1/sbom.cdx.json

Results land as JSON under ./output.

Step 4: Make every future release produce one automatically

A GitHub Actions workflow that builds an SBOM on every release tag and attaches it to the release keeps the register current:

name: release-sbom
on:
  push:
    tags: ['v*']
permissions:
  contents: write
jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - run: npm ci
      - run: npx @cyclonedx/cyclonedx-npm --output-file sbom-${{ github.ref_name }}.cdx.json
      - run: gh release upload "${{ github.ref_name }}" sbom-${{ github.ref_name }}.cdx.json --clobber
        env:
          GH_TOKEN: ${{ github.token }}

The release must exist before gh release upload runs; if you create releases in the same workflow, add that step first.

Step 5: Query across releases when the clock starts

With one SBOM per release in a folder, a single command answers "which releases contain this component, and at which version":

for f in sboms/*.cdx.json; do
  jq -r --arg f "$f" '.components[]? | select(.name=="openssl")
    | "\($f)\t\(.name)\t\(.version)"' "$f"
done

Join that output to your register and you know, within minutes, which affected releases are legacy (report only) and which are under the full CRA (report, then fix under Annex I Part II).

Step 6: Count what is still running

Placing dates tell you the legal status; install counts tell you the risk. Use update server logs, device check ins, licence activations or support contracts to estimate active units per release. A legacy release with zero active installs needs a note in the register. A legacy release with 40,000 devices online is where an exploited vulnerability will hurt, and where your Article 14(8) message to users must be ready.

What should a 90 day plan look like for a manufacturer with a large installed base?

Reporting has been live since 11 September 2026, so the first month is about being able to report. The next two are about reducing how often you will need to.

Keep the paperwork for each "not reportable" decision as well as each report. If a market surveillance authority asks later, the record of why you did not notify is as important as the notifications you made. The guidance on reachability analysis for CRA due diligence is useful here.

Common mistakes

• Assuming legacy means exempt. Article 69(3) puts every in scope product under Article 14 from 11 September 2026, whatever its age.
• Treating the model as the unit. The CRA applies per unit. A model launched in 2024 is not grandfathered for units built in 2028 (FAQ 7.2).
• Bundling features with security fixes. A security update on its own is generally not substantial. The same fix shipped with a new remote access feature may be.
• Believing "security" labels decide the test. The guidance's Examples 49 and 50 show security driven changes that are substantial because they alter data flows or add third party dependencies.
• Forgetting the back end. An exploited flaw in the cloud service a legacy device needs can be reportable for that device.
• Stopping reporting at end of support. The guidance (paragraph 210) says reporting continues after support ends.
• Waiting for the 24 hours to start before building an inventory. For an old product, generating SBOMs from scratch can take days, especially if the builds no longer run.
• Assuming the small business exemption removes the duty. Article 64(10) waives fines for missing the 24 hour early warning for micro and small enterprises. It does not waive the 72 hour notification, the final report, or the duty to inform users.
• Rearchitecting a cloud platform for older devices without a substantial modification review. Changes to APIs and data flows are what the guidance's tests target.

FAQ

Does the Cyber Resilience Act apply to products sold before 2027?

Only partly. Products placed on the EU market before 11 December 2027 are outside the essential requirements unless they are substantially modified after that date (Article 69(2)). But Article 69(3) applies the Article 14 reporting duties to them, and those have applied since 11 September 2026.

Do I have to report vulnerabilities in old products under the CRA?

Yes, if the vulnerability is actively exploited or a severe incident affects the product's security. Since 11 September 2026, Article 14 covers all in scope products, including those placed on the market before 11 December 2027. FAQ 5.3 confirms you must notify even if you cannot investigate the old code.

Is a security patch a substantial modification under the CRA?

Generally no. Recital 39 and the Commission's guidance (paragraph 108) say a security update that reduces risk without changing the intended purpose or introducing new risks is not a substantial modification. It can become one if it materially changes data flows, adds externally reachable interfaces or new dependencies (paragraph 109).

Can I keep selling an old model after 11 December 2027?

Units already placed on the market before that date can keep being sold by distributors without CRA compliance (FAQ 7.5). New units placed on the market from 11 December 2027 must comply with the CRA, even if the model was designed earlier (FAQ 7.2). The guidance (paragraphs 33 to 39) says a redesign is not always needed if a risk assessment shows the existing design is adequate.

Do I need an SBOM for products already on the market?

Not as a CRA legal duty for units placed on the market before 11 December 2027, because Annex I Part II does not apply to them. You need one in practice to meet the 24 hour reporting clock, and you will need it for any units of those models placed on the market after December 2027.

Does CRA reporting stop when my product's support period ends?

No. The Commission's guidance (paragraph 210) says reporting obligations continue after a product is no longer supported. What ends is the duty to handle vulnerabilities under Annex I Part II.

Does the CRA apply to SaaS?

Standalone SaaS that is not part of a product is not a product with digital elements, according to the Commission's FAQ. Cloud services that a product needs to perform one of its functions are remote data processing solutions and are part of that product (Article 3(1) and 3(2)).

If I add a new feature to an old product in 2028, does the whole product have to comply?

Only if the feature is a substantial modification, and even then the guidance (paragraph 124) says your obligations are limited to the modified parts unless the change affects the cybersecurity of the product as a whole.

Fix it without waiting for upstream

For a legacy product, the fastest way out of a reporting cycle is a corrective measure your users can actually install. Most of the work is in the open source dependencies inside those old releases.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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

For legacy products, the CRA questions come down to three things: which shipped releases contain a component, whether it matters there, and how fast a fix can reach users. Safeguard generates SBOMs in SPDX and CycloneDX, scans repositories, container images and SBOM files, shows which projects contain a given component and version, applies reachability analysis, and accepts CSAF and VEX uploads. Its compliance suite lists the EU Cyber Resilience Act among its frameworks. It does not decide whether a release is a substantial modification, and it does not file your Article 14 notification; those stay with your product and legal teams and your Assigned Representative on ENISA's platform.

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For legacy lines, that is how you generate inventories for old firmware images or customer specific builds that cannot leave your network.

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

The second demo is a real Safeguard CLI session. You ask it to fix the lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. On a legacy security branch, that is the loop that produces a fix-only release, which keeps the update on the right side of the substantial modification line.

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 lets you choose which tools Claude can use. When a 24 hour clock starts on an old product line, an analyst can ask in plain language which projects carry a component and version, while you keep control of what the assistant may do.

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

To try it, download Safeguard or read the CLI documentation. For how the Commission's guidance binds, see what C(2026) 5252 does and does not bind, and for inventory under pressure, SBOM incident response.

Quick check

Sources

• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act (official text)
• Regulation (EU) 2024/2847, Article 3 (definitions), as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Article 13, as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Article 14, as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Article 22, as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Article 64, as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Article 69, as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Article 71, as published in OJ L 2024/2847
• Regulation (EU) 2024/2847, Annex I, as published in OJ L 2024/2847
• Cyber Resilience Act, recital 39
• European Commission: guidance on the application of the CRA, C(2026) 5252 annex
• European Commission: new guidance to support timely Cyber Resilience Act implementation (27 July 2026)
• European Commission: FAQs on the Cyber Resilience Act, version 1.4
• European Commission: CRA reporting obligations
• ENISA: CRA Single Reporting Platform

Last reviewed: 23 October 2026. This post is general information, not legal advice; check the linked Commission and ENISA pages for the latest guidance.