Cyber Resilience Act: What Manufacturers, Software Companies and Web Developers Need to Know Now
If you build hardware with a network connection, sell software, or place connected products on the EU market, the Cyber Resilience Act (CRA) — Regulation (EU) 2024/2847 — applies to you. It has been in force since December 10, 2024 and, for the first time, establishes binding EU-wide cybersecurity requirements for “products with digital elements”. The rules apply in stages: the first reporting obligations kick in on September 11, 2026, and the full substantive requirements (security by design, conformity assessment, CE marking) on December 11, 2027. So you don’t have an open-ended deadline — you have a countdown.
TL;DR
- What: The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, regulates cybersecurity for connected hardware and standalone software on the EU market. In force since December 10, 2024; application is staggered.
- Who: Manufacturers, importers and distributors of “products with digital elements” — anything with a direct or indirect data or network connection.
- First hard deadline: From September 11, 2026, notification/reporting obligations (Art. 14) apply for actively exploited vulnerabilities and severe incidents — early warning within 24 hours, notification within 72 hours, final report.
- Full application: From December 11, 2027, security by design, conformity assessment and CE marking become mandatory.
- Core obligations: Security by design/default, vulnerability management across the entire support period, free security updates, and a defined support period with an end date.
- In Germany: A CRA implementation act (amending the BSI Act — the law governing Germany’s Federal Office for Information Security) puts the regulation into national effect; its first reading in the Bundestag, Germany’s federal parliament, took place on June 11, 2026. This is not legal advice.
What is the Cyber Resilience Act, exactly?
The CRA is the first EU-wide regulation that makes cybersecurity a product property — just as product safety or electromagnetic compatibility have long been. Until now, you could sell an insecure connected device or a leaky piece of software, and nobody forced you to fix it. The CRA changes that: cybersecurity becomes a precondition for being allowed to place a product on the EU market at all.
The wording “product with digital elements” matters. It doesn’t just mean traditional hardware — it covers hardware and software with a direct or indirect data or network connection. That includes a wide range of connected devices, from smart sensors to industrial gateways, but explicitly also standalone software products. So if you’re thinking “I don’t build devices, this doesn’t apply to me” — that’s probably not true.
Am I actually affected?
Three roles along the supply chain are in scope:
- Manufacturers — anyone who develops a product (or has it developed) and markets it under their own name. This is where the bulk of the obligations lands.
- Importers — anyone who brings a product from a third country onto the EU market.
- Distributors — anyone who makes products available within the supply chain.
The criterion isn’t “hardware or software” — it’s “digital element with a connection, made available on the EU market”. For mid-market companies, that means in practice: machinery manufacturers with connected components, embedded software providers, SaaS-adjacent product vendors, and software companies shipping finished software products should all take a close look at which role they fall into. The classification isn’t trivial in individual cases — and that’s exactly why it’s one of the first tasks you shouldn’t put off.
What obligations am I actually facing?
The CRA bundles several obligations that together are meant to make a product “resilient”:
| Obligation | What it means |
|---|---|
| Security by design & security by default | The essential cybersecurity requirements from Annex I must be met out of the box — secure default settings, no known exploitable vulnerabilities at the time the product is placed on the market. |
| Vulnerability management | Across the entire support period, including free security updates. |
| Defined support period | You must set a support period, determine an end date, and communicate it. |
| Conformity assessment + CE marking | Self-assessment (Module A) for standard products; a third-party/notified body for important or critical products. CE marking follows. |
| Reporting vulnerabilities & incidents | Actively exploited vulnerabilities and severe incidents must be reported (Art. 14). |
The point many companies underestimate is the free security updates across the entire support period. It changes your business model and your pricing: a product isn’t “done” once it’s sold — it ties up resources for as long as the support period runs. If you don’t plan for that from the start, you’re building yourself a cost trap.
The deadlines — what applies when
The CRA doesn’t give you a single cut-off date but a staggered timeline. That’s good, because you have room to breathe — and dangerous, because the earlier dates are easy to miss.
- June 11, 2026 — Rules on the designation and notification of conformity assessment bodies enter into application. Mainly relevant for the testing-body infrastructure, less so for your day-to-day business.
- September 11, 2026 — The notification/reporting obligations under Art. 14 kick in: actively exploited vulnerabilities and severe incidents must be reported. This is the first deadline that hits you operationally.
- December 11, 2027 — Full substantive requirements: security by design, conformity assessment and CE marking become mandatory.
You’ll find this and other upcoming EU requirements collected on our overview page, the Regulatory Radar. That’s where we track the dates that genuinely matter for mid-market companies.
What does the reporting obligation from September 2026 mean in practice?
From September 11, 2026, you need to be able to report fast — and “fast” is meant literally here. The reporting obligation under Art. 14 follows a three-stage process:
- Early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
- Notification within 72 hours.
- Final report once the matter is investigated and resolved.
You can’t improvise this cadence. You need processes sorted out in advance: Who decides whether an incident is reportable? Who drafts the early warning? Where is the technical information you’ll need? A 24-hour deadline is merciless when the responsible person happens to be on vacation and nobody knows where the credentials are. Which is exactly why it pays to run through this process now — not during an actual emergency.
How is this being implemented in Germany?
An EU regulation generally applies directly, but details of national implementation — such as responsibilities and supervision — are set at the national level. In Germany, this happens via a CRA implementation act, enacted as an amendment to the BSI Act (the law governing the BSI, Germany’s Federal Office for Information Security). The first reading in the Bundestag took place on June 11, 2026. That means the national framework is still in flux, and it’s worth keeping an eye on the legislative process — especially regarding responsibilities and the specific reporting channels.
What you can usefully do now
You need to be ready by December 11, 2027, not today. But the preparation is work that can’t be knocked out in two weeks. Sensible first steps:
- Inventory your products. Which of your products are “products with digital elements”? Which have a direct or indirect network connection?
- Clarify your role. For a given product, are you the manufacturer, importer or distributor? The obligations differ.
- Define the support period. Set a support period with an end date for every affected product — and think about how you’ll organize free security updates over that time.
- Set up a reporting process. For the September 11, 2026 deadline: who reports what, to whom, within which time window? Run through the 24/72-hour process once.
- Determine your conformity route. Is self-assessment (Module A) enough, or does your product fall into the important/critical category and require third-party assessment?
Honestly: where are the limits?
We’re not a law firm, and this article is not legal advice. Whether a specific product falls under the CRA, which conformity category it belongs to, and what the German implementation looks like in detail can only be assessed reliably case by case and against the final legal text — and the German implementation framework was still going through the legislative process at the time of writing. What we can do: help you make your products technically CRA-ready — security by design in the architecture, robust vulnerability management, a clean update mechanism, and processes that actually meet the reporting deadlines.
That’s exactly where Rocket-Monkeys comes in: we build web and software products and integrate AI — and we think about security from day one instead of bolting it on afterwards. If you want to know what the CRA specifically means for your products and how to prepare technically, let’s have a no-obligation conversation. Just drop us a line at info@rocket-monkeys.com — a first chat costs you nothing but half an hour.