EU CRA ComplianceCRA compliance software See the CRA Workbench →

Field notesRegulation (EU) 2024/2847Products with digital elements

The CRA Brief

What the EU Cyber Resilience Act asks of you — explained without the 60 pages of legalese.

In this issue

01
Primer

What the EU CRA actually is

The Cyber Resilience Act — Regulation (EU) 2024/2847 — is the first EU-wide cybersecurity law for products with digital elements: hardware and software placed on the EU market. Its scope is broad; nearly every connected or software-bearing product, from industrial controllers to consumer IoT, falls under it.

What sets it apart from a guideline is the consequence. Without a CE mark, an EU Declaration of Conformity and an Annex VII technical file, an in-scope product cannot be lawfully sold on the EU market. There is no "do nothing" option — demand for compliance is created by law, not by persuasion.

For most teams, this is new ground: the text runs to more than 60 pages, the obligations are unfamiliar, and the deadlines are fixed.

Source: Regulation (EU) 2024/2847; European Commission CRA pages.

02
Obligations

The manufacturer's obligation chain

The CRA reads as a single chain of duties. Work through it in order, and the technical file assembles itself:

  • Classify the product — default, important (Annex III, class I & II), or critical (Annex IV).
  • Run the Article 13 risk assessment, tied to the requirements it activates.
  • Meet the Annex I essential requirements — Part I product properties and Part II vulnerability handling.
  • Choose the conformity-assessment route — self-assessment or third-party.
  • Apply the CE mark and the EU Declaration of Conformity.
  • Assemble the Annex VII technical file.

This chain is exactly what the CRA Workbench software walks a product through, with every conclusion cited to the article behind it.

Source: Reg (EU) 2024/2847 — Articles 13 and 32; Annexes I, III, IV, and VII.

03
Timeline

The deadlines that matter

The compliance clock is fixed, and it is already running:

  • 10 December 2024 — the CRA entered into force; the clock starts.
  • 11 June 2026 — the notified-body provisions (Chapter IV) apply.
  • 11 September 2026 — Article 14 vulnerability and incident reporting applies.
  • 11 December 2027 — the main obligations apply; non-compliant products can no longer be sold.

Reporting duties arrive first, well before the full market-access gate — so for most manufacturers, a vulnerability-handling program is the nearest-term obligation.

Source: Reg (EU) 2024/2847 — application dates.

04
Scope

Default, important, or critical?

Classification decides how much scrutiny a product with digital elements faces. Most are default and self-assessed. Important products (Annex III, class I & II) — network-management tools, password managers, industrial gateways — carry heavier expectations, and critical products (Annex IV) more still.

Article 32 confirms that most products will be subject to self-assessment by the manufacturer; third-party assessment is mandatory only for the narrow important and critical tiers. Getting the class right, with a documented rationale, is what decides both the route and the evidence bar.

Source: Reg (EU) 2024/2847 — Article 32; Annexes III and IV.

05
Article 14

The 24- and 72-hour reporting clock

From 11 September 2026, Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents on a tight clock.

An early warning within 24 hours, a fuller notification within 72 hours, and a final report once the issue is resolved.

Meeting it is not a form to fill in — it is a standing capability: a coordinated-vulnerability-disclosure policy, a monitored intake, severity triage, and a runbook that is ready before an incident, not written during one.

Source: Reg (EU) 2024/2847 — Article 14; Annex I, Part II.

06
OT / ICS

Turning IEC 62443 work into CRA evidence

Industrial manufacturers rarely start from zero. If you already run an IEC 62443-4-1 secure-development lifecycle, much of your CRA evidence already exists — it is simply shaped for a different framework.

ENISA and the JRC have mapped 62443-4-1 onto the CRA's Annex I requirements, and the standard is being amended (A11:2026) to align further.

The bridge turns the 62443 work you have done into CRA evidence — instead of starting over.

The CRA Workbench maps each CRA requirement to the 62443 practice and evidence artefact that produces it, so OT teams reuse the work rather than repeat it. ENISA flags 62443 as the ICS-specific exception, not the general backbone — so the bridge is built for OT and ICS specifically.

Source: ENISA–JRC CRA Requirements Standards Mapping (EUR 31892 EN); EN IEC 62443-4-1.

From understanding the CRA to documenting it.

The CRA Workbench is the software that turns all of this into a reviewer-ready package for your own product with digital elements.

See the CRA Workbench →

These field notes are general information about Regulation (EU) 2024/2847, not legal advice. Figures and dates are verified against primary sources, but the CRA's harmonised-standards landscape is still settling — confirm against the current official text before relying on any point. The CRA Workbench is software that produces draft documentation for expert review; it indicates the evidence needed and does not, by itself, guarantee compliance.