The Cyber Resilience Act: What Software Teams Need to Know

The EU Cyber Resilience Act (CRA) came into force in October 2024. If your team ships software that runs on customer devices — desktop apps, server packages, container images, IoT firmware, SDKs, self-hosted platforms — you have until October 2027 to comply. Here is what the law actually requires, who it applies to, and what to start doing now.

TL;DR

Applies to software that runs on customer devices or infrastructure — not purely browser-based SaaS
Requires a continuously maintained SBOM, vulnerability disclosure within 24–72 hours of discovery, and no known exploitable vulnerabilities at release
Non-compliance means no CE mark and no legal sales in the EU — plus fines up to €15M or 2.5% of global turnover
Vulnerability reporting kicks in September 2026. Full compliance required by October 2027

What is the CRA?

The CRA is an EU regulation targeting "products with digital elements" — any software or hardware that can connect, directly or indirectly, to another device or network. Unlike earlier EU guidance that was advisory, this one has teeth: fines up to €15 million or 2.5% of global annual turnover, whichever is higher.

Products that do not comply cannot carry a CE mark, which means they cannot legally be sold in the EU.

Does it apply to your team?

The practical test is simple: does your customer run your software, or do they just use it through a browser?

If you ship a binary, a container image, an installable package, or anything that runs on the customer's own device or server — you are in scope. This covers desktop apps, mobile apps, server-side software, embedded firmware, IoT components, SDKs, and self-hosted platforms.

Purely browser-based SaaS — where all processing happens on your infrastructure and users never install anything — is generally outside the CRA's scope. That said, many teams fall into both categories depending on which product lines they offer.

Open-source exemption: software developed and distributed non-commercially is largely exempt. But if you are a commercial entity that ships open-source components inside products you sell, you are responsible for the security of those components. Your dependency inventory is now a compliance matter.

What does it require?

A living Software Bill of Materials

You must produce and maintain a machine-readable Software Bill of Materials (SBOM) covering your product's components — including third-party dependencies. It needs to stay accurate for the lifetime of the product, and be updated whenever the composition changes.

Teams relying on manual audits or one-off inventories will not be able to keep up with this. It needs to be automated.

Vulnerability reporting — fast

When you discover an actively exploited vulnerability, you must notify ENISA (the EU Agency for Cybersecurity) within 24 hours, with a fuller report within 72 hours. Remediation must follow without undue delay.

That 24-hour window is tight. Teams that cannot answer "which of our products are affected by this CVE?" in minutes — not days — will miss it. This is where blast-radius analysis matters.

No known exploitable vulnerabilities at release

Products must be designed with security from the outset. Specifically, you cannot ship a release that contains known exploitable vulnerabilities. Security updates must be delivered promptly and can be separate from feature releases.

For dependency-heavy software this means adding vulnerability checks to your release pipeline — not as a one-off audit, but as a gate.

Long-term support obligations

You must provide security updates for the expected lifetime of the product, or a minimum of five years. That creates a long tail of dependency management responsibility well beyond the initial release.

Key dates

October 2024 — CRA entered into force
September 2026 — Vulnerability and incident reporting obligations apply
October 2027 — All requirements apply; CE marking becomes mandatory

The September 2026 reporting deadline is less than 5 months away. If you do not yet have tooling in place to detect and disclose vulnerabilities quickly, that should be treated as urgent.

What to do now

Get a complete, continuously updated inventory of all dependencies across your products — including transitives
Add a vulnerability gate to your release pipeline so you cannot ship known critical issues
Define a vulnerability disclosure process with clear ownership and an escalation path that fits the 24-hour window
Generate machine-readable SBOMs (CycloneDX or SPDX) as part of your build process
Map each dependency to the products containing it — so you can answer blast-radius questions instantly when a new CVE lands
Decide your support period commitments and plan dependency lifecycle accordingly

Not sure if your product is in scope? Use our free tool at stackradar.com/cyber-resilience-act — describe your product and get an instant AI-powered scope analysis.

How StackRadar helps

StackRadar is built for exactly the operational challenges the CRA surfaces: continuous dependency inventory, policy enforcement as CI gates, and automated upgrade PRs with repo-specific context.

When a CVE is published, StackRadar surfaces which products and repositories are affected and which exact versions are in use — in seconds. Automated upgrade PRs mean moving from detection to remediation takes hours, not weeks. For teams starting their CRA readiness work, the first step is usually the hardest: getting a complete picture of what you actually depend on. That is where StackRadar starts.

Working through CRA readiness and want to talk through how StackRadar fits in? Reach us at hello@stackradar.com or through the contact form.