The short answer
From 11 September 2026, the EU Cyber Resilience Act's Article 14 requires manufacturers of products with digital elements to report actively exploited vulnerabilities to ENISA and national computer security incident response teams (CSIRTs) within 24 hours of discovery. A triage report with a resolution pathway follows at 72 hours; a final remediation report is due within 14 days. The obligation catches every manufacturer shipping software or connected hardware to the EU, including US-based companies.
The CRA entered into force on 11 December 2024. Its full conformity requirements — CE marking, conformity assessments, software bills of materials — apply from 11 December 2027. The reporting deadline on 11 September 2026 is the first operationally significant checkpoint, and it arrives in days, not months. Teams that have not yet built vulnerability management and security audit workflows mapped to CRA's timelines should treat this as the prompt to do so.
What changes on 11 September
The Cyber Resilience Act (Regulation (EU) 2024/2847) introduced a framework of cybersecurity requirements for any product with a digital component sold in the EU. The regulation is structured in waves: the heaviest obligations — conformity assessments, CE marking, SBOM maintenance — do not apply until December 2027. The reporting wave arrives first, and it arrives this month.
Article 14 covers two categories of event. First, actively exploited vulnerabilities: security flaws in a manufacturer's product that threat actors are using right now, in any deployment context, not only against the manufacturer's own customers. Second, severe security incidents: events with a significant impact on the security of a product, including incidents capable of affecting data protection, introducing malicious code into a supply chain, or compromising a development or production environment. In both cases, the trigger is the manufacturer becoming aware — there is no grace period for internal investigation before the 24-hour clock starts.
ENISA will operate a Single Reporting Platform that routes each submission to ENISA itself and to the national CSIRT in the member state where the manufacturer is established or, for non-EU manufacturers, the member state designated as point of single contact. The platform is designed to accept machine-readable notifications and to avoid manufacturers filing four separate reports across four different portals for a single incident.
The 24-h / 72-h / 14-day reporting clock
The timeline is precise. Once a manufacturer is aware of a qualifying event:
- 24 hours — Early warning. A preliminary notification to ENISA and the national CSIRT. The regulation does not require a full technical analysis at this stage, but the notification must confirm the event, the affected product and the preliminary impact assessment. The intent is to give authorities visibility before information travels further, not to demand a complete incident report overnight.
- 72 hours — Triage report. A more detailed submission including severity assessment, any initial mitigation measures taken, and a resolution pathway. If a patch is already available, that should be noted. If not, the plan for producing one should be described.
- 14 days — Final report (vulnerabilities) / 30 days (incidents). A complete account of the vulnerability or incident, the corrective measures applied, and their effectiveness. For incidents, the window extends to 30 days from when the manufacturer became aware.
For teams used to GDPR's 72-hour breach notification window, the CRA's 24-hour opening report is meaningfully shorter. For teams used to coordinated vulnerability disclosure (CVD) timelines that run 90 days or more, the contrast is sharper still. The practical implication is that vulnerability detection and internal escalation cannot be a slow process: the moment the security team confirms active exploitation, legal and compliance need to be in the loop within hours, not days.
Who must comply — including US vendors
The CRA's obligations fall on manufacturers: companies that design, develop or produce products with digital elements, or have them designed, developed or produced and then place those products on the EU market under their own name or trademark. The definition is intentionally broad. It covers commercial off-the-shelf software, SaaS platforms, mobile applications, consumer IoT devices, industrial control systems, embedded firmware and network equipment.
Importers and distributors carry lighter but real obligations: they must verify manufacturer compliance and, in some circumstances, act as the responsible entity if a manufacturer outside the EU cannot be identified. But the core Article 14 reporting duty sits with the manufacturer.
The geographic trigger is the EU market, not EU incorporation. A US-based software vendor whose product is available to enterprise or consumer customers in Germany, France or any other EU member state is a manufacturer under the CRA. The same applies to UK companies post-Brexit, Canadian SaaS providers, and any other non-EU entity. If your product is sold or distributed in the EU, you are in scope, and you need a reporting pathway to ENISA's SRP before 11 September.
Overlapping with GDPR, NIS2 and DORA
The CRA is the fourth major EU digital compliance framework to arrive alongside GDPR, NIS2 and DORA, and the four share enough architectural DNA — 24-hour early warnings, tiered follow-up reports, notification to designated authorities — to create coordination risk if treated as separate programmes.
A ransomware attack on a connected device, for instance, might simultaneously trigger: a CRA Article 14 report to ENISA (within 24 hours, as a severe incident); a GDPR Article 33 notification to the supervisory authority (within 72 hours, if personal data is affected); a NIS2 significant incident report (within 24 hours, if the manufacturer is an essential or important entity); and, for financial-sector SaaS vendors, a DORA major incident report (within 4 hours for high-severity events). Each notification goes to a different authority, follows a slightly different template and has different follow-up deadlines.
The practical risk is not that teams forget to report; it is that they build four independent silos and either miss one reporting window because the wrong team owned the notification, or send contradictory information to different regulators about the same event. The right architecture is a single incident-triage workflow that takes as input the confirmed fact of an incident and produces, as output, the correct set of notifications to the correct authorities on the correct timelines. That workflow needs to be mapped, documented and tested before 11 September — because the first real incident is a bad time to discover the process does not work. Building a unified GDPR and multi-regulation compliance programme is how teams that sell into Europe typically handle this; the CRA adds a new lane to an existing motorway rather than building an entirely new road.
What it means for US & EU software teams
The operational shift is real, and it is worth naming precisely. Before 11 September, a software vendor with an actively exploited vulnerability in its product could manage the disclosure timeline at its own pace: CVD processes typically gave months; voluntary disclosure to authorities was exactly that, voluntary. From 11 September, the state has a mandatory first call on that timeline — 24 hours, every time, whether or not the vendor is ready, whether or not the patch is ready, whether or not the exploit is public.
For engineering teams, the implication is instrumentation: you cannot report an actively exploited vulnerability you do not know about. Continuous monitoring of threat intelligence feeds, vendor advisories and your own telemetry for signs of exploitation is no longer a best practice for mature teams; under Article 14 it is a prerequisite for compliance. The same applies to having a clear internal definition of what "becoming aware" means — because the clock starts when your organisation knows, not when the CISO writes the brief.
For product managers and founders of EU-facing SaaS products, the implication is process ownership: the CRA reporting obligation sits with the manufacturer, not the customer, not the cloud provider and not the security consultant. If your product is in scope, your legal entity is the one with the 24-hour clock, and you need a named person who knows what to file and where.
The wider strategic read is that the CRA is pulling EU cybersecurity standards up toward what mature enterprise buyers in regulated sectors — banking, healthcare, critical infrastructure — have required for years. Teams already running SOC 2 Type II programmes or GDPR-aligned incident-response processes will find the CRA's mechanics familiar. Teams that have been informally managing security will find the CRA is the forcing function that turns informal practice into documented, auditable process.
What to do before 11 September
The checklist is not long, but each item needs to be genuinely done, not planned.
- Confirm scope. List every product your company places on the EU market. If it has a digital component — any software, firmware, connectivity — it is likely in scope. Legacy products already on the market before the CRA entered into force may also be covered if they receive software updates.
- Define "becoming aware" internally. Set a bright-line threshold for when your organisation is considered to know about an actively exploited vulnerability. This determines when the 24-hour clock starts. Ambiguity here creates compliance risk.
- Build continuous monitoring. You cannot report what you cannot detect. Establish or contract threat intelligence and telemetry monitoring for signs of active exploitation across your product portfolio.
- Assign a notification owner. Designate the person (and a deputy) responsible for filing CRA reports. They should have the authority to notify authorities without a long internal approval chain that would eat into the 24-hour window.
- Register with ENISA's SRP. The Single Reporting Platform opens on 11 September 2026. Pre-register if ENISA opens early access; at minimum, verify your access credentials are ready before the deadline.
- Draft report templates. Article 14's three-stage reporting structure is predictable. Prepare templates for the 24-hour early warning, 72-hour triage report and 14-day final report now, so that under time pressure your team is filling in facts rather than writing format.
- Map regime overlaps. If you also have NIS2, DORA or GDPR obligations, confirm that a CRA-triggering incident flows correctly into all applicable reporting workflows.
Frequently asked questions
What does the CRA require from 11 September 2026?
From 11 September 2026, manufacturers of products with digital elements placed on the EU market must submit an early warning to ENISA and their national CSIRT within 24 hours of becoming aware of an actively exploited vulnerability or a severe security incident. A triage report with a resolution pathway follows within 72 hours, and a final report is due within 14 days of a patch being available (30 days for incidents).
Who does the CRA reporting obligation apply to?
Any manufacturer placing products with digital elements on the EU market — including software, SaaS, mobile apps, IoT devices and embedded systems — is covered. Importers and distributors have lighter obligations. Crucially, the rule applies based on where the product is sold, not where the manufacturer is headquartered, so US, UK and other non-EU companies shipping software or devices into Europe are fully in scope.
What counts as an actively exploited vulnerability under the CRA?
A security flaw in a manufacturer's product that threat actors are actively leveraging — in any deployment environment, not only against that manufacturer's own customers. The regulation also covers severe security incidents, including events capable of affecting data protection, introducing malicious code into a supply chain, or compromising development or production environments.
How does CRA reporting interact with GDPR, NIS2 and DORA?
All four frameworks share a 24-hour early-warning structure but route to different authorities and carry different follow-up timelines. A single incident can trigger obligations under multiple regimes simultaneously. Build a unified incident-triage workflow that identifies which regimes apply and produces the correct notification to each regulator on the correct schedule, rather than running separate compliance processes for each framework.
What should software teams do before 11 September 2026?
Confirm which products are in scope; define internally when the 24-hour clock starts; build or contract continuous vulnerability monitoring; assign a named notification owner with direct authority to file; register with ENISA's Single Reporting Platform; draft 24-hour, 72-hour and 14-day report templates; and map overlapping obligations under GDPR, NIS2 and DORA to avoid missed or contradictory notifications.
Sources
European Commission — CRA Reporting Obligations (primary regulatory source)
DLA Piper — The CRA’s 24-Hour Rule: Preparing for September 2026 Reporting Obligations (August 2026)
Crowell & Moring — EU CRA: September 11, 2026 Reporting Deadline