The EU Cyber Resilience Act’s incident and vulnerability reporting obligations took effect on September 11, 2026. Any manufacturer β inside or outside the EU β that places a “product with digital elements” on the EU market (software, IoT devices, industrial and OT equipment, networking gear, embedded systems, and more) must now report actively exploited vulnerabilities and severe security incidents through ENISA’s Single Reporting Platform: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days of a fix. The obligation applies even to legacy products already sold years ago. Penalties reach β¬15 million or 2.5% of global annual turnover, whichever is higher. Legal, compliance and product-security teams need an operational reporting workflow in place now, not a policy document that assumes there is time to build one later.
This is a general summary of a public EU regulation and is not legal advice. Companies should confirm applicability and specific obligations with qualified EU regulatory counsel.
- What changed? The Cyber Resilience Act’s Article 14 reporting duties for actively exploited vulnerabilities and severe incidents became legally binding on September 11, 2026, ahead of the Act’s full essential-requirements deadline in December 2027.
- Who is affected? Manufacturers of hardware and software “products with digital elements” sold into the EU market, including non-EU companies, importers and, in some circumstances, distributors β regardless of when the product was originally placed on the market.
- What are the clocks? 24-hour early warning, 72-hour follow-up notification, and a final report within 14 days after a corrective measure is available (or one month for incidents without a fix yet).
- What to do this week? Confirm who in your organization is authorized to file on the Single Reporting Platform, map which products are in scope, and rehearse the 24-hour clock with your security and legal teams together.
What the Cyber Resilience Act actually requires, starting now
The Cyber Resilience Act (CRA) is the EU’s horizontal cybersecurity regulation for products with digital elements β a category broad enough to cover consumer software, connected devices, industrial control systems, medical devices with software components, and networking and telecom equipment, among much else. The CRA’s full set of essential cybersecurity and vulnerability-handling requirements does not become mandatory until December 11, 2027. But the Act deliberately front-loaded one obligation: reporting. As of September 11, 2026, manufacturers must report actively exploited vulnerabilities in their products, and severe incidents having an impact on the security of those products, to the relevant national Computer Security Incident Response Team (CSIRT) and to ENISA, the EU’s cybersecurity agency, using the CRA’s new Single Reporting Platform (SRP).
The reporting timeline has three stages. An early warning is due within 24 hours of a manufacturer becoming aware of an actively exploited vulnerability or a severe incident, giving only basic details β what is known, and nothing more, since the point is speed. A more complete notification is due within 72 hours, updating the initial report with a fuller assessment. A final report is due within 14 days of a corrective or mitigating measure becoming available; where a fix is not yet ready, an interim update is expected within one month, followed by a final report once remediation exists.
Who is actually in scope β and the legacy-product trap
The CRA applies to any manufacturer that places a qualifying product on the EU market, whether or not the manufacturer itself is based in the EU. A US, UK or Asia-based software or hardware company that sells, licenses or otherwise makes available a product with digital elements to EU customers is in scope on the same terms as an EU-headquartered manufacturer. Importers and distributors carry secondary obligations, including verifying that a manufacturer has met its duties and, in some cases, notifying authorities themselves if they identify a risk the manufacturer has not addressed.
The detail most legal teams underestimate is that the reporting obligation is not limited to newly launched products. It reaches products already on the market, including ones sold years ago, if they still qualify as “products with digital elements” being made available in the EU and a covered vulnerability or incident is later discovered. Products that have reached end-of-life or end-of-support are not automatically exempt if they remain in the field and in use β a point that has drawn specific attention from compliance advisors because it forces companies to maintain reporting-readiness for their installed base, not just their current product line.
How the CRA clock interacts with your other breach-notification obligations
Most multinational companies already operate under at least one, and often several, overlapping incident- or breach-notification regimes: GDPR’s 72-hour personal-data-breach notice to data protection authorities, the EU’s NIS2 Directive’s incident reporting for operators of essential and important entities, and β for US-listed issuers β the SEC’s four-business-day Form 8-K disclosure of material cybersecurity incidents. The CRA adds a fourth, product-centric clock that runs on its own timeline (24 hours, not GDPR’s 72, for the very first notification) and is triggered by the product’s vulnerability status rather than by whether personal data was exposed or the incident is financially material to investors.
This matters operationally because a single security event can now trigger three or four separate, differently timed notification obligations to different regulators, using different thresholds for what counts as reportable. A legal or compliance team that has only mapped GDPR and NIS2 workflows is missing a faster clock that starts on a different trigger. The practical fix is a single incident-response intake process that immediately screens every confirmed security event against all applicable regimes β GDPR, NIS2, CRA, sectoral rules (e.g., DORA for EU financial entities), and any securities-disclosure obligations β rather than routing the event to whichever team happens to receive it first.
Why this is a legal-team problem, not just a security-team problem
Because the CRA’s obligations run to the corporate entity and carry fines of up to β¬15 million or 2.5% of worldwide annual turnover β whichever is higher β general counsel and compliance leadership have direct exposure here even though the underlying technical facts originate with product security teams. Two failure modes are most common in the early months of a new reporting regime like this: security teams identify an actively exploited vulnerability but do not know that a 24-hour external filing clock exists, so the first notification is filed late; or legal teams know the CRA exists in the abstract but have never been told, in real time, that a specific active exploitation has been confirmed, because no internal escalation path connects security findings to the legal function fast enough to make a 24-hour deadline achievable.
Vendor and supply-chain contracts add another layer. If your company integrates third-party software or components into a product you place on the EU market, you may be relying on those suppliers to tell you about vulnerabilities in their code fast enough for you to meet your own 24-hour clock as the manufacturer of the finished product. Contracts that do not specify a supplier notification deadline meaningfully shorter than your own regulatory deadline leave a structural gap.
Concrete steps for this week
Identify and document, in writing, which named individuals are authorized to submit reports on ENISA’s Single Reporting Platform, and confirm they have working platform access today rather than after an incident starts the clock. Work with product and engineering leadership to build or refresh an inventory of every product with digital elements your company places on the EU market, explicitly including legacy and end-of-life products still in customer use. Run a tabletop exercise that starts from “security has just confirmed active exploitation of a vulnerability in an EU-market product” and walks the full chain β security detection, internal escalation, legal review, and SRP filing β against a real 24-hour clock, to find out where the process actually breaks. Review supplier and vendor contracts for security-notification timelines that are fast enough to support your own CRA deadlines, and add or tighten those clauses where they are not. Finally, confirm how your CRA reporting workflow connects to your existing GDPR, NIS2 and (if applicable) securities-disclosure processes so the same incident is not evaluated four separate times by four teams that never compare notes.
What to watch next
Watch for ENISA guidance clarifying edge cases in the “actively exploited” and “severe incident” definitions, since early practice under any new reporting regime tends to generate interpretive questions faster than formal guidance answers them. Watch for the first public enforcement actions or fines under the reporting obligation, which will be the clearest signal of how strictly national authorities intend to apply the 24-hour standard in practice. And keep December 11, 2027 on the compliance calendar β that is when the CRA’s full essential cybersecurity requirements, covering secure-by-design obligations, vulnerability handling processes and conformity assessment, become mandatory on top of the reporting duty that is already live today.
Does the CRA apply to us if we have no EU office?
Yes, if you place a qualifying product with digital elements on the EU market β physical location of the manufacturer does not determine scope.
What counts as an “actively exploited vulnerability”?
In general terms, a vulnerability that has evidence of exploitation in the wild, as opposed to one that has only been theoretically identified or privately disclosed with no known exploitation.
Do we need to report every vulnerability we find?
No. The September 2026 obligation is specifically triggered by active exploitation and severe incidents, not by the discovery of a vulnerability with no evidence of exploitation.
Where do we actually file?
Through ENISA’s Single Reporting Platform, which routes the report to the relevant national CSIRT and to ENISA.
What happens if we miss the 24-hour deadline?
Late or missed reporting exposes the company to the CRA’s penalty regime, up to β¬15 million or 2.5% of global annual turnover, and should be treated as a genuine deadline, not a target.
Sources: European Commission, Shaping Europe’s Digital Future β “Cyber Resilience Act: Reporting Obligations”; Crowell & Moring, “EU Cyber Resilience Act: September 11, 2026 Reporting Deadline”; Steptoe and Mondaq client alerts on CRA vulnerability and incident reporting entering into force; Pearl Cohen, “EU Cyber Reporting Obligations Take Effect on September 11.”
Discover more from Kurums | Business Intelligence
Subscribe to get the latest posts sent to your email.