_SNB%20Hard%20crop.png)
A working overview of the EU Cyber Resilience Act for IoT OEMs — what changed, what it costs, when the clock starts, and where it sits in the global regulatory landscape.
Default passwords. Unsigned firmware updates. Two-year security support windows on devices that stay in the field for ten. None of these have been illegal in the EU — until now.
Regulation (EU) 2024/2847 — the EU Cyber Resilience Act — changes that. It covers almost every product with digital elements placed on the EU market, and pins legal responsibility on a single party: the manufacturer holding the CE marking. Not the silicon vendor. Not the cloud platform. Not the contract manufacturer. The CE holder.
What follows is the law itself — what changed, what it costs, when it bites, and where it sits globally. For how engineering teams turn this into a programme, see What IoT OEMs Need to Know.
Every piece of EU cybersecurity legislation before CRA left a gap in the same place. GDPR governs how personal data is processed. NIS2 governs essential and important entities in critical sectors. The Radio Equipment Directive, via EN 18031, covers radio equipment. The Cybersecurity Act offers voluntary certification. Sectoral laws cover medical devices, motor vehicles, aviation, and marine equipment.
None of them covered — systematically, across every product category — the security of the connected product itself, throughout its life in the field.
CRA is horizontal: it covers every product with digital elements, not a list of named sectors. A Bluetooth sensor, an industrial PLC, and a cloud-hosted application are all in scope under the same text. Exemptions are narrow and explicit — medical, automotive, civil aviation, marine — and everything else falls inside.
What this means for engineering: CRA sets outcomes, not mechanisms. The regulation cannot specify AES-256 or TLS 1.3 when one text governs all three of them simultaneously; technical specifications live in the harmonised standards beneath it. Read CRA for what to achieve. Read the standards for how.
CRA's enforceable surface sits in three places in the text. Annex I sets the essential cybersecurity requirements — what the product must be. Articles 13 and 14 set the manufacturer's obligations — what you must do for the product across its life, including security updates and vulnerability reporting. Annex VII sets the technical documentation requirements — what records you must keep, and for how long.
CRA entered into force on 10 December 2024. But scope without enforcement is a paper tiger. CRA has teeth — and they bite the CE-mark holder.
CRA places legal liability for product cybersecurity squarely on the manufacturer holding the CE marking. CRA does not ask who wrote the firmware or who holds the signing key. It asks who is on the CE marking. That party is the manufacturer, and the obligation cannot be contractually delegated. Vendor agreements that purport to push CRA liability onto a module supplier or an OTA platform have no legal effect on regulator-facing obligations.
Placing your product on the EU market is what triggers the obligation. Where you are incorporated does not change anything. A manufacturer in Shenzhen exporting to Hamburg carries the same CRA exposure as a manufacturer in Munich.
CRA also recognises two roles beyond the manufacturer: an importer (who places a non-EU product on the EU market) inherits a subset of manufacturer obligations, and a distributor bears verification and reporting obligations. The primary obligation, however, sits with the manufacturer.
A €15M fine is a discrete event. A market withdrawal order touches every SKU in scope, every retail counterparty, every importer and distributor in the supply chain — and it removes the CE marking from the product line.
The fines, however, are real. CRA's penalty architecture mirrors GDPR's — same legislative tier, same percentage-of-turnover ceiling structure. Three tiers apply:
Above roughly €600M in global revenue, the 2.5% turnover figure overtakes the €15M fixed amount and becomes the operative cap. Smaller manufacturers hit the absolute floor first.
GDPR has produced fines in the €1.2 billion range (Meta, 2023). CRA inherits the same percentage-of-turnover enforcement model that produced those fines.
But financial exposure is not "fine multiplied by probability." It is fine plus recall logistics, retailer delisting, re-certification of CE-marked inventory in EU warehouses, and downstream contract penalties from importers and distributors.
Member-state market surveillance authorities have direct powers under Articles 52–58 to order corrective action, restrict or prohibit a product's availability, order its withdrawal or recall, and revoke CE marking for the product line. A recall — logistically, contractually, reputationally — can dwarf the headline fine.
Regardless of what your supplier contracts say:
For how these red lines play out when modules and components come from third parties, see Third-Party Components, First-Party Liability.
The stakes named, the next question is when the clock starts.
CRA imposes two kinds of time-bound obligations: enforcement dates that fix when CRA bites, and duration commitments that determine how long your obligations run.
Three dates govern when CRA's obligations bite, but only two of them apply to you operationally.
The two enforcement dates are not redundant. September 2026 is the operational trigger — it applies to products already placed on the market and starts the 24-hour vulnerability reporting clock. December 2027 is the market-access trigger — it applies to products newly placed on the market and requires full Annex I conformity before a product can legally be sold in the EU. The two run in parallel from December 2027 onward.
Underneath those dates, three numbers determine how long your obligations run:
The 10-year clock is the one most often missed. A consumer device that ships from 2027 to 2032 carries a documentation obligation that runs until 2042.
The 24-hour figure in that callout is the headline. The actual reporting cycle has three moments. When you become aware of an actively exploited vulnerability in your product, Article 14 requires:
A similar clock applies to severe incidents impacting product security, with the same 24-hour and 72-hour structure and a one-month final-report window. Submission is single-channel via the SRP — routing to the relevant CSIRTs and ENISA is automatic.
"Becomes aware" is the most underestimated phrase in Article 14 — it starts the 24-hour clock. By analogy with GDPR Article 33 and NIS2, regulators are widely expected to read this to include what a manufacturer ought reasonably to have known.
For your engineering programme, this changes the question. It is not "did our team see the alert?" It is "should our team have seen the alert?" Subscription to NVD, vendor security bulletins, and relevant CERT feeds becomes a legal capability, not a discretionary SLA.
Article 14 measures the clock in calendar hours. EU bank holidays, Chinese New Year, time zones — none of them stop it.
CRA's clocks — and the breadth of products they apply to — are unprecedented. Which raises the question: what does aligning to CRA actually buy you?
Aligning your team to CRA is not just an EU compliance project. It is the closest available match to what most major jurisdictions are converging toward over the next decade — which means today's investment outlasts the current text of the regulation.
Six product cybersecurity regimes are typically compared when an OEM plans a multi-jurisdictional roadmap: EU CRA, EU RED Delegated Act (via EN 18031), UK PSTI, US Executive Order 14028, ETSI EN 303 645, and IEC 62443-4-2.
Legend: ✓ MANDATORY · △ COVERED BY COMPANION STANDARD · − NOT A DIRECT REQUIREMENT
Footnotes
¹ EU RED DA (EN 18031) covers requirements via harmonised standard for radio equipment only. RED DA Article 3.3(d/e/f) makes principle-level requirements; technical details are specified by EN 18031-1/2/3 (listed in the Official Journal January 2025).
² US EO 14028 applies through federal procurement. NIST IR 8259/8259A is the IoT cybersecurity capability baseline; NIST SP 800-218 SSDF is the software development baseline. OMB M-26-05 (2026-02) reverted government-wide SBOM self-attestation requirements from M-22-18 to a risk-based approach.
³ UK PSTI Schedule 1 §1 requires unique per-device passwords (user-defined allowed), which is a credential requirement rather than a cryptographic device identity. Marked △ on this reading.
⁴ ETSI EN 303 645 §5.1 requires unique per-device passwords, not cryptographic device identities.
⁵ IEC 62443-4-2 has no dedicated anti-rollback requirement. Indirect coverage comes via CR 3.4 (software and information integrity) and EDR 3.14 (verify integrity of firmware needed for boot and runtime).
⁶ US SBOM is no longer a government-wide mandatory self-attestation following OMB M-26-05 (2026-02). SBOM can still be required by specific procurement authorities on a risk basis.
⁷ IEC 62443-4-2 does not directly require SBOM. Coverage comes from the companion standard IEC 62443-4-1:2024 (Practice 1 SM-9/SM-11 on third-party components; Practice 5 SVV-3; Practice 6 DM-1/2/3). The 2024 edition explicitly requires suppliers to provide SBOM.
⁸ IEC 62443-4-2 mandates patchability (EDR/HDR/NDR 3.10), but the vulnerability handling process itself is covered by IEC 62443-4-1 Practice 6 (DM-1 through DM-5) and IEC 62443-2-3 (patch management).
⁹ UK PSTI Schedule 1 §3 requires disclosure of a minimum security update period but does not mandate a minimum length.
CRA stands out on three measures no peer regime currently matches in horizontal scope:
(i) It is the first horizontal law to make SBOM (disclosable to market surveillance authorities), coordinated vulnerability disclosure, and a minimum support period legally binding for nearly every product with digital elements placed on the EU market. EN 303 645, RED DA, and PSTI all lack SBOM provisions. US EO 14028 covers SBOM only via federal procurement — and even there, OMB M-26-05 has reverted to a risk-based approach. NIST IR 8259 is a baseline, not a mandate. On minimum support period: under UK PSTI, a vendor can declare "zero months" and remain compliant — a gap that CRA's mandatory five-year floor closes.
(ii) It imposes hard reporting clocks — 24 hours for actively exploited vulnerabilities, 72 hours for severe incidents impacting product security — that PSTI, RED DA, EO 14028, EN 303 645, and IEC 62443 do not impose.
(iii) It covers the broadest product perimeter, from consumer IoT to industrial gateways to enterprise software. Each peer regime addresses only one slice of the market: RED DA covers radio equipment, EO 14028 covers federal procurement, EN 303 645 covers consumer IoT, IEC 62443 covers industrial automation, PSTI covers consumer connectable products.
Other standards remain technically deeper in specific corners — IEC 62443-4-2 on cryptographic component requirements, EN 18031 on radio-equipment update mechanisms, FIPS 140-3 on cryptographic module certification. But none combines breadth, mandatory transparency, and time-bound obligations the way CRA does.
Even so, the policy direction is set globally: UK PSTI and US EO 14028 (in the table above) are joined by Japan's METI Cybersecurity Guidelines for IoT, Singapore's Cybersecurity Labelling Scheme, and Australia's Code of Practice for Securing the IoT — each different in scope and binding force, but each pointing toward CRA's outcome-based model rather than away from it.
CRA is not Europe asking you to do more security work. It is Europe making the security work you should already be doing legally enforceable. The teams that internalise that today are aligned with the next decade of global product security regulation — not just the next 18 months in Brussels.
This overview reflects Snowball's reading of CRA's text and EC/ENISA guidance through April 2026. It is not a legal opinion.
This article is part of Snowball's CRA series for IoT OEMs.
