Cybersecurity BlogCyber Resilience Act (CRA): Who’s Affected – and What You Must Deliver by September 2026

• What: The Cyber Resilience Act (CRA) – Regulation (EU) 2024/2847 – requires manufacturers of „products with digital elements” to ensure cybersecurity across the entire lifecycle.
• Deadlines: In force since 10 Dec 2024. Reporting obligations from 11 Sep 2026. Full obligations (CE, security by design, SBOM) from 11 Dec 2027.
• You’re affected if you place a product on the market: installable software, app, plugin, SDK, connected device with firmware. Pure SaaS in the browser: no CRA (rather NIS2).
• Company size is irrelevant: if you develop it yourself, you’re the manufacturer – the role with the most obligations.
• Fines: up to €15 million or 2.5% of worldwide annual turnover.

The Cyber Resilience Act sets, for the first time, EU-wide binding cybersecurity requirements for products with digital elements. The logic behind it: a connected product should carry a security promise the way a machine carries the CE mark – security becomes mandatory, from development through the post-sale phase.

The regulation entered into force on 10 December 2024, but the obligations apply in stages over several years. An important distinction: the CRA governs products. For pure services that you operate, the NIS2 Directive usually applies, not the CRA.

The question isn’t who wrote the code. It’s: is it a product – and is it being placed on the market?

👉 Do you ship a product – or only run a service in the browser?

• Shipped/installed (mobile app, desktop tool, plugin, browser extension, SDK, connected device with firmware) → Product → CRA. You’re the manufacturer.
• Runs only in the browser (your website, your SaaS platform) → Service → no CRA (rather NIS2).

Two examples, because many get this wrong:

• Coded your own website? No CRA. A website is operated, not „placed on the market”.
• Developed your own app? If people install it, you’re the manufacturer – CRA. If it only runs in the browser, it’s SaaS – no CRA.

This is also how the regulation puts it: websites and cloud services without a product link explicitly fall outside the scope, per Recital 12.

You run a platform in the browser (no CRA) but ship a companion app, a browser extension or a CLI tool to install? Then the CRA applies to exactly that component. The backend developed specifically for it then counts as a „remote data processing solution” and is also covered. So the dividing line isn’t „browser vs. download”, it’s „product vs. service”.

A manufacturer is anyone who develops a product (or has it developed) and places it on the market under their own name – whether paid or free. There are also importers and distributors. Note: anyone who markets a third-party product under their own name or substantially modifies it becomes the manufacturer themselves.

The point that often surprises people: company size doesn’t matter. If you develop it yourself, you’re the manufacturer – from one-person business to corporation. There are only simplifications in the form of documentation for micro and small enterprises – not in the security requirements themselves.

Date	What happens
10 December 2024	Entry into force. The regulation applies – the obligations kick in gradually.
11 June 2026	Rules on conformity assessment bodies become applicable.
11 September 2026	The reporting obligations kick in (24h / 72h / 14 days or 1 month). The first deadline that directly affects you.
11 December 2027	Full applicability: CE marking, security by design, SBOM, security updates over the support period.

The crux, then, isn’t December 2027 – it’s September 2026. Anyone without a working reporting process by then has a problem the moment the first vulnerability is actively exploited.

From that date, the reporting obligation applies to actively exploited vulnerabilities and severe security incidents. Reporting is done in three stages – simultaneously to the responsible CSIRT (the national emergency response team) and to the EU agency ENISA, via a single reporting platform.

For an actively exploited vulnerability:

• 🕐 24 hours – early warning (initial report, with affected member states where applicable).
• 🕐 72 hours – detailed notification (product, type of exploit, corrective measures taken/recommended).
• 🕐 14 days – final report, once a fix is available (vulnerability, severity, update details).

For a severe incident, the same 24/72 scheme applies – but the final report within one month of the 72-hour notification.

On top of that: you must inform the users of your product about the vulnerability and available patches. If you fail to do so, the notified CSIRT may inform the users itself.

Only then do the big obligations kick in – and only for products placed on the market from that date:

• CE marking with demonstrated cybersecurity conformity
• Security by design and a secure default configuration (secure by default)
• SBOM (Software Bill of Materials): a machine-readable component list, at least of the direct dependencies – not to be published, but to be provided to the authority on request
• Security updates over the support period (as a rule, at least 5 years)

The good news: for around 90% of products (the default class), a self-assessment with internal documentation is enough – no external auditor. Only „important” and „critical” categories (e.g. password managers, firewalls, operating systems, or smart cards) need an external assessment or certification. Enforcement is on a sample basis by the market surveillance authority. If the documentation is missing when they ask, it gets expensive.

🔒 Important on legacy products: the full obligations only hit existing products upon substantial modification from December 2027. The reporting obligations from September 2026, by contrast, apply to all products on the market – including those already shipped.

• up to €15 million or 2.5% of worldwide annual turnover – for breaches of the security requirements and core obligations (incl. reporting obligations)
• up to €10 million or 2% – for most of the remaining obligations
• up to €5 million or 1% – for false information provided to authorities

Some leeway for the small: micro and small enterprises are not fined for merely missing the 24-hour deadline.

The big obligations from December 2027 are in the spotlight – but things get serious first on 11 September 2026. From then on, what counts is whether you can report an actively exploited vulnerability within 24 hours. That’s not a question of documentation, but of process: who spots the vulnerability? Who decides? Who reports – and to whom? Who informs the users?

Anyone who can’t answer that today should use the month and run through the process once as a dry run – from „signal” to „report sent”.