Product law, not organisational law
NIS2 asks how you are organised. DORA asks how well you absorb a shock. The Cyber Resilience Act regulates something else entirely: what you place on the market. That is a difference in kind, not in degree — and it settles the question of who inside your company owns the file.
Regulation (EU) 2024/2847 belongs to the CE marking family, alongside the machinery and radio equipment regimes: essential requirements in an annex, conformity assessment, a mark on the product, market surveillance empowered to pull it. This is product law, not risk governance.
So the CRA is not the CISO's programme. It is the product organisation's. Hand it to the security compliance team and you will get immaculate policies and no engineering evidence: what a notified body looks for is a per-product risk assessment, requirements traced through to design decisions, a signed update channel. Wavatec writes this from both sides of the counter — we run EBIOS RM, NIS2 and DORA work for client organisations, and we publish Elyys360, which makes us a manufacturer.
The timeline is staggered, and the nearest milestone comes first
The regulation entered into force on 10 December 2024. Article 71 then phases in application: Chapter IV, which sets up the notification of conformity assessment bodies, has applied since 11 June 2026; Article 14, covering the reporting of actively exploited vulnerabilities and severe incidents, applies from 11 September 2026; everything else — the Annex I essential requirements, conformity assessment, CE marking — from 11 December 2027.
The inversion is deliberate: a vulnerability being exploited in the wild could not wait another three years. The consequence catches people late. Article 69(3) extends the reporting duties to products already placed on the market before 11 December 2027, whereas the rest of the text only reaches existing products if they undergo a substantial modification. Your installed base is therefore in scope for reporting in September 2026, whether or not product compliance work has started.
Reports go through a single reporting platform run by ENISA (Article 16), which routes the notification to the coordinating CSIRT of your main establishment. As of late June 2026 that platform was still not live. The clock, however, starts when you become aware of the facts.
You are probably in scope
The scope covers any product with digital elements made available on the Union market, hardware or software, components sold separately included: an industrial sensor, a PLC, a mobile application, an embedded firmware. Plenty of manufacturers assume they are outside it because they build machines or appliances rather than "digital products". The test is not the nature of the product but the presence of digital elements and of a data connection.
The exclusions are sectoral: medical devices (Regulations 2017/745 and 2017/746), type-approved motor vehicles (2019/2144), civil aviation (2018/1139), marine equipment (Directive 2014/90/EU), plus defence and classified information. The Machinery Regulation (2023/1230), which applies from 20 January 2027, excludes nothing: a machinery builder will have to satisfy both. And Delegated Regulation (EU) 2022/30 on radio equipment cybersecurity is set to disappear on 11 December 2027, the Commission having moved to repeal it.
Product classes and assessment routes
Self-assessment is the default. It stops being the default depending on the product's core functionality, listed in Annexes III and IV and described in technical terms by Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025.
| Category | Examples | Assessment route |
|---|---|---|
| Unclassified | Most software and connected devices | Internal control (module A) |
| Important, class I | Browsers, password managers, VPNs, operating systems, routers, SIEM systems, smart locks and cameras | Internal control if harmonised standards cover all requirements; otherwise module B+C or module H |
| Important, class II | Hypervisors and container runtimes, firewalls, IDS/IPS, tamper-resistant microprocessors and microcontrollers | Module B+C, module H, or a European certification scheme at assurance level "substantial" or above |
| Critical (Annex IV) | Hardware devices with security boxes, smart meter gateways, smartcards and secure elements | European certification scheme where one exists; failing that, the class II regime |
Class I only loses self-assessment where harmonised standards are not applied. Yet as of mid-2026 no CRA harmonised standard had been ratified or cited in the Official Journal, out of the forty-one foreseen by standardisation request M/606, accepted in April 2025: the Article 27 presumption of conformity is not yet available for any category, which tightens the 2027 deadline considerably.
The sleeper clause: the support period
This is the obligation that will cost the most, and it is rarely the one people discuss.
Article 13(8) requires a support period reflecting how long the product is expected to be in use, with a floor of five years unless expected use is shorter. Article 13(9) adds that every security update issued must remain available for at least ten years, or for the remainder of the support period if that is longer. And the end date of support has to be made clear to the buyer at the point of purchase.
Read that as a product director. You can no longer discontinue a line the day it stops paying for itself: the end date is a commitment made at the sale, for five years minimum. You have to keep build chains, test environments and skills alive on versions the roadmap left behind — every SKU added to the catalogue creates a dated maintenance debt. The real cost of the CRA is not the technical file; it is that end-of-life becomes a contractual decision rather than a commercial one. For a software publisher, that pushes towards fewer supported versions in parallel; we did this arithmetic for Elyys360 before doing it for clients. For a manufacturer shipping firmware onto hardware installed for fifteen years, it is a design problem: the product must be able to accept a signed update for the whole announced period.
SBOM: necessary, not sufficient
Annex I, Part II requires manufacturers to identify and document components and vulnerabilities, including by drawing up a software bill of materials in a machine-readable format covering at least the top-level dependencies. It forms part of the technical documentation and is provided to market surveillance authorities on a reasoned request, with no obligation to publish it.
The legal floor is low, and an SBOM that stops there is operationally useless. Four conditions make it worth having: that it is generated at build time, and so faithful to the artefact actually shipped; that components carry resolvable identifiers, the only thing that will feed automated matching against vulnerability databases; that it is retained for every version still under support, without which you cannot answer which customers are exposed; and that it comes with an exploitability position, since a good share of the CVEs surfacing in your dependencies never touch the code path you use.
The rest of Part II matters just as much: a coordinated disclosure policy, a published contact point, fixes distributed without delay and free of charge. Article 13 adds due diligence on third-party components, open source included, and an obligation to pass a discovered vulnerability back to the upstream maintainer.
Reporting within 24 hours
Article 14 sets a three-stage sequence, addressed to the coordinating CSIRT and ENISA simultaneously.
- An early warning within 24 hours of becoming aware.
- A fuller notification within 72 hours, with corrective or mitigating measures.
- A final report: within 14 days of a fix becoming available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident.
Twenty-four hours is an on-call deadline, not a committee deadline: it presumes detection that escalates, someone empowered to declare a vulnerability "actively exploited" on a Sunday evening, and a notification template ready to go. Micro and small enterprises are shielded from fines for missing the early warning alone. Everyone else faces up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher — the same ceiling that covers Annex I and Articles 13 and 14; then EUR 10 million or 2% for a set of procedural obligations; EUR 5 million or 1% for misleading information given to an authority. The fine is not the real risk. Market surveillance can order withdrawal or recall, and losing a product line's access to the European market costs more, and faster.
Open source: the steward, explained calmly
The 2023 panic left its mark, but the adopted text is measured. Free and open-source software developed and supplied outside any commercial activity stays out of scope; an individual contributor bears nothing; and when a manufacturer integrates an open-source library into a commercial product, the manufacturer carries the compliance, not the upstream project.
Between those poles, Article 24 creates an intermediate figure: the open-source software steward, a legal person other than a manufacturer that systematically and sustainably supports the development of open-source software intended for commercial activities and ensures its viability — typically a foundation. Its obligations are contained: document a cybersecurity policy, cooperate with market surveillance authorities, report actively exploited vulnerabilities from 11 September 2026. What does not apply matters as much: no CE marking, no conformity assessment, no full technical file, and Article 64(10) rules out administrative fines against stewards altogether. Article 32 separately allows the manufacturer of commercial open-source software to stay on the general-regime procedures provided it publishes its technical documentation.
How it meets NIS2, and the real gap between companies
The CRA and NIS2 do not overlap; they interlock. NIS2 requires an essential or important entity to control its supply chain security; the CRA gives it something concrete to demand, since suppliers will have to produce documentation, a stated support period and a reporting channel. Expect CRA evidence to appear in tenders well before December 2027 — buyers under NIS2 have no reason to wait. On the AI side, Article 12 opens a presumption of conformity with the cybersecurity requirement in Article 15 of Regulation (EU) 2024/1689.
Then there is the gap between companies. One that already runs a mature secure development lifecycle — threat modelling, dependency management, artefact signing, a standing PSIRT — will find the CRA an evidence exercise: formalise what exists, trace the Annex I requirements, assemble the Annex VII technical file. Twelve to eighteen months of serious but predictable work. One that ships firmware with no update process, no component inventory and no vulnerability contact point is not doing compliance; it is doing product re-engineering. Not the same budget, not the same schedule — and confusing the two at the scoping stage is the surest way to miss 2027.
What has to be in place before 11 September
Three things, none of which depends on a harmonised standard that has yet to arrive.
- Know which products in your catalogue are in scope, including those already installed at customer sites, since reporting reaches them too.
- A qualification and notification process that works within 24 hours: a named on-call, a written trigger criterion, the coordinating CSIRT identified, the template drafted.
- A disclosure contact point that is published and genuinely monitored, failing which you will learn about active exploitation of your vulnerabilities from the press.
11 December 2027 looks far away. The support period does not: any product you place on the market on that date will carry a commitment of at least five years, and that commitment is made at design time, not at the declaration of conformity.
