The EU Cyber Resilience Act: CE Marking Comes for Software

Cyber Resilience Act · CRA · Product Security · CE Marking · SBOM · Vulnerability Disclosure · Secure by Design · EU Regulation

For thirty years, the CE mark has told European consumers that a toaster won't electrocute them. From December 2027, it will also have to tell them that their router, their smart doorbell, and — remarkably — their software won't be trivially hackable. Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), is the first horizontal law anywhere that makes cybersecurity a condition of market access for digital products, and its reach surprises almost everyone who reads the scope article for the first time.

Who is caught. The CRA covers every "product with digital elements" (PDE) made available in the EU: any hardware or software with a network interface. That means IoT devices and network gear, but also operating systems, mobile apps, desktop applications, games, and commercial off-the-shelf software with nothing physical about it at all. Obligations fall primarily on manufacturers — which includes any software vendor selling into the EU regardless of headquarters — with lighter verification duties for importers and distributors. Sector-regulated products (medical devices, automotive, aviation) are excluded, and open-source software escapes when it is not commercially placed on the market, with a light-touch "steward" regime for foundations supporting commercial open source.

A three-class risk model. Most products sit in the default class and can self-assess conformity. Class I (Annex III) lists around 35 higher-risk categories — password managers, browsers, VPNs, identity software, home routers, smart meters — where manufacturers choose between self-assessment against harmonised standards or a third-party route. Class II (Annex IV) names the highest-risk categories — hypervisors, firewalls for industrial use, HSMs, tamper-resistant microcontrollers, industrial control systems — where notified-body assessment is mandatory. Classify early: the class determines your entire conformity strategy and whether you need to book a notified body while capacity still exists.

The essential requirements. Annex I Part I is a secure-development charter with legal force: products must ship with no known exploitable vulnerabilities, be secure by default, enforce access control, encrypt data at rest and in transit, protect integrity with signed updates, minimise data collection, resist denial of service, and include exploit mitigations. Part II is where most organisations have the furthest to travel — a mandatory vulnerability handling process for the product's whole support life: maintain a software bill of materials (SBOM) covering at least top-level dependencies, run a published coordinated vulnerability disclosure policy with a named contact, remediate without delay, and deliver free security updates for a support period of at least five years, with end-of-life announced a year in advance.

The deadline everyone underestimates. Full application lands on 11 December 2027, but the reporting obligations bite earlier: from 11 September 2026, manufacturers must report any actively exploited vulnerability in their product — and any severe incident affecting it — to ENISA and their national CSIRT with an early warning within 24 hours and a full report within 72. That is a live operational capability: exploit-awareness monitoring, a decision path, and a reporting pipeline, needed roughly a year before the rest of the regulation applies. If your PSIRT is one engineer and a shared mailbox, September 2026 is your real deadline.

Paperwork with teeth. Conformity ends in familiar New Legislative Framework artefacts: technical documentation per Annex VII (architecture, threat model, risk assessment, test evidence, SBOM), a signed EU Declaration of Conformity, the CE mark, and ten years of record-keeping. Penalties scale to the offence: up to €15 million or 2.5% of global turnover for breaching the essential requirements. Market surveillance authorities can order withdrawal of non-compliant products — for a software company, the equivalent of being switched off in Europe.

Where to start, in order. First, inventory your products and classify each against Annexes III and IV — this single exercise sizes the whole programme. Second, stand up the Part II machinery: SBOM generation in the build pipeline, a public VDP, and the 24-hour ENISA reporting path. Third, define and publish support periods, because they drive engineering budgets for years. Fourth, push requirements upstream — your product's compliance inherits from your components, so SBOM and support-period clauses belong in supplier contracts now.

The CRA completes a regulatory triangle: NIS2 secures the operators, DORA secures finance, and the CRA secures the products they all run on. For GRC teams it is also a genuine novelty — product security, long an engineering subculture, just became a conformity discipline with auditors, technical files, and a mark on the box.