Cyber Resilience Act reporting became a legal obligation today, September 11, 2026. For a lot of vendors selling connected products into the European Union, it arrived faster than the rest of the regulation did. Most of the EU Cyber Resilience Act (CRA) doesn’t apply in full until December 2027 but Article 14’s reporting duty is live right now, and it runs on a clock measured in hours, not months.
If your organization manufactures software, IoT devices, or any product with digital elements sold in the EU, Cyber Resilience Act reporting isn’t something to plan around later in the year. It’s an active obligation as of today, and it applies whether or not you’ve finished redesigning your product for CRA compliance.
This guide covers what actually triggers Cyber Resilience Act reporting, the exact 24/72-hour/14-day timeline, where reports go, and a practical first-response workflow your security, engineering, legal, and compliance teams can run together the next time this clock starts ticking.
Quick Answer
Cyber Resilience Act reporting is the EU legal requirement, effective September 11, 2026, for manufacturers of products with digital elements to notify their national CSIRT and ENISA within 24 hours of becoming aware of an actively exploited vulnerability or a severe security incident, followed by a fuller notification within 72 hours and a final report within 14 days (vulnerabilities) or one month (incidents).
What Changed Today: Article 14 and the CRA Reporting Trigger
The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force back in December 2024, but its obligations don’t all land at once they phase in over several years. Article 14, the vulnerability and incident reporting duty, is the first one to actually bite. It applies from September 11, 2026, more than a year before the CRA’s general application date of December 11, 2027.
In practice, that means Cyber Resilience Act reporting obligations now sit alongside the design-phase requirements everyone’s been writing about, not after them.
Here’s the part that catches teams off guard: this duty isn’t limited to new products. It also covers products with digital elements already placed on the EU market legacy software and hardware shipped years ago included.
If you have a connected product in the EU today, you’re already in scope for Cyber Resilience Act reporting. Whether the product itself has been redesigned for CRA compliance yet doesn’t change that.
Who Must Comply With Cyber Resilience Act Reporting
The CRA applies to manufacturers of “products with digital elements” (PDEs) hardware or software, or their remote data processing solutions, whose intended or reasonably foreseeable use involves a direct or indirect connection to a device or network. That’s a broad net: IoT devices, routers, connected machinery, smartphones and laptops, smart home products, firewalls, business software, games and apps, and commercially supplied open-source software all fall inside it.
Coverage follows where the product is sold, not where the company sits on a map. A SaaS vendor, IoT manufacturer, or security tool provider based outside the EU including in India is fully in scope for Cyber Resilience Act reporting the moment its product reaches the EU market.
Indian software exporters and hardware manufacturers with EU customers should treat this exactly the way domestic EU vendors do: figure out which products qualify as PDEs, and build reporting readiness now rather than after an incident forces the question on you.
What Counts as Reportable: Exploited Vulnerabilities vs. Severe Incidents
Cyber Resilience Act reporting is triggered by two distinct categories, and the distinction matters a lot most vulnerabilities never trigger it at all.
Actively exploited vulnerability: a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner’s permission. Discovering a CVE in a dependency, a researcher’s proof-of-concept, or a bug-bounty report with no evidence of malicious use does not by itself trigger reporting. The CRA is explicit about separating good-faith security research from malicious exploitation, which is a relief for teams that run active bug-bounty programs.
Severe incident: an incident that either (a) negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or (b) has led, or is capable of leading, to malicious code being introduced or executed in the product or in a user’s systems.
The CRA doesn’t set a single numeric severity threshold here. That’s exactly why manufacturers need documented, consistent triage criteria you don’t want to be arguing definitions while the clock is already running.
The Timeline: 24 Hours, 72 Hours, 14 Days
This is the part that makes Cyber Resilience Act reporting operationally demanding, not just legally new:
- 24 hours – Early warning to your national CSIRT and ENISA, from the moment you become aware of the vulnerability or incident.
- 72 hours – Fuller notification, including an initial assessment and any corrective or mitigating measures taken.
- 14 days – Final report after a corrective measure (e.g., a patch) is available, for actively exploited vulnerabilities.
- 1 month – Final report after the initial notification, for severe incidents.
The clock starts at awareness, not at the moment a fix exists or a root-cause analysis wraps up. That distinction trips people up. Security teams that haven’t defined internally what “becoming aware” actually means which alerts count, on which channel, reviewed by whom are the most likely to blow through the 24-hour window on their first real Cyber Resilience Act reporting event, and it’s usually not because they didn’t care. It’s because nobody had written the definition down before it mattered.
Where to Report: The Single Reporting Platform and CSIRT Routing
Manufacturers report once, through the CRA’s Single Reporting Platform (SRP), established under Article 16 and operated by ENISA. The platform automatically routes the notification to the CSIRT designated as coordinator in the manufacturer’s country of main establishment, and barring exceptional circumstances simultaneously to ENISA. Non-EU manufacturers, including Indian vendors, follow a defined fallback chain to work out their coordinating CSIRT.
One practical detail worth knowing before your first Cyber Resilience Act reporting submission: the SRP ships without an API at launch. Every mandatory report goes through the web portal manually even organizations with fully automated SBOM and vulnerability-monitoring pipelines will need a manual handoff at the point of filing. Build that step into your runbook now, so it isn’t a surprise mid-incident.
Is the Reporting Platform Actually Live Today?
This is the genuinely time-sensitive part of the story, and it’s worth sitting with for a moment. As late as September 1, 2026, ENISA’s Single Reporting Platform had no published public URL, and as of August 31, functional and security testing were still described as “underway.” ENISA has said the platform is scheduled to go live on September 11, 2026 the same day Cyber Resilience Act reporting becomes mandatory with the address to appear on ENISA’s SRP page before go-live. The list of national CSIRTs designated as coordinators for all 27 Member States was only published on September 4, 2026, days before the deadline itself.
Practically speaking: if you’re checking today, confirm the platform’s live status and your correct coordinating CSIRT directly on ENISA’s SRP hub rather than assuming your organization can file immediately. And register for a dry run now discovering the portal for the first time during a real incident is an avoidable, unforced error.
First-24-Hours Workflow for Security, Engineering, Legal, and Compliance
Cyber Resilience Act reporting isn’t a legal-team-only task. It fails without cross-functional coordination in the first hours, and the handoffs matter as much as the deadlines themselves:
- Hour 0–2 (Security): Detect and triage. Confirm the finding actually meets the “actively exploited” or “severe incident” definition above not just a raised CVE.
- Hour 2–8 (Security + Engineering): Classify severity and scope. Identify affected product versions using your SBOM. You genuinely cannot answer “which deployed versions are affected” without one.
- Hour 8–18 (Compliance + Legal): Draft the early warning using a pre-filled report template product, version, CVE, nature of exploitation, measures taken. Confirm the correct coordinating CSIRT for your main establishment while you’re at it.
- Hour 18–24 (Compliance): File through the Single Reporting Platform. Confirm routing to both the CSIRT and ENISA. Log the submission timestamp you’ll need it for the 72-hour and 14-day follow-ups.
Building this runbook, and registering on the SRP, before an incident happens is probably the single highest-leverage step any team can take this week.
How This Overlaps With NIS2 and GDPR
A single incident can trigger Cyber Resilience Act reporting alongside separate obligations under NIS2 and GDPR, each running its own clock with its own recipient authority. NIS2 requires essential and important entities to send a 24-hour early warning and 72-hour notification to their national CSIRT for significant incidents affecting network and information systems a parallel duty, but organizationally scoped rather than product-specific like the CRA’s. Where personal data is involved, GDPR’s Article 33 requires notification to the relevant Data Protection Authority within 72 hours, independent of both of the above.
The EU’s proposed Digital Omnibus package would eventually let a single incident report satisfy multiple regimes through a shared entry point. But that consolidation isn’t expected before 2027 at the earliest, so it’s not something to plan around yet.
Until then, the smarter move is building one internal incident-response pipeline that captures the facts all three notifications need, rather than treating Cyber Resilience Act reporting, NIS2, and GDPR as three separate fire drills every time something goes wrong.
Penalties for Non-Compliance
Get Cyber Resilience Act reporting wrong, and the exposure isn’t abstract. Non-compliance with Article 14 along with the essential cybersecurity requirements in Annex I, and Article 13 carries administrative fines of up to €15 million or 2.5% of the company’s total worldwide annual turnover for the preceding financial year, whichever is higher. That’s the CRA’s top penalty tier.
Other CRA obligations carry lower ceilings of €10 million/2% and €5 million/1%, but for reporting failures specifically, you’re looking at the harshest bracket. Microenterprises and small enterprises are exempted from fines tied specifically to missing certain Article 14 deadlines, though the underlying reporting duty itself still applies to them.
Authorities weigh the nature, gravity, and duration of the infringement, and whether the manufacturer took action to mitigate harm. Prompt, good-faith Cyber Resilience Act reporting is treated very differently from staying quiet though it’s worth remembering that reporting late is still, on paper, a top-tier breach in its own right.
CyberInfos Analyst Insight
The following is CyberInfos’s analysis, not a new factual claim.
The most underappreciated risk in Cyber Resilience Act reporting isn’t the fine it’s the platform-timing gap. Regulations that launch their reporting duty and their reporting tool on the same calendar day tend to produce early confusion. Organizations that treat “the platform isn’t ready yet” as a reason to delay internal readiness will be the ones scrambling once a real incident hits.
Teams that build the detection-to-filing runbook now, regardless of how polished the SRP’s interface looks on day one, will be in far better shape once the first enforcement actions eventually test how regulators actually interpret “becoming aware.”
Actionable Checklist
- Confirm which of your products qualify as a “product with digital elements” under the CRA
- Maintain a current SBOM for every in-scope product
- Write a documented internal definition of “becoming aware” for your incident-response process
- Identify your coordinating CSIRT based on your organization’s main establishment
- Register on ENISA’s Single Reporting Platform before an incident occurs
- Prepare a pre-filled early-warning report template
- Assign clear ownership across security, engineering, legal, and compliance for the 24-hour window
- Map how Cyber Resilience Act reporting interacts with your existing NIS2 and GDPR incident processes
- Run an internal dry-run/tabletop exercise on the 24/72-hour timeline
FAQ
What is Cyber Resilience Act reporting?
Cyber Resilience Act reporting is the legal requirement under Article 14 of Regulation (EU) 2024/2847 for manufacturers of products with digital elements to notify EU authorities of actively exploited vulnerabilities and severe security incidents, starting September 11, 2026.
Does Cyber Resilience Act reporting apply to products already sold before September 2026?
Yes ,and this is the detail that surprises people. The reporting obligation covers products with digital elements already placed on the EU market, not just new products released after the CRA’s general application date in December 2027.
What is the difference between the 24-hour and 72-hour deadlines?
The 24-hour deadline is for an early warning as soon as you become aware of a qualifying vulnerability or incident. The 72-hour deadline is for a fuller notification that includes an initial assessment and any mitigation steps you’ve taken.
Who do I report to under the Cyber Resilience Act?
Reports go through the Single Reporting Platform, which routes them to the CSIRT designated as coordinator for your organization’s main establishment, and simultaneously to ENISA.
Does Cyber Resilience Act reporting apply to companies outside the EU?
Yes. Coverage is based on where the product is sold, not where the company is headquartered any manufacturer placing a qualifying product on the EU market is in scope, regardless of where they’re based, including CRA compliance obligations for Indian and other non-EU vendors.
What counts as an “actively exploited” vulnerability?
It’s a vulnerability with reliable evidence that a malicious actor has exploited it in a system without the system owner’s permission. A plain CVE, a proof-of-concept, or a good-faith research finding doesn’t automatically qualify on its own.
Is the ENISA Single Reporting Platform live yet?
ENISA has said the platform is scheduled to go live September 11, 2026, the same day Cyber Resilience Act reporting becomes mandatory, though it had no published public URL as recently as September 1. Confirm current status on ENISA’s official SRP page rather than assuming either way.
What happens if I miss the 24-hour reporting deadline?
Missing the deadline is itself treated as non-compliance with Article 14, exposing the organization to fines of up to €15 million or 2.5% of global turnover though microenterprises and small enterprises are exempted from fines tied specifically to certain Article 14 deadlines.
Final Thoughts
Cyber Resilience Act reporting is no longer a future compliance milestone. As of today, it’s an active legal obligation for any manufacturer with a connected product on the EU market. The immediate priority isn’t finishing full CRA product compliance that still has until December 2027.
It’s making sure your organization can detect, classify, and file within 24 hours of becoming aware of a qualifying vulnerability or incident. Confirm your coordinating CSIRT, register on the Single Reporting Platform, and rehearse the workflow now, before an actual incident makes it your first live attempt at any of this.
The organizations that treat Cyber Resilience Act reporting as a rehearsed process, not a scramble, are the ones that’ll come out of the next twelve months looking prepared rather than exposed.
