Cyber Resilience Act Reporting Obligations From 11 September 2026, What Manufacturers of Products with Digital Elements Must Report, to Whom, and Within What Deadlines

By Global Law Experts

– posted 2 hours ago

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.

Executive summary: CRA reporting obligations from 11 September 2026 (what you must know now)

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.

Who is in scope. Manufacturers of products with digital elements (PDEs) carry the primary reporting duty. Importers and distributors have related obligations in defined circumstances.
What to report. Two categories: actively exploited vulnerabilities and severe incidents having an impact on the security of the product.
Where to report. The single reporting platform coordinated by ENISA is the central channel, with national CSIRTs and competent authorities involved depending on the incident and its cross-border reach.
Key deadlines. An early warning within 24 hours, a more structured notification within 72 hours, and a final report once the vulnerability has been remediated or the incident resolved.

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.

Who is in scope: products with digital elements (PDEs), manufacturers, importers and distributors

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.

Definition of PDEs (with examples)

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:

Consumer IoT. Smart home devices, connected cameras, wearables, routers and smart appliances.
Industrial and operational technology. Programmable logic controllers, industrial control systems and connected sensors used in manufacturing environments.
Software products. Operating systems, applications, firmware and libraries, whether embedded or supplied separately.
Connected components. Microcontrollers, chipsets and modules integrated into larger products.

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.

Who counts as a manufacturer under the CRA

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, when do they have obligations?

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.

What must be reported: exploited vulnerabilities vs severe incidents

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.

Actively exploited vulnerabilities, definition and examples

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:

A remotely exploitable flaw in a device’s firmware for which working exploit code is circulating and being deployed against customers.
An authentication bypass in a connected product observed being used to gain unauthorised access.
A memory-corruption vulnerability confirmed as the entry point in an ongoing attack campaign.

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.

Severe incidents, definition, impact thresholds and examples

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:

A successful compromise of a widely deployed product resulting in unauthorised access to customer data.
A ransomware or supply-chain attack affecting the integrity of firmware distributed to end users.
An outage or manipulation of a connected industrial system with safety or operational consequences.

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.

Borderline cases and examples

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.

Reporting channels: the ENISA single reporting platform (how to report)

Knowing what to report is only half the picture. Manufacturers must also know precisely where reports go and how the mechanics work.

Overview of the platform and who receives the report

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.

Step-by-step reporting flow

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:

Registering or authenticating on the single reporting platform.
Identifying the affected product with digital elements, including version and build information.
Selecting the report type, early warning, notification or final report.
Describing the vulnerability or incident, including indicators, suspected root cause and preliminary impact.
Attaching supporting evidence and metadata, such as timestamps and affected-population estimates.
Submitting and retaining the confirmation for internal records.

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.

Practical tips: evidence preservation, redaction and cross-border reporting

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.

Timelines and deadlines: 24-hour early warning, 72-hour notification, and final report

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 24-hour early warning, what to include and who triggers it

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 72-hour notification, required content and escalation

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 final report, timing and recommended contents

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

Roles and responsibilities: internal processes and supply-chain coordination

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.

Manufacturer internal incident response, roles, RACI and SLA examples

Manufacturers should establish a clear incident-response structure with defined roles and decision rights. A practical RACI approach might designate:

Incident lead (Responsible). Owns triage, coordinates the response and drives the reporting timeline.
Legal/compliance (Accountable for reporting decisions). Confirms whether a report is required and approves content before submission.
Engineering/security (Consulted). Provides technical analysis, impact assessment and remediation.
Executive sponsor and communications (Informed). Manage escalation, customer messaging and disclosure strategy.

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.

Contractual flow-down: suppliers, importers and distributors

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.

Interaction with national competent authorities and CSIRTs

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.

Practical checklist and evidence: what to collect before, during and after reporting

Good reporting rests on good evidence. Collecting the right information early makes each stage of the reporting process faster and more defensible.

Minimum data fields to collect

Manufacturers should capture both technical and non-technical data, including:

Affected product name, model, firmware and software versions, and build identifiers.
Vulnerability identifier or internal reference, and any exploit indicators.
Timeline of detection, awareness and key events, with timestamps.
Impact assessment: affected users, data categories, operational effects.
Mitigation and remediation measures taken and planned.
Communications with customers, suppliers and authorities.

Evidence preservation and chain-of-custody best practice

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.

Post-reporting follow-up and communication strategy

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.

Enforcement, penalties and common pitfalls

The Regulation is backed by enforcement, and the reporting duties are not optional best practice.

Potential enforcement approaches and penalties

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.

Common compliance mistakes and mitigation

Slow internal escalation. Alerts languishing in support queues instead of reaching the incident lead. Mitigate with defined internal SLAs and testing.
Scope misjudgement. Assuming a product is out of scope. Mitigate by mapping the portfolio against the PDE definition.
Under-reporting borderline events. Waiting for certainty before filing. Mitigate by using the early-warning mechanism and documenting the analysis.
Weak supply-chain contracts. No obligation on suppliers to notify. Mitigate through contractual flow-down.
Evidence destroyed by remediation. Mitigate by capturing forensic evidence before fixing.

Next steps: immediate actions for manufacturers and legal checklist

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.

First 30 days. Map your product portfolio against the PDE scope; identify who is the responsible manufacturer for each product; confirm access to the single reporting platform; assign incident-response roles.
Days 31–60. Draft or update the incident-response playbook with 24-hour, 72-hour and final-report workflows; set internal escalation SLAs; prepare report templates and evidence checklists; train the incident team.
Days 61–90. Amend supply-chain and distribution contracts to include notification and cooperation duties; run a tabletop exercise simulating an exploited vulnerability; test the end-to-end reporting process against the deadlines; document everything for audit.

Conclusion

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.

Sources

FAQs

What must manufacturers report under the CRA from 11 September 2026?

Manufacturers must report actively exploited vulnerabilities and severe incidents affecting products with digital elements to the coordinating national CSIRT and ENISA via the single reporting platform within the prescribed timeframes, an early warning within 24 hours and a notification within 72 hours, followed by a final report with detailed findings within the period set by the Regulation once the event is resolved.

Who qualifies as a manufacturer under the CRA?

The CRA defines “manufacturer” broadly to include any natural or legal person who develops or manufactures a product with digital elements, or has it designed or manufactured, and markets it under their own name or trademark. Importers and distributors may also have obligations, and an importer or distributor marketing a product under its own name may itself be treated as a manufacturer.

Where do manufacturers submit reports under the cyber resilience act reporting obligations?

Reports are submitted through the single reporting platform operated by ENISA, generally to the coordinating national CSIRT and ENISA. National competent authorities and other CSIRTs may also be involved depending on the incident and any cross-border effects.

What is the difference between the 24-hour and 72-hour reports?

The early warning, due within 24 hours of awareness, alerts authorities to the event with only essential preliminary information. The notification, due within 72 hours, requires more structured detail, including an updated assessment of severity and impact and, where available, initial mitigation measures. A detailed final report follows within the period set by the Regulation once the event has been investigated and resolved.

What evidence should be preserved when preparing a CRA report?

Preserve logs, exploitation indicators, timestamps, patch and firmware details, affected product versions, forensic images and communication records. Maintain a documented chain of custody and record the forensic steps taken, so the evidence supporting each report is defensible.