For twenty years, the security of software sold in Europe was largely the buyer's problem. The Cyber Resilience Act ends that. It puts the obligation on the people who make the product — to design it securely, to keep handling vulnerabilities long after it ships, and to say so with a CE mark. If you place products with digital elements on the EU market, it will reshape how you release and support them.
What the CRA is
The Cyber Resilience Act — Regulation (EU) 2024/2847 — is horizontal EU legislation setting mandatory cybersecurity requirements for products with digital elements. "Horizontal" matters: unlike sector rules for, say, medical devices or cars, the CRA cuts across the whole market. If your product has software in it and connects to something, it is likely in scope.
It does three things a manufacturer feels directly. It requires secure-by-design engineering against a set of essential requirements. It requires vulnerability handling for the whole support period, not just at launch. And it requires reporting of actively exploited vulnerabilities and severe incidents on a tight clock. Compliance is expressed through a CE mark and an EU Declaration of Conformity, and non-compliance is backed by fines large enough to notice.
Does it apply to you?
The test is whether you place a product with digital elements on the EU market. That phrase is deliberately broad: any software or hardware product, together with its remote data-processing solutions, whose intended use includes a data connection to a device or network. In everyday terms — connected software, IoT and embedded devices, connected hardware, and the cloud-side components a product depends on to function.
- Who's on the hook. Primarily the manufacturer. Importers and distributors carry lighter obligations to check that a product is compliant before putting it on the market.
- Open-source stewards get a lighter, tailored regime, and non-commercial open-source development is largely outside scope. Commercial activity is the dividing line.
- Products already covered by sector rules — medical devices, motor vehicles, civil aviation, marine equipment — are carved out to avoid double regulation.
- Pure SaaS delivered only as a service generally sits outside the CRA's product scope, but remote data-processing solutions that are necessary for a product's functions are pulled back in. This edge is worth checking against your architecture.
The deadlines: a staged rollout
The CRA entered into force in December 2024, but its obligations switch on in phases. Three dates matter:
| Date | What applies |
|---|---|
| 11 Jun 2026 | Rules on conformity assessment bodies apply — the machinery for notified bodies begins to stand up. |
| 11 Sep 2026 | Reporting obligations. Manufacturers must report actively exploited vulnerabilities and severe incidents on the 24 / 72 / 14 timeline. The first obligation with operational teeth. |
| 11 Dec 2027 | Full application. All remaining obligations — essential requirements, SBOM, vulnerability handling, technical documentation, Declaration of Conformity and CE marking. |
Read the sequence carefully. Reporting lands more than a year before full compliance — so from September 2026 you owe reports on your existing, shipped portfolio, even though the CE-marking regime doesn't fully apply until the end of 2027. The reporting obligation is covered in depth in the 24 / 72 / 14 reporting guide.
Product classification drives everything downstream
How much scrutiny a product attracts depends on which class it falls into. Most products are default; a minority are singled out as more sensitive.
| Class | Examples | Conformity route |
|---|---|---|
| Default | The large majority of products | Self-assessment (Module A) |
| Important (Annex III) | Password managers, network management tools, VPNs, boot managers (Class I & II) | Standards-based self-assessment, or third-party assessment |
| Critical (Annex IV) | Highest-risk categories, e.g. hardware security modules, smart meter gateways | Third-party / notified-body assessment, possibly EU certification |
The practical consequence: classifying your products early tells you whether you're on a self-assessment path you can run yourself, or heading toward a notified body — which is a longer, higher-touch process you'll want to start on time.
What you actually have to do
Strip away the legal structure and the manufacturer's obligations come down to a handful of things you have to be able to show:
- Meet the essential requirements (Annex I). Part I covers product properties — secure defaults, protection of data, minimised attack surface. Part II covers vulnerability handling as an ongoing process.
- Produce an SBOM. A machine-readable software bill of materials, at least of top-level dependencies, kept current. The open formats are CycloneDX and SPDX — see SBOM for the CRA.
- Handle vulnerabilities across the support period. You declare a support period — expected to be at least five years for most products — and must address vulnerabilities throughout it, shipping security updates.
- Run a coordinated vulnerability disclosure process. A published policy, a way for researchers to report, and a route from that report into your handling — see coordinated vulnerability disclosure.
- Report actively exploited vulnerabilities and severe incidents on the 24 / 72 / 14 timeline, from September 2026.
- Compile technical documentation, draw up a Declaration of Conformity, and affix the CE mark — from December 2027. See CRA conformity & CE marking.
Two of these carry most of the day-to-day load: vulnerability handling and reporting. Both turn on the same underlying question — which of the CVEs in your components actually matter in your product. Answering that with evidence rather than a guess is what keeps the workload sane; see evidence-backed VEX for why.
Conformity assessment & CE marking
CE marking under the CRA follows the familiar EU pattern. You demonstrate that the product meets the essential requirements, document it, declare it, and mark it. Default products use Module A — internal control (you self-assess, no notified body, but you still compile the full technical file and sign the Declaration of Conformity). Important and critical products face stricter routes, up to third-party or notified-body assessment. The full picture is in CRA conformity & CE marking.
Technical documentation and the Declaration of Conformity must be retained for ten years (or the support period, if longer) after the product is placed on the market. This is why an immutable, long-retention evidence trail — not a folder of PDFs — is the sane way to hold it.
Penalties
The CRA is enforced by national market-surveillance authorities, and the fines are tiered. Breaching the essential requirements or the core manufacturer obligations tops out at €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other breaches carry lower ceilings, and supplying incorrect or misleading information to authorities is its own, smaller tier. The number that focuses minds is the first one — and it's set against obligations that, for reporting, are already live in 2026.
Where to start
If you're staring at this list wondering what to do first, sequence it by deadline and by pain:
- Classify your products (default / important / critical) so you know which conformity route each one is on.
- Get reporting-ready for September 2026. Identify your coordinating CSIRT, wire active-exploitation monitoring to a clock, and prepare report templates. Start with the reporting guide.
- Make your vulnerability handling defensible. Generate SBOMs, correlate them, and decide which CVEs matter — with evidence you can stand behind. That's the evidence-backed VEX problem.
- Build toward conformity for December 2027 — technical file, Declaration of Conformity, CE marking — on top of the evidence you're already collecting, rather than as a separate late scramble.
Done in that order, the December 2027 work is mostly assembly of evidence you gathered for the September 2026 obligation — which is the whole idea behind treating the CRA as one continuous programme rather than two disconnected deadlines.
Frequently asked
What is the EU Cyber Resilience Act?
It is Regulation (EU) 2024/2847, an EU law setting mandatory cybersecurity requirements for products with digital elements sold in the EU. It makes manufacturers responsible for secure design, vulnerability handling across a support period, and vulnerability and incident reporting, backed by CE marking and administrative fines.
When does the CRA come into effect?
It entered into force in December 2024 and applies in phases: rules on conformity assessment bodies from 11 June 2026, reporting obligations from 11 September 2026, and the full set of obligations from 11 December 2027.
What is a "product with digital elements"?
Any software or hardware product, and its remote data-processing solutions, whose intended use includes a direct or indirect data connection to a device or network. In practice that covers most connected software, IoT and embedded devices, and connected hardware placed on the EU market.
Do most products need a notified body?
No. Most products are default class and self-assess under Module A, without a notified body — though a full technical file and Declaration of Conformity are still required and kept for ten years. Important and critical products face stricter routes that can require third-party or notified-body involvement.