On 11 September 2026 the Cyber Resilience Act (Regulation (EU) 2024/2847) switches on its reporting regime. From that date, any manufacturer of a product with digital elements sold in the European Union has 24 hours to file an early warning the moment it detects that one of its vulnerabilities is being actively exploited, or that it has suffered a severe incident affecting the product's security.
The part that gets missed is who is on the hook. The incident reporting most people associate with NIS2 falls on essential and important entities; the CRA's falls on whoever makes the product and places it on the market. Different parties, different duties — and plenty of software and hardware companies assume that if they are not an essential entity, none of this concerns them. It does.
The regulation is already in force. What begins in September is the part that demands the most operational discipline: report fast, with a written procedure and someone empowered to decide under pressure. It is worth walking through exactly what it requires, who it reaches and what you need to have ready.
What a board needs to know before the detail:
- From 11 September 2026 the CRA reporting regime applies (Article 14).
- The cascade has three stages: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days once a fix is available (one month for severe incidents).
- Reports go to the national CSIRT and to ENISA through the Single Reporting Platform.
- It binds manufacturers of products with digital elements — hardware and software — including those already on the market.
- The bulk of the regulation (essential requirements, CE marking) applies in full on 11 December 2027.
- Penalties reach EUR 15 million or 2.5% of worldwide turnover (Article 64).
What starts on 11 September
The CRA creates a reporting duty for two specific triggers: a vulnerability that is being actively exploited, and a severe incident affecting the product's security. Not every flaw and not every glitch: the trigger is active exploitation or severe impact, and that is the first operational decision an organisation needs settled in advance.
The three stages of the deadline
As the analyses by Crowell & Moring and Hogan Lovells of Article 14 set out, the notification is staged: an early warning within 24 hours of becoming aware; a more detailed notification within 72 hours; and a final report at 14 days, once a fix or mitigating measure is available. For severe incidents the final report extends to one month. Submissions go to the national CSIRT and to ENISA through the Single Reporting Platform, which the regulation requires to be operational by that date.
The short deadline does not reward the perfect report; it rewards the timely one. The 24-hour warning is a first communication with what is known, and the detail follows. What the mechanism does not tolerate is discovering mid-incident that nobody knows who drafts that first warning, or who signs it off.
Which products it covers
The scope is broad. According to the European Commission's official summary of the regulation, the CRA is the first EU-wide law to set mandatory cybersecurity requirements for products with digital elements — hardware and software — across their whole lifecycle. The reporting duty is not limited to new launches: it also covers products already on the market. The full secure-by-design requirements and CE marking apply in full on 11 December 2027, but the reporting piece is brought forward to September 2026.
“This is for the big players”: why half the sector thinks it is exempt
On paper the duty is clear; in practice it collides with four widely held beliefs among product makers:
- “We are an SME, this is for multinationals.”
- “We sell a cloud service, not a product.”
- “We integrate open source; responsibility sits with the community.”
- “We already passed ISO 27001 and we are preparing for NIS2; that covers it.”
None of the four survives the text of the regulation. Each is worth taking in turn, because each hides a different misunderstanding of what the CRA actually governs.
Why it does apply to you
Size does not exempt you
Unlike NIS2, which uses size and sector thresholds to decide who is an essential or important entity, the CRA's reporting duty attaches to the product placed on the market, not to headcount or revenue. An SME that makes a connected device or distributes an application is in scope for what it sells, not for what it earns.
The SaaS/product line is exactly where to look
The “service, not product” argument is the one that needs the most nuance. The CRA covers products with digital elements and the remote data processing solutions that form part of the product. A standalone cloud service may fall under NIS2 instead; but remote components that are an integral part of a product are within the CRA's scope. The test is not the commercial label but whether that component is part of the product being placed on the market. That distinction is precisely what has to be assessed case by case, not waved away with “we do SaaS”.
Open source does not transfer your responsibility
As the Hogan Lovells analysis explains, the manufacturer owes due diligence over the open-source software it integrates into its product, and must handle and report its vulnerabilities. The regulation introduces the “open-source software steward”, with its own lighter duties; but a company that takes open components and ships a product with them remains the manufacturer for CRA purposes. Here an SBOM stops being good practice and becomes the basis for knowing what affects you when a flaw surfaces in a third-party component.
NIS2 and ISO 27001 do not cover this duty
This is the costliest misunderstanding. NIS2 governs how you operate as an organisation; the CRA governs what you sell. ISO 27001 is a management system that organises your controls, but it does not replace a legal duty to notify the regulator within 24 hours. They are different objects, which is why treating security and compliance as separate boxes leaves gaps exactly here: a company meets its frameworks and still has not decided who pulls the CRA trigger.
What you need to have ready
The regulation does not ask for a phased plan; it asks for the capability to detect, decide and report, backed by evidence. In practice that is five pieces worth having standing before September — not as an endless project, but as muscle you can exercise:
A coordinated vulnerability handling and disclosure process — a PSIRT or its equivalent — with an intake channel, named owners and a clear flow from the moment a report arrives to the decision on what to do. It is the base from which the regulator notification comes, if it comes. This is where the vulnerability management capability many organisations already run half-built earns its keep.
An inventory of the software that makes up each product — maintained, not a two-year-old PDF — so you can tell within minutes which products a newly published flaw in a third-party library affects.
The ability to tell “actively exploited” from just another vulnerability. Without telemetry, threat intelligence and an agreed threshold, the 24-hour deadline becomes an improvised argument at the worst possible moment.
A written and rehearsed reporting procedure: who drafts the early warning, who approves it, how it is sent to ENISA and the CSIRT, and how everything is documented for the later report. One drill is worth more than an unused manual.
A fit with what you already have. ISO 27001 controls and NIS2 preparation give you a base, but the CRA's trigger and deadline are its own: they have to be mapped onto your existing processes rather than assumed to be covered.
What ignoring it costs
The penalty regime has three tiers. According to Taylor Wessing's summary of Article 64, breaching the essential requirements (Annex I) and the core manufacturer obligations — Articles 13 and 14, which include reporting — carries fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Other obligations, including those of importers and distributors and conformity assessment, reach EUR 10 million or 2%. Supplying incorrect or misleading information to the authorities is penalised at up to EUR 5 million or 1%.
Importers and distributors do not get a pass: they carry secondary verification and reporting duties. For anyone building an offering on third-party products, this connects to third-party risk management and to recent digital supply chain lessons.
This is not only the product team's call
The 24-hour deadline forces a governance decision before the incident happens: who makes the call, who signs the early warning, and how product, security and legal coordinate when there are only hours to act. Product security stops being an engineering matter alone and becomes a governance one — much as NIS2 put incident response on the board's agenda.
11 September does not change what has to be built; it changes how little time you have. A company that today cannot say who would send that early warning, or with what data, will find out mid-incident with the clock running. The work to do beforehand is not drafting the ideal warning: it is rehearsing the first 24 hours until they stop being handled on the fly.
This article is technical commentary and does not constitute legal advice. The obligations, deadlines and dates of the Cyber Resilience Act should be verified against the official text of Regulation (EU) 2024/2847 and the guidance from ENISA and the competent authority; the information here reflects the date of publication. To assess how it applies to a specific product, consult your legal counsel and your compliance lead.