The European Union’s Cyber Resilience Act reaches its first major operational deadline on September 11, 2026, when vulnerability-reporting duties begin for manufacturers of connected products and commercial software placed on the EU market. The full product-security rulebook does not apply until December 2027, but the reporting clock starts now.
For product security teams, the immediate change is simple and uncomfortable: an actively exploited vulnerability can become a regulated notification event within 24 hours of the company becoming aware of it. That makes the CRA less of a distant compliance project and more of a live incident-response requirement for software vendors, device makers, IoT companies, cloud-connected hardware suppliers, and businesses that ship digital components into Europe.
The European Commission describes the Cyber Resilience Act as a horizontal cybersecurity law for products with digital elements, covering hardware and software that can connect directly or indirectly to another device or network. The regulation was published in the EU’s Official Journal in 2024 and entered into force that December, with most substantive obligations applying from December 11, 2027. The vulnerability and incident reporting provisions begin earlier, on September 11, 2026.
What starts on September 11
Article 14 of the regulation requires manufacturers to notify authorities of actively exploited vulnerabilities contained in a product with digital elements. The first notice, an early warning, is due within 24 hours after the manufacturer becomes aware of the exploitation. A fuller vulnerability notification follows within 72 hours, and a final report is required after the corrective or mitigating measure is available.
The same article also covers severe incidents that affect the security of a product with digital elements. Those reports follow a similar early-warning and notification sequence, with final reporting tied to the incident’s resolution. In practice, the reporting obligation is likely to sit close to the product security incident response team, because it depends on fast triage: is the flaw present in a covered product, is exploitation active, what markets are affected, what mitigation exists, and which users need to be warned?
ENISA, the European Union Agency for Cybersecurity, is building the single reporting platform that will route reports to national computer security incident response teams and to ENISA. The Commission’s reporting guidance frames the platform as the main path for CRA vulnerability and incident notifications, rather than a patchwork of separate national forms.
Who should pay attention
The CRA is aimed at manufacturers, importers, and distributors of products with digital elements, but the September deadline will land first on the teams that know the code, firmware, build pipeline, updater, cloud dependency, and customer exposure. A smart thermostat, router, industrial controller, business application, desktop utility, mobile-connected accessory, or commercial open-source-based product can all raise CRA questions if it is placed on the EU market and falls within the law’s scope.
The regulation contains exclusions and special handling for areas already covered by sector-specific rules, including some medical, aviation, and vehicle systems. Non-commercial open-source software is treated differently from commercial products, but companies that package, sell, support, or integrate open-source components into covered products cannot treat upstream maintainers as a shield. If a product reaches European customers under a commercial manufacturer’s responsibility, the company needs its own reporting and patch process.
That is why this deadline matters beyond legal departments. A company cannot make a credible CRA report if it does not know which products contain the vulnerable component, whether the flaw is remotely reachable, what versions are affected, how updates are delivered, whether customers can apply a mitigation, and whether exploitation has been observed in the wild.
The hard part is evidence, not the form
The 24-hour early-warning deadline does not require a complete root-cause analysis. It does require enough internal discipline to recognize a reportable event quickly. That means security teams need a working definition of “aware,” an escalation path from support tickets and bug bounty reports into incident response, and a way to distinguish proof-of-concept chatter from confirmed active exploitation.
Product teams should also expect the 72-hour follow-up to require cleaner facts: affected products and versions, the nature of the vulnerability, exploitation status, likely impact, mitigations, and the expected patch or update path. If the same component is embedded across several product lines, the company may need product inventory, SBOM data, release ownership, and customer segmentation before it can answer basic questions.
The customer-notification side is just as important. The regulation requires manufacturers to inform affected users without undue delay when an actively exploited vulnerability is present, along with corrective measures or mitigations where available. A silent server-side fix may not be enough when customers need to update firmware, rotate credentials, disable a vulnerable feature, isolate a device, or review logs.
What product teams should do now
Companies that sell covered products into the EU should use the September 11 deadline to test their vulnerability workflow against a real clock. The useful exercise is not to write a policy and file it away. It is to pick a recent exploited vulnerability, pretend it affects a shipping product, and walk the report from intake through triage, executive approval, customer communication, patch release, and final documentation.
That dry run should answer practical questions. Who can decide that a vulnerability is actively exploited? Who owns the ENISA platform account? Who approves the first 24-hour notice if the technical picture is still incomplete? Which product manager can confirm affected versions? Who writes customer-facing mitigations? Which support team will handle follow-up questions in Europe? Where is the evidence stored after the final report?
Engineering leaders should also check whether patch delivery can keep up with the reporting promise. A company may be able to file an early warning quickly but still struggle to ship firmware updates, update app-store builds, coordinate managed-service changes, or support older product lines. The CRA does not turn every bug into a crisis, but it does make exploited product vulnerabilities harder to manage as quiet internal events.
A security deadline with business consequences
The wider CRA compliance deadline in December 2027 will bring more product-design and conformity-assessment obligations. The September 2026 reporting start is narrower, but it is likely to expose which companies already have mature product security operations and which ones are still relying on informal patch coordination.
For buyers, the law should make vulnerability handling more visible over time. Vendors will need better records of affected versions, clearer update commitments, and faster communication when exploitation is confirmed. For manufacturers, the risk is not only regulatory scrutiny. A slow or vague response to an exploited product flaw can become a customer-trust problem, especially for devices and software that sit inside enterprise networks, homes, factories, and public infrastructure.
The deadline also gives U.S. and other non-EU companies a reason to stop treating European cybersecurity regulation as someone else’s paperwork. If a product is sold into the EU, the reporting obligation can reach the manufacturer even when the engineering team, cloud service, or security operations center sits elsewhere.
The next year will show how aggressively national authorities and ENISA operationalize the reporting pipeline. The safer assumption for product teams is that the first exploited vulnerability after September 11 will not arrive on a convenient schedule. The process needs to be ready before the alert does.
Sources: European Commission Cyber Resilience Act overview; European Commission CRA reporting guidance; ENISA Single Reporting Platform information; Regulation (EU) 2024/2847 text.
