What is the Cyber Resilience Act: scope, obligations, and the dates that bind

The short answer

The Cyber Resilience Act — Regulation (EU) 2024/2847 — is the first EU law to impose **cybersecurity requirements on products themselves**, as a condition of placing them on the EU market. It entered into force on **10 December 2024**.

It covers **products with digital elements**: hardware and software that connect, directly or indirectly, to a device or network. A router, an industrial controller, a mobile application, a smart doorbell and a standalone software product all fall under the same instrument.

Two dates matter, and they are not the same date:

``` 11 September 2026 reporting obligations (Article 14) apply 11 December 2027 the regulation applies in full ```

Because it is a Regulation and not a Directive, it applies directly in every Member State. There is no national version to look up, and no transposition to wait for.

**What makes the CRA structurally different from the security rules most manufacturers have met before:** it does not stop at the moment of sale. It requires vulnerability handling, security updates and incident reporting **throughout a defined support period** — turning a one-off market-entry check into a continuing obligation attached to every unit shipped.

Who is in scope

**Any economic operator placing a product with digital elements on the EU market**, wherever they are established. A manufacturer in Shenzhen, Taipei, Seoul or San Jose is in scope the moment its product is made available in the Union.

The regulation assigns distinct duties to **manufacturers**, **importers** and **distributors**. The heaviest sit with the manufacturer; importers and distributors carry verification duties and cannot lawfully pass on a product they know to be non-compliant.

**What is excluded, and why the list matters**

Products already covered by equivalent sector regimes are carved out — among them medical devices, civil aviation, motor vehicles and marine equipment — as are products developed exclusively for national security or defence purposes.

**Free and open-source software supplied outside the course of a commercial activity is outside scope.** The regulation also creates a lighter, distinct regime for **open-source software stewards** — organisations that support the development of open-source products used in commercial activity without themselves monetising them.

The practical trap is that **the exclusion attaches to the supply, not to the licence**. An open-source component shipped inside a commercial product is inside that product's scope, and the manufacturer answers for it.

What the regulation actually requires

The essential requirements sit in **Annex I**, and it is worth reading its two parts as two different obligations, because they are enforced on different timelines.

**Part I — the product must be secure**

Products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks, and must be **made available without known exploitable vulnerabilities**. Part I then sets out the property-level requirements — secure default configuration, protection from unauthorised access, confidentiality and integrity of data, minimisation of attack surfaces, and the ability to install security updates, among others.

**"Secure by default" is a legal requirement, not a design philosophy.** A product shipped with a default password, or with an insecure configuration that the user is expected to correct, does not meet Part I.

**Part II — vulnerability handling, for as long as the product is supported**

Part II is the part that turns compliance into a process. Manufacturers must, among other duties:

**software bill of materials** covering at least the top-level dependencies;

updates;

**without delay and free of charge**.

**The support period is a declaration, not an intention**

The manufacturer must determine a support period reflecting how long the product is expected to be in use. **It shall be at least five years**, unless the product's expected lifetime is shorter. The period must be stated so the buyer knows it before purchasing.

This is the requirement most likely to change a commercial model. A five-year obligation to ship free security updates has a cost, and that cost belongs in the price of the product — not in a support budget discovered in year three.

• **Identify and document the components** contained in the product, including a
• **Address and remediate vulnerabilities without delay**, including by providing security
• **Test and review** the security of the product regularly;
• **Publish information about fixed vulnerabilities** once an update is available;
• Put in place and enforce a **coordinated vulnerability disclosure policy**;
• Provide a **contact address** for reporting vulnerabilities found in the product;
• Distribute updates through a **secure mechanism**, and disseminate security updates

Classification decides how you prove conformity

Most products are **default products**: the manufacturer assesses conformity itself, through internal control, and affixes the CE marking.

Above that sit two named lists, and **the naming is where most published summaries get it wrong**:

``` Annex III important products class I and class II Annex IV critical products ```

**Annex III is "important", not "critical".** Annex IV is the critical list. Getting this backwards changes which conformity assessment route applies, and it appears often enough in secondary sources that it is worth verifying against the regulation itself rather than against a summary.

For **important products in class I**, self-assessment remains available only where harmonised standards, European cybersecurity certification schemes or common specifications have been applied in full. Where they have not, a **third-party assessment route** applies. For **class II**, a third-party route applies regardless. **Critical products** may be required to obtain a European cybersecurity certificate under a scheme adopted for that purpose.

The consequence is scheduling, not paperwork: **a third-party route introduces a queue you do not control**. A notified body's availability in late 2027 is not something a project plan can assume.

Reporting: the obligation that arrives first

**Article 14 applies from 11 September 2026 — fifteen months before the rest of the regulation.** A manufacturer whose product is not yet subject to the full essential requirements can already be subject to the reporting duty.

Two triggers, reported to the CSIRT designated as coordinator and to ENISA through a single reporting platform:

Both follow a staged timeline — an early warning within **24 hours**, a fuller notification within **72 hours**, and a final report thereafter. Manufacturers must also inform impacted users, and where appropriate advise them on corrective measures.

**Twenty-four hours is an operational commitment, not a legal one.** It requires someone reachable, a decision rule for what counts as actively exploited, and a channel that is already registered before the first incident — none of which can be improvised on the day.

• an **actively exploited vulnerability** contained in the product;
• a **severe incident having an impact on the security** of the product.

What non-compliance costs

Article 64 sets three tiers, each expressed as the **higher** of a fixed amount or a percentage of **total worldwide annual turnover**:

``` essential requirements (Annex I) and the Article 13 / 14 duties up to EUR 15 000 000 or 2.5 % other obligations under the regulation up to EUR 10 000 000 or 2 % supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities up to EUR 5 000 000 or 1 % ```

**The commercial exposure is larger than the fine.** Market surveillance authorities may require a non-compliant product to be brought into conformity, withdrawn, or recalled. For an exporter, a withdrawal decision reaches the whole Union at once, and it reaches the distributor relationship before it reaches the balance sheet.

What to establish first

1. **Determine your classification** — default, Annex III class I or II, or Annex IV. Every downstream decision, including whether you need a notified body, follows from it. 2. **Produce an SBOM you can regenerate**, not one you wrote once. Part II requires it to stay accurate as the product changes. 3. **Publish a coordinated vulnerability disclosure policy and a working contact address.** These are cheap, they are verifiable from outside, and they are among the first things a market surveillance authority can check without asking you. 4. **Decide and publish the support period** before it becomes a pricing argument. 5. **Stand up the reporting path for September 2026**, separately from the 2027 programme. It binds first, and it binds regardless of how the rest is progressing.

Tools available on NexCyber

• Free applicability assessment — confirm CRA scope and product classification
• Compliance responsibility mapper — RACI by role
• Penalty calculator — exposure by regulation

Further reading

→ Important versus critical: Annex III and Annex IV explained → CRA Article 14: the vulnerability reporting workflow → SBOM under the CRA: format, depth and signing → CRA penalties and how they are calculated → NIS2 × CRA — what overlaps and what does not → One evidence set across five EU regulations → CRA regulation overview

*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. Harmonised standards, certification schemes and the delegated acts refining the technical description of product categories are still being adopted and amended — verify against the current text of Regulation (EU) 2024/2847 and the Official Journal. Consult your competent authority or a qualified adviser.*