Cyber Resilience Act reporting obligations from 11 September 2026 now apply directly to manufacturers of products with digital elements placed on the EU market, marking one of the most consequential compliance milestones in the European Union’s cybersecurity framework. From that date, businesses must report actively exploited vulnerabilities and severe incidents to the European Union Agency for Cybersecurity (ENISA) through a dedicated single reporting platform, within tightly compressed deadlines. This guide explains precisely who is in scope, what must be reported, to whom, and within what timeframes, and sets out the internal processes manufacturers, importers and distributors should have in place to meet these duties.
It is written for compliance officers, in-house counsel and product teams who need an actionable, EU-wide reference rather than a high-level summary.
Who this is for: manufacturers, importers, distributors, in-house counsel and compliance officers handling products with digital elements (PDEs).
What you will learn: scope, to whom to report (the ENISA single reporting platform), the reporting deadlines (24-hour early warning, 72-hour notification, and a later final report), what data to include, and immediate steps to implement internally.
Read time: approximately 14 minutes.
Attributed expertise: This article is contributed through the Global Law Experts network as practical guidance on EU technology regulation and incident reporting obligations. Legal interpretation offered here is framed as general guidance and does not constitute legal advice; all mandatory obligations should be verified against primary EU and ENISA sources and, where necessary, specific legal advice.
The core message is simple: the Cyber Resilience Act reporting obligations from 11 September 2026 create a mandatory, time-critical duty to notify certain security events. If you place products with digital elements on the EU market, you cannot rely on informal or voluntary disclosure alone.
For most organisations, the practical challenge is not understanding the headline rules but operationalising them: building detection, triage, escalation and reporting workflows that can move within 24 hours. That is where the bulk of compliance effort, and legal risk, now sits.
Scope is the first question every business must answer, because it determines whether the reporting duties apply at all. The Regulation is deliberately broad, capturing far more than traditional software vendors.
Products with digital elements are, in essence, any software or hardware products, and their remote data-processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. The definition is intentionally wide so that connected and connectable products across sectors fall within the regime. Practical examples include:
Certain categories are excluded or addressed under separate sectoral legislation, and manufacturers should confirm how the Cyber Resilience Act interacts with those regimes for their specific product line. The definitive scope is set out in the CRA legal text available via EUR-Lex, and businesses should map their portfolio against those definitions rather than assume a product is excluded.
The Regulation defines “manufacturer” broadly. It captures any natural or legal person who develops or manufactures a product with digital elements, or who has such a product designed or manufactured, and markets it under their own name or trademark. This means that a business rebranding a third-party product as its own can bear manufacturer obligations, including the reporting duties. Because the definition follows the well-established EU product-safety approach, organisations that place products on the market under their own brand should assume they are the responsible manufacturer for CRA purposes unless a clear analysis shows otherwise.
Importers and distributors are not exempt. While the manufacturer holds the principal reporting duty, importers must ensure the products they bring into the EU market meet the Regulation’s requirements and must not place non-compliant products on the market. Where an importer or distributor becomes aware of a vulnerability or incident, they have obligations to act, including informing the manufacturer and, in certain situations, cooperating with authorities. An importer or distributor that markets a product under its own name or trademark may itself be treated as a manufacturer, inheriting the full set of Cyber Resilience Act reporting obligations from that point. Distributors, positioned further down the supply chain, must exercise due care and cannot ignore known risks.
The precise allocation of duties between these actors is one of the most important governance questions for cross-border supply chains, and it should be resolved contractually before an incident occurs, not during one.
The reporting regime distinguishes between two triggers. Understanding the difference is essential, because they can arise separately, together, or in sequence, and each demands a rapid decision under time pressure.
An actively exploited vulnerability is a weakness in a product with digital elements that is being used by a threat actor, rather than merely a theoretical or newly discovered flaw. The key concept is exploitation “in the wild”, evidence that attackers are, or have been, taking advantage of the vulnerability. Examples include:
The important compliance signal is not the severity score alone but the presence of active exploitation. A vulnerability that is severe but not being exploited may not trigger the reporting clock in the same way, though it will trigger the manufacturer’s broader duty to handle and remediate vulnerabilities across the product lifecycle.
A severe incident is a security event that has a negative impact on the security of the product with digital elements, or on the availability, authenticity, integrity or confidentiality of the data it processes. In assessing severity, manufacturers should consider the scale of affected users, the sensitivity of impacted data, operational disruption and the potential for physical or financial harm. Examples of severe incidents include:
The Cyber Resilience Act reporting obligations from September 2026 require manufacturers to assess these impact factors quickly and to document the reasoning behind their severity determination, since that assessment underpins whether and when reporting is triggered. Manufacturers should follow any implementing guidance issued by the Commission and ENISA on how severity is to be assessed.
In practice, many situations sit near the threshold. A vulnerability with credible but unconfirmed reports of exploitation, an incident whose full impact is not yet understood, or a suspected compromise still under investigation all present judgement calls. The prudent approach in borderline cases is to treat the reporting clock as running from the point of reasonable awareness, document the analysis contemporaneously, and use the early-warning mechanism to flag an evolving situation rather than waiting for certainty. Under-reporting carries greater regulatory risk than a good-faith early warning that is later refined or updated.
Knowing what to report is only half the picture. Manufacturers must also know precisely where reports go and how the mechanics work.
ENISA, the European Union Agency for Cybersecurity, establishes and operates the single reporting platform that acts as the central electronic entry point for CRA notifications. Under the Regulation, a manufacturer generally notifies the CSIRT designated as coordinator in the relevant Member State as well as ENISA, and submission through the platform is designed to route the information to the relevant recipients within the EU cybersecurity architecture, including national computer security incident response teams (CSIRTs) and competent authorities where appropriate. The single-platform model is designed to reduce duplication and provide a more consistent reporting experience across Member States, so that a manufacturer facing a cross-border incident is not left navigating multiple national systems from scratch.
The exact interface and required fields should be confirmed against current ENISA platform guidance. A manufacturer preparing to report should expect to provide structured information at each stage. A typical flow involves:
Because the platform underpins the Cyber Resilience Act reporting obligations from the moment they apply, manufacturers should familiarise their incident teams with it before any live event, ideally through a dry run using a mock scenario, and should maintain a fallback process in case of technical unavailability.
Three practical points matter. First, preserve evidence as it exists at the time of detection, logs, indicators of compromise and affected images, before remediation overwrites it. Second, apply sensible redaction: report the security-relevant facts without unnecessarily exposing customer personal data beyond what is required, coordinating with data-protection colleagues, and remain alert to any parallel breach-notification duties under the GDPR. Third, plan for cross-border effects: where an incident spans multiple Member States, the single platform helps, but manufacturers should still understand which national CSIRTs and competent authorities may become involved.
The timeline is the sharpest edge of the regime. The Cyber Resilience Act reporting obligations from September 2026 operate on a staged model, and each stage has a distinct purpose and content requirement.
The early warning is the first and fastest step, generally due without undue delay and within 24 hours of the manufacturer becoming aware of an actively exploited vulnerability or a severe incident. At this stage, complete information is not expected. The early warning should convey the essentials: that an event has occurred or is occurring, the product involved, a preliminary indication of the nature and suspected impact, and, where applicable, the Member States in which the product has been made available. The trigger is the manufacturer’s awareness, which makes fast internal escalation, from support and engineering teams to the incident lead, the single most important operational capability to build.
The notification stage, generally due without undue delay and within 72 hours of awareness, requires more structured and substantive information than the early warning. By this point the manufacturer should provide a clearer description of the vulnerability or incident, an updated assessment including its severity and impact, and, where available, information on affected products and any corrective or mitigating measures being taken. This stage typically involves internal escalation to legal counsel and senior management, since decisions about customer communication, remediation and public disclosure begin to crystallise here. The notification is not the end of the process; it is a checkpoint that reflects the manufacturer’s understanding at the 72-hour mark.
The manufacturer must submit a final report to the coordinating CSIRT and ENISA within the period set by the Regulation. For an actively exploited vulnerability, the final report is generally due no later than 14 days after a corrective or mitigating measure is available; for a severe incident, it is generally due within one month of the notification. Manufacturers should confirm the exact timing and content against the current CRA text and ENISA guidance. The final report should contain a full account of the event: root cause analysis, the full scope of impact, the mitigation and remediation measures applied, and details of user notifications and any coordinated disclosure.
Treat the final report as the definitive record that authorities, and potentially litigants, will scrutinise, so accuracy and completeness matter more than speed at this stage.
| Trigger | When to report | Minimum required content | Who receives it | Recommended immediate step |
|---|---|---|---|---|
| Actively exploited vulnerability | Early warning within 24 hours of awareness; notification within 72 hours; final report generally within 14 days of a fix being available | Vulnerability identifier, affected product(s), exploit indicators, preliminary impact | Coordinating national CSIRT and ENISA via the single reporting platform | Isolate affected builds; capture indicators of compromise; notify internal incident team |
| Severe incident having an impact on product security | Early warning within 24 hours of awareness; notification within 72 hours; final report generally within one month of the notification | Incident description, impact assessment, affected products, mitigation steps | Coordinating national CSIRT and ENISA; competent authorities where applicable | Engage legal counsel; preserve logs; hold public statements pending assessment |
| Final report (after mitigation/investigation) | Within the period set by the Regulation, once resolved | Full root cause analysis, mitigation, remediation plan, user notifications | Coordinating CSIRT and ENISA; affected parties as required | Release remediation patches and coordinate disclosure |
Meeting the deadlines depends on people and process as much as on legal knowledge. A well-drafted policy that no one can execute at 2am is worthless.
Manufacturers should establish a clear incident-response structure with defined roles and decision rights. A practical RACI approach might designate:
Internal service-level agreements should reflect the external deadlines. If the early warning must be filed within 24 hours of awareness, internal escalation from first detection to the incident lead should be measured in hours, not days. Manufacturers should define a maximum internal escalation time and test it. This is where the Cyber Resilience Act reporting obligations most often fail in practice, not through ignorance of the rules, but through slow internal routing of the first alert.
Many products with digital elements incorporate third-party components. If a vulnerability originates upstream, the manufacturer still bears the reporting duty for its own product. Contracts across the supply chain should therefore include obligations to notify vulnerabilities and incidents promptly, cooperate in investigations, and support remediation. Similarly, agreements with importers and distributors should allocate responsibilities clearly, including notification obligations back to the manufacturer. Effective contractual flow-down turns a fragmented supply chain into a coordinated reporting network and reduces the risk of a manufacturer learning about an exploited vulnerability too late to meet its deadlines.
Although the single reporting platform is the central channel, national competent authorities and CSIRTs remain part of the ecosystem, particularly for incidents with significant national or cross-border effects. Manufacturers should understand which authorities are relevant to their principal markets and maintain awareness of any national coordination guidance. Where an incident also engages other regimes, such as the NIS2 Directive or the GDPR, coordinated engagement with the relevant authorities helps avoid inconsistent messaging.
Good reporting rests on good evidence. Collecting the right information early makes each stage of the reporting process faster and more defensible.
Manufacturers should capture both technical and non-technical data, including:
Preserve logs, forensic images, affected firmware versions and indicators of compromise in a manner that maintains their integrity. Document who collected what, when and how, so that the evidence supporting a report, and any subsequent regulatory or legal scrutiny, is defensible. Avoid remediating in a way that destroys the only record of the incident before it has been captured.
Reporting is not the end. Manufacturers must manage the aftermath: releasing patches, coordinating vulnerability disclosure, updating affected customers and, where appropriate, aligning with authorities on public messaging. A pre-agreed communication strategy prevents inconsistent or premature statements that could increase legal exposure or undermine trust.
Prepare in advance: A CRA reporting checklist and a report field template that consolidate the data points above into a working document can help your incident team act quickly during a live event.
The Regulation is backed by enforcement, and the reporting duties are not optional best practice.
The Cyber Resilience Act provides for supervision by national market surveillance authorities and for penalties in the event of non-compliance, with the framework and maximum thresholds set out in the legal text available via EUR-Lex. Manufacturers should treat the reporting obligations as legally binding requirements, not aspirational targets, and should be prepared to demonstrate their compliance processes to authorities. Documented decision-making and a functioning reporting workflow are the best evidence of good faith if a manufacturer’s handling of an event is later reviewed.
With the Cyber Resilience Act reporting obligations applying from 11 September 2026, manufacturers should treat readiness as an active project rather than a future task. A structured 30/60/90-day plan helps.
The Cyber Resilience Act reporting obligations from 11 September 2026 have shifted incident and vulnerability reporting from good practice to binding legal duty for every manufacturer of products with digital elements on the EU market. The rules are demanding not because they are complex to state, report actively exploited vulnerabilities and severe incidents to the coordinating CSIRT and ENISA via the single reporting platform through an early warning within 24 hours, a notification within 72 hours and a final report within the period set by the Regulation, but because they demand speed, coordination and evidence under pressure.
Manufacturers who invest now in scope mapping, incident-response playbooks, internal escalation SLAs and supply-chain contract terms will be able to meet these deadlines with confidence, while those who wait for a first incident to test their readiness risk both regulatory exposure and reputational harm. Treat compliance with the Cyber Resilience Act reporting obligations as an operational capability to be built and rehearsed, not a document to be filed.
posted 29 minutes ago
posted 51 minutes ago
posted 1 hour ago
posted 1 hour ago
posted 1 hour ago
posted 1 hour ago
posted 1 hour ago
posted 1 hour ago
Find the right Legal Expert for your business
Send welcome message
