The short answer
The EU Cyber Resilience Act’s reporting duty is now in force. As of September 11, 2026, any manufacturer of a “product with digital elements” sold in the EU must report actively exploited vulnerabilities and severe incidents to ENISA and its national CSIRT — an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days. The clock starts when you become aware, not when you finish confirming, and the rule reaches products already on the market and vendors based outside the EU.
For engineering leaders, the sting is that this is a process obligation with a fast clock, arriving more than a year before the CRA’s design-and-documentation requirements. Knowing an exploited flaw exists is no longer just an internal severity call; it is the start of a regulatory timeline. The teams that will handle it calmly are the ones who treat exploited-vulnerability detection and disclosure as a rehearsed capability — the same muscle we build into a penetration test and security audit, where finding and triaging real, exploitable issues is the whole point.
What went live on September 11
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU’s horizontal cybersecurity law for “products with digital elements” — effectively any software or hardware that can connect to a device or network, from firmware and operating systems to mobile apps, SaaS-adjacent components, and connected consumer gear. Most of its obligations, covering secure design, documentation, and conformity, do not apply until December 11, 2027. But the regulation front-loaded one duty, and that duty went live on September 11, 2026: the obligation to report.
From that date, a manufacturer that becomes aware of a vulnerability in its product being actively exploited, or of a severe incident affecting the product’s security, must notify the EU Agency for Cybersecurity (ENISA) and the relevant national Computer Security Incident Response Team (CSIRT). The timeline is staged and tight: an early warning within 24 hours of becoming aware, a fuller technical notification within 72 hours, and a final report within 14 days of a corrective measure becoming available for exploited vulnerabilities — or within one month for severe incidents.
Two design choices make this heavier than it looks. First, the trigger is awareness, not confirmation: independent legal analyses stress that the clock begins when a manufacturer becomes aware of the issue, so a team cannot run a leisurely internal investigation and start counting later. Second, reports flow through ENISA’s new Single Reporting Platform, which went live the same day; at launch it is a manual web portal with no public API and no voluntary-reporting channel, so submission cannot yet be scripted into an incident pipeline. A CSIRT that receives the report shares it with other relevant national teams.
Who is in scope — including US teams
The most common misread is that this is an EU-company problem. It is not. The obligation attaches to placing a product on the EU market, so a US, UK, or other non-EU manufacturer that ships software, a SaaS-delivered component, or a connected device to EU customers is squarely in scope. A vendor headquartered in Austin or London with European users inherits the same 24-hour clock as a Berlin one. That extraterritorial reach is deliberate, and the enforcement backstop is real: administrative fines can reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
The second surprise is the reach into the installed base. The reporting duty is the one part of the CRA that applies to products already on the market, not only to new ones placed after a future cutoff. Firmware shipped years ago, a library bundled into a device, or an application released long before the CRA entered into force all sit inside the obligation from September 11 if a contained vulnerability is being actively exploited. For teams that build durable, long-lived products — and for anyone shipping custom software that lands inside a client’s connected product — the practical consequence is that legacy code you no longer actively develop can still generate a same-day reporting event.
Open-source stewards get more runway: their specific obligations are set to apply later, on December 11, 2027, in recognition of how non-commercial maintainers differ from manufacturers. But commercial vendors that package open-source components into a product do not get to defer — if the shipped product has an exploited flaw, the manufacturer placing it on the market is the one that reports.
What it means for US & EU software teams
The first shift is that vulnerability handling becomes a regulated timeline, not an internal preference. Many teams already run a coordinated-disclosure process, but on their own cadence. The CRA fixes the cadence for the worst case: exploited-in-the-wild. That means you need an unambiguous internal definition of “aware” and “actively exploited,” a named decision-maker who can make that call outside business hours, and a report you can complete without a week of drafting. Bake this into the same security discipline you apply across your cloud and DevOps pipeline — asset inventory, dependency and SBOM visibility, and monitoring — because you cannot report on a 24-hour clock about a product whose components you cannot enumerate.
The second shift is evidence and traceability. A staged report at 24 hours, 72 hours, and 14 days is, in effect, a demand for a timeline you can reconstruct: when you learned of the issue, what you knew at each step, what the corrective measure was, and when it shipped. Teams that log detection, triage, and patch decisions as first-class events will produce that narrative almost for free; teams that treat security work as tribal knowledge will scramble to assemble it under a regulator’s deadline. This is the same posture that GDPR’s 72-hour breach notification rewarded — the CRA simply extends that reflex from personal-data incidents to product security.
The third shift is overlap and de-confliction. A single exploited flaw can now trigger CRA reporting alongside GDPR breach notification, and, for critical-infrastructure operators, NIS2 or DORA incident duties — each with its own recipient and clock. For FinTech and HealthTech vendors especially, the answer is not to run parallel, ad-hoc processes but to design one incident workflow that fans out to the right regulators with the right content and timing. Getting that plumbing right in advance is far cheaper than discovering the conflicts mid-incident.
What to do now
- Confirm your market exposure. List every product with digital elements you make available in the EU — including SaaS-delivered and embedded components, and legacy items still in the field. If any reach EU users, you are in scope regardless of where you are based.
- Define “aware” and “actively exploited.” Write down the criteria and the named owner who decides. Ambiguity here is what burns the 24-hour window, because the clock starts at awareness, not at the end of your investigation.
- Pre-stage the reports. Draft the 24-hour, 72-hour, and 14-day templates now, and get an account and workflow ready on ENISA’s Single Reporting Platform. With no API at launch, filing is manual — rehearse it so it is muscle memory, not improvisation.
- Wire it into engineering. Make sure detection, dependency and SBOM visibility, and patch decisions are logged as events, so the report’s timeline assembles itself. You cannot notify quickly about components you cannot see.
- De-conflict with GDPR, NIS2, and DORA. Map which incidents trigger which duties, and design one workflow that routes to each regulator with the correct content and clock instead of separate, competing procedures.
Frequently asked questions
What changed on September 11, 2026?
The reporting obligations of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) became applicable. Manufacturers of products with digital elements sold in the EU must now report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT. The broader CRA cybersecurity requirements apply later, on December 11, 2027, but the reporting duty is live now.
What is the reporting timeline?
For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective measure is available. Severe incidents follow the 24-hour and 72-hour steps with a final report within one month. The clock starts at awareness, not at the end of internal confirmation.
Does it apply to companies outside the EU?
Yes. The duty attaches to making a product available on the EU market, so a US, UK, or other non-EU manufacturer selling software, a SaaS component, or a connected device to EU customers is in scope. Fines can reach 15 million euro or 2.5% of worldwide annual turnover, whichever is higher.
Are legacy products covered?
Yes. The reporting obligation reaches products already on the EU market, not just new ones. A router, firmware image, library, or application shipped before the CRA entered into force is inside the duty from September 11, 2026 if it contains an actively exploited vulnerability. It is the part of the CRA that touches the installed base first.
How do you submit a report?
Through ENISA’s Single Reporting Platform (SRP), live since September 11, 2026. It routes the notification to the CSIRT in your primary member state and on to other relevant national teams. At launch it is a manual web portal with no public API and no voluntary-reporting option, so the practical move is to prepare templates, owners, and decision rules before an incident rather than trying to automate submission.
Sources
European Commission — Cyber Resilience Act: Reporting obligations
TechHQ — EU Cyber Resilience Act reporting: what changed on September 11
Crowell & Moring — EU CRA: 11 September 2026 incident/vulnerability reporting deadline