The European Union’s Cyber Resilience Act has reached a deadline that technology manufacturers cannot leave to their 2027 compliance plans. Under the regulation’s published timetable, mandatory reporting of actively exploited vulnerabilities and severe security incidents began applying on 11 September 2026, more than a year before most of its product security requirements take effect.
The distinction matters for businesses selling connected hardware and software in the EU. A company may still be preparing for the act’s broader requirements, but its process for escalating a qualifying vulnerability or incident already needs to account for the reporting rules.
This is not a requirement to disclose every software bug to regulators. It targets particular events: vulnerabilities being actively exploited and incidents that have a severe impact on the security of covered products. For manufacturers, the practical challenge is identifying those events quickly enough to meet deadlines measured in hours.
The reporting clock starts before the main compliance deadline
The Cyber Resilience Act, formally Regulation (EU) 2024/2847, establishes cybersecurity requirements for products with digital elements placed on the EU market. Its scope extends across many categories of hardware and software, including products that connect directly or indirectly to a device or network.
Most of the act’s requirements apply from 11 December 2027. These include a wider set of obligations concerning secure product design, vulnerability handling, conformity assessment and information supplied to users. Article 14’s reporting obligations have an earlier application date.
That creates two distinct workstreams. Manufacturers need to prepare products and development practices for the broader regime while also maintaining a functioning vulnerability reporting process now. Treating December 2027 as the only relevant date risks overlooking the earlier legal obligation.
The reporting provisions can also apply to covered products placed on the market before the broader requirements begin. Businesses should therefore not assume that only a future product generation belongs in their incident escalation procedures.
What manufacturers must report—and how quickly
For an actively exploited vulnerability, the regulation sets out a staged reporting process. The manufacturer must notify the relevant Computer Security Incident Response Team, or CSIRT, designated as coordinator, and the EU Agency for Cybersecurity, ENISA, through the act’s single reporting platform.
- Within 24 hours of becoming aware: Submit an early warning without undue delay, including available information about the affected territories.
- Within 72 hours of becoming aware: Provide a vulnerability notification, unless the relevant information has already been supplied. This includes available details about the product, the vulnerability, exploitation and corrective or mitigating measures.
- Within 14 days after a corrective or mitigating measure becomes available: Submit a final report with further information, including details of the vulnerability and the security update or other corrective measures.
The distinction between becoming aware of exploitation and completing an investigation is consequential. The staged process anticipates that a manufacturer will have incomplete information at first. It does not allow the initial warning to wait until engineers have reproduced every aspect of an attack or finished a patch.
Severe security incidents follow a related but separate sequence: an early warning within 24 hours, an incident notification within 72 hours and a final report generally within one month of the incident notification. Where the incident remains ongoing, the regulation provides for a progress report and a subsequent final report after handling is complete.
These are different reporting tracks, not interchangeable deadlines. A vulnerability report’s final deadline is tied to the availability of a corrective or mitigating measure; the incident track uses a different timetable.
A vulnerability score is not the reporting trigger
One of the most important distinctions is between a serious vulnerability and an actively exploited one. A high severity score, a researcher’s disclosure or the publication of proof-of-concept code does not, by itself, establish that malicious actors have exploited the flaw.
The act defines an actively exploited vulnerability by reference to reliable evidence that a malicious actor has exploited it in a system without the system owner’s permission. Manufacturers therefore need a way to assess evidence, not simply a rule that forwards every critical scanner result to a regulator.
Consider a vendor receiving a report about an authentication bypass in a connected appliance. The initial report might establish that the flaw exists. Later evidence from a customer’s compromised device could establish active exploitation. Those developments require different assessments, even though they concern the same underlying defect.
For incident reporting, the legal test concerns severe impact on product security. The regulation addresses circumstances such as an incident affecting the product’s ability to protect the availability, authenticity, integrity or confidentiality of important data or functions. Companies need to evaluate that test rather than assume every internal IT disruption is a reportable product incident.
The operational pressure falls between teams
The first 24 hours are often spent determining which product versions are affected, whether a report is credible and who owns the response. The new reporting requirements make those handoffs a compliance issue as well as an engineering problem.
A product security incident response team needs access to customer reports, vulnerability researchers’ findings and relevant threat intelligence. Legal and compliance staff need enough technical context to assess the reporting obligation. Whoever submits the notification needs the authority to act before a full executive briefing or completed root-cause analysis is available.
Third-party software dependencies add another complication. If an exploited library is included in a commercial product, the manufacturer needs to establish whether its implementation is affected. Waiting for an upstream maintainer to describe every downstream consequence may leave too little time for that assessment.
A software bill of materials can help identify affected components, but it is not a substitute for investigating how those components are used. The useful operational question is not merely whether a library appears in an inventory; it is whether the vulnerable functionality is present, reachable and relevant to the manufacturer’s product.
Regulatory reporting also sits alongside communication with users. The act requires manufacturers to inform affected users about relevant vulnerabilities or incidents and, where necessary, the corrective or mitigating measures they can take. A regulator notification is not a replacement for a usable customer security advisory.
Broad coverage, with boundaries that still matter
The regulation is relevant to manufacturers outside Europe when they place covered products on the EU market. Its reach is based on the products and market activity involved, not simply the location of a company’s headquarters.
However, it should not be read as covering every digital service or every open-source contribution. The act contains exclusions and specific scope rules. Free and open-source software supplied outside a commercial activity is treated differently from covered commercial products, while certain product categories are addressed through sector-specific legislation.
Cloud functionality also requires a more careful analysis than a blanket statement that all software-as-a-service products are included. The act addresses certain remote data processing solutions associated with a product, with coverage depending on the statutory conditions.
For technology suppliers, the immediate priority is consequently narrower—and more urgent—than completing an entire product compliance programme: establish which products are covered, who evaluates evidence of exploitation, and how a qualifying report reaches the authorities within the required window. The broader December 2027 deadline does not postpone that work.
Source basis: This report covers the reporting milestone established by the published regulation, rather than a newly announced enforcement action. The legal text, including Articles 14 and 71 and the transitional provisions, is available in Regulation (EU) 2024/2847. The European Commission also provides an overview of the Cyber Resilience Act and its implementation timetable.
