Cyber Resilience Act: Timeline, Requirements & Compliance
Frontend Development
August 13, 2026•Updated September 15, 2026•4 min read
I hope you enjoy reading this post. If you want us to do your frontend development or design, click here.
Author: Pavlo Tyshchenko | COO at The Frontend Company
The Cyber Resilience Act (CRA) is the EU regulation that makes cybersecurity a legal requirement for virtually every product with digital elements sold in the EU — hardware and software alike. It entered into force on December 10, 2024, its incident and vulnerability reporting obligations have applied since September 11, 2026, and full compliance, including CE marking, becomes mandatory on December 11, 2027. Fines reach EUR 15 million or 2.5% of global turnover, whichever is higher.
If you ship software that ends up on the EU market — a desktop app, a mobile app, firmware, a connected device, a paid library — the CRA almost certainly applies to you, wherever your company is based. This guide breaks down who is covered, what the law actually demands, the risk classes, the real timeline, and a practical path to readiness.
What is the Cyber Resilience Act?
The CRA is Regulation (EU) 2024/2847. Unlike a directive, a regulation applies directly in every member state — no national transposition, no local variations. It introduces mandatory cybersecurity requirements for "products with digital elements": products that have a digital component and can connect, directly or indirectly, to a device or network.
The logic mirrors what the EU did for physical product safety decades ago: to sell on the EU market, a product must meet essential requirements, carry documentation that proves it, and bear the CE mark. The CRA extends that regime to software security.
The Commission's first official application guidance — Communication C(2026) 5252 of July 27, 2026 — is non-binding, but it settles the questions manufacturers ask most: how remote data processing and open source fall in or out of scope, what counts as a substantial modification, how support periods work, and how the reporting obligations apply, with 67 worked examples aimed at small and mid-sized companies. Read it alongside the regulation, not instead of it.
Who must comply
The obligations fall primarily on manufacturers — the party that develops the product or has it developed and places it on the EU market under its name. Importers and distributors carry secondary duties. Three clarifications matter for software companies:
- Non-EU vendors are fully covered. The CRA follows the market. A US or UK company selling software into the EU has the same obligations as an EU manufacturer.
- Software counts as a product. Operating systems, desktop and mobile apps, games, libraries and components sold commercially, firmware — all in scope. Remote data processing that is integral to the product's function (the backend your app cannot work without) is treated as part of the product.
- Pure cloud services sit mostly outside. Standalone SaaS and websites generally fall under NIS2 rather than the CRA — but the boundary runs through your architecture, not your marketing. If a cloud component is essential to a product's functioning, it comes into CRA scope with the product.
Open-source software gets a dedicated, lighter regime: non-commercial projects are out of scope, and "open-source software stewards" (foundations and similar) carry reduced obligations rather than full manufacturer duties.
Risk classes: most products self-assess
The CRA sorts products into classes that determine how conformity is checked:
Class | Examples | Conformity route |
|---|---|---|
Default (~90% of products) | Most apps, games, standard software, smart devices | Manufacturer self-assessment (internal control) |
Important — Class I | Password managers, VPNs, browsers, smart home devices | Harmonised standards, or third-party assessment |
Important — Class II | Firewalls, hypervisors, tamper-resistant microcontrollers | Third-party assessment by a notified body |
Critical | Hardware security modules, smart meter gateways | European cybersecurity certification |
The headline for SMB software vendors: roughly nine out of ten products fall in the default class, where the manufacturer runs the assessment internally, signs the EU Declaration of Conformity, and affixes the CE mark — no external certification body involved. The European Commission's own impact assessment puts the default share at about 90% of covered products.
The essential requirements, in plain terms
Annex I of the regulation defines what every covered product must deliver. Condensed to engineering language:
- Secure by design and by default. Ship with secure configurations, minimize attack surface, protect confidentiality and integrity of data, apply least privilege.
- No known exploitable vulnerabilities at release. You must have looked, documented what you found, and fixed what matters before shipping.
- Security updates for the support period. Provide free security updates for the expected product lifetime — at least five years unless the product's life is genuinely shorter — and tell users how long that period is.
- A working vulnerability-handling process. A coordinated vulnerability disclosure policy, a contact point for reports, timely patching, and — the part most teams lack today — a Software Bill of Materials (SBOM) covering at minimum the product's top-level dependencies.
Reporting: the September 2026 clock
Since September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents through the ENISA single reporting platform: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days (one month for incidents). This obligation landed before full compliance — and it applies to products already on the market. If you still have no process for detecting, triaging, and reporting exploitation, you are already behind: the reporting clock is running now, and December 2027 only adds the rest of the requirements on top. We track the live state of the reporting regime, the standards and the implementing acts month by month on our CRA updates page.
Transform your UI for peak performance!
🔹
Unlock seamless, high-performance frontend solutions tailored to your business.
🔹
Get an interface that outshines competitors and delights your users.
Penalties
Non-compliance with the essential requirements or reporting duties carries administrative fines up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Lesser breaches of other obligations run up to EUR 10 million / 2%, and supplying misleading information to authorities up to EUR 5 million / 1%. Market surveillance authorities can also order corrective action, restrict, or withdraw products from the market — which, for a software business, is the more existential threat.
What CRA readiness looks like in practice
For a default-class software product, a defensible program has six steps:
- Scope and classify. Confirm which of your products are covered and in which class — this single decision shapes everything downstream.
- Gap assessment against Annex I. Map current practice to each essential requirement: what passes, what fails, what is undocumented.
- SBOM and dependency hygiene. Generate SBOMs in a standard format (CycloneDX or SPDX), wire generation into CI, and set up vulnerability monitoring against them — open tooling covers most of this. Our guide to SBOM formats compares SPDX and CycloneDX and explains which one the CRA actually needs.
- Vulnerability handling and reporting readiness. Publish a disclosure policy, define the intake-triage-patch flow, and keep the 24h/72h/14d reporting path exercised — it has been mandatory since September 2026.
- Technical documentation and self-assessment. Assemble the technical file: risk assessment, design decisions, test evidence, support period. Run the internal control procedure, sign the EU Declaration of Conformity, affix the CE mark.
- Maintain. Security updates through the support period, documentation kept current, reporting muscle exercised. Like accessibility, CRA compliance is a state you maintain, not a certificate you frame — the same principle that runs through the European Accessibility Act, the EU's parallel compliance regime for accessibility.
Most of this work is engineering, not paperwork: dependency management, build pipelines, secure defaults, patch flow. Teams whose product is a modern web or app codebase usually find the gap is narrower than they feared — but almost never zero, and the documentation layer is where nearly everyone starts from scratch.
Get a CRA readiness review before December 2027
We map your product against the CRA's essential requirements, set up SBOM and vulnerability handling in your pipeline, fix what fails in the code, and assemble the technical file your Declaration of Conformity needs. Book a call to scope it.
FAQ
Pavlo Tyshchenko is COO at The Frontend Company, where he runs operations, delivery, and the internal systems the company runs on - AI workflows, knowledge infrastructure, and hiring. He writes about AI agents, process automation, and the engineering side of software compliance.
Follow the expert:
LEARN MORE
