The CRA in one hour: what changes for anyone who builds connected products
29 July 2026·7 min read·Alberto Scarpa
Most manufacturers know the CRA exists. Far less clear is what it actually demands, and how to turn its requirements into concrete development decisions. That’s the distance between “we read there’s a new regulation” and “we know which product decisions to make by December 2027”, and it’s the distance that costs money.
The Cyber Resilience Act (EU Regulation 2024/2847, in force since 10 December 2024) is a product safety law. It doesn’t describe good practice: it imposes requirements that must be true of every product with digital elements sold on the European market. Those who don’t meet them don’t earn a CE mark. Those without a CE mark don’t sell. An hour of reading is enough to grasp the essentials, and this article is that hour. The references in brackets point to the official text; where I offer an interpretation of my own, I flag it.
What’s in scope: “product with digital elements”
The CRA’s perimeter is uncomfortably wide. A product with digital elements (PDE) is, in the regulation’s definition, “any software or hardware product and its remote data processing solutions” (art. 3, point 1). It doesn’t need to be “smart” in the commercial sense of the word.
Concretely: if your product has a microcontroller, firmware, a communication port, or a component that talks to something else, it’s very probably in scope. The ECU of an agricultural machine, a plant gateway, the sensor that sends data over a bus: all PDEs.
The boundary, technically, turns on the type of connection. The regulation distinguishes logical, physical, and indirect connection (art. 3, points 8, 9, and 10), and it also treats as part of the product the remote data processing developed by the manufacturer, when its absence would prevent the product from performing a function (art. 3, point 2): the cloud back-end is in scope. The Commission’s guidance (document C(2026) 5252, non-binding, adopted under art. 26) clarifies that a signal which merely powers or triggers a function, without carrying encoded digital data, stays out.
Operational note (my reading, not the text of the law). The boundary of “carries data or merely powers and triggers” decides whether an entire product line is in scope or not. It’s the first analysis I’d run, before any other: it changes everything downstream.
The three obligations that didn’t exist before
Anyone who knows IEC 62443 or the NIST frameworks will recognise much of the CRA’s requirements, collected in Annex I: product security (part I) and vulnerability handling (part II). But three obligations had no binding equivalent before the CRA. These are the ones that change how you work.
The first is the support period. The manufacturer must ensure vulnerability handling and security updates for a period that reflects the product’s expected use, and in any case for at least five years (art. 13, para. 8). Updates already released must remain available for at least ten years, or for the rest of the support period if longer (art. 13, para. 9). IEC 62443 prescribes no duration; the CRA does. It means designing from the outset the mechanism by which you’ll deliver signed firmware to a device you may sell only once.
The second is reporting. An actively exploited vulnerability must be notified to the coordinating CSIRT and to ENISA with an early warning within 24 hours of discovery (art. 14, para. 2, point a), a notification within 72 hours (point b), and a final report within 14 days of a corrective measure being made available (point c), through the single reporting platform (art. 16). If your vulnerability handling process today measures time in weeks, the CRA measures it in hours. I’ve laid out the exact deadlines, and what you need ready for each, in The CRA deadlines.
The third is the software bill of materials (SBOM): in the regulation’s definition, “a formal record containing details and supply chain relationships of components” in the product’s software (art. 3, point 39). It’s not an internal best practice: it’s a vulnerability handling requirement (Annex I, part II, point 1), which asks you to include at least the top-level dependencies. It is the software bill of materials. If you know exactly which libraries you’ve integrated and in which version, you handle a critical vulnerability in a day. If you don’t, every report becomes an emergency.
Compliance is not a document at the end of the project
Here is the real shift in mindset, and it’s worth saying plainly: under the CRA compliance is not something you sort out before CE marking. The regulation requires a documented cybersecurity risk assessment kept up to date for the whole support period (art. 13, para. 2 and 3) and vulnerability handling that continues after launch (Annex I, part II). The manufacturer must demonstrate not only that the product was secure on the day of sale, but that it stays managed for the whole declared period. Demonstrate is the key word: you need documented, up-to-date evidence (art. 13, para. 3), the kind that holds up to a market surveillance check, not a folder assembled after the fact.
In practice: security enters design decisions (architecture, choice of components, update mechanism), not the closing documentation. An embedded system designed without this requirement has two roads ahead: a costly retrofit before the deadline, or a product off the market. If you start from an ISO 9001 certified quality system, part of this structure you can reuse, and part you can’t: I cover it in Already ISO 9001 certified?.
A widespread fear is dispelled by the Commission’s guidance (C(2026) 5252): a product designed before the CRA can stay on the market after 2027 on the basis of a current risk assessment, without any obligation to reconstruct historical design documentation that no longer exists. The constraint is on the future, not the past.
Who decides whether you can self-certify
Not all products follow the same path. The CRA distinguishes “default” PDEs (the majority), “important” products listed in Annex III and split into class I and II (art. 7), and “critical” products in Annex IV (art. 8). The band determines the conformity assessment procedure (art. 32).
In practice: default products self-certify through internal control (module A, Annex VIII, part I); important and critical products may require the application of harmonised standards or the involvement of a notified body (art. 32, para. 2 and 3). Applying a harmonised standard gives a presumption of conformity (art. 27): it’s the legal shortcut that avoids having to demonstrate the requirement from scratch.
One point the regulation puts in black and white, and which weighs at the design stage: integrating into a product a component with an “important” function does not, in itself, make the whole product subject to the stricter procedures (art. 7, para. 1). It’s the main function of the product as a whole that determines the path. A microcontroller or a firewall inside a device does not automatically make it “important”.
Where you really start
The first step is not choosing a standard. It’s looking at your own product lines and answering three questions: which qualify as PDEs (art. 3, point 1), which band they fall into (art. 6, 7, and 8), and, for each, how far the current process is from the Annex I requirements. It’s half a day of work per line, unexciting and decisive, because any cost estimate made before doing it is a made-up number.
The decision isn’t whether to comply. It’s when. And the ones who pay most are the ones who wait.
References: Regulation (EU) 2024/2847 (CRA), articles 3, 6, 7, 8, 13, 14, 16, 27, 32 and Annexes I, III, IV, VIII; Commission guidance C(2026) 5252 (non-binding, art. 26). The notes flagged as operational are my interpretations, not regulatory text.