The bug report is becoming a product deadline

The next EU technology deadline is less about a new button on a phone and more about a clock starting inside companies that sell connected products.

From 11 September 2026, manufacturers covered by the Cyber Resilience Act will have to report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The European Commission says an early warning is due within 24 hours of becoming aware, followed by a fuller notification within 72 hours. Final reporting comes later, with different deadlines for exploited vulnerabilities and severe incidents.

That sounds like compliance language. In practice, it pulls product security out of the specialist inbox and into the release calendar.

The rule matters because the products in scope are ordinary now. The Commission's own examples include baby monitors, smart watches, apps and computer programs. Its manufacturer guidance also points beyond finished gadgets to components such as chips and operating systems. A security flaw in a consumer device, a business application or a connected component can quickly become a support issue, a customer trust issue and a regulatory issue at the same time.

The September date is not the full Cyber Resilience Act deadline. The CRA entered into force in December 2024, and the main obligations apply from 11 December 2027. Reporting starts earlier. That gap is the useful part for readers: companies do not have to wait for the whole rulebook to bite before they need a working process for exploited bugs and serious security incidents.

The new process is supposed to run through a Single Reporting Platform, built and operated by ENISA, the EU cybersecurity agency. The Commission says manufacturers report once through that platform. The notification goes to the relevant national Computer Security Incident Response Team, usually tied to the manufacturer's main establishment, and is made available to ENISA except in defined exceptional circumstances. ENISA says the platform is meant to be the single entry point rather than a maze of separate national notifications.

For product teams, the unglamorous question is what counts as being ready. A company needs to know who owns vulnerability intake, who decides when evidence shows active exploitation, who contacts legal and security leadership, and who can submit a report when the clock is already running. None of that is fixed by adding a line to a privacy policy.

The hard part is often evidence. A suspected flaw is not always an actively exploited vulnerability. A service outage is not always a severe incident affecting product security. The reporting clock starts when the manufacturer becomes aware, so internal notes, customer support tickets and security researcher emails have to reach the people who can make that call. Slow handoffs can become a compliance problem before anyone has written a public advisory.

It also changes what buyers may want to ask. A connected product's support period, update policy and vulnerability handling process are no longer background details. The Commission's manufacturer page says products will need information such as a support period, and that manufacturers must handle vulnerabilities after placement on the market. That makes the promise after purchase part of the product, especially for devices that sit in homes or offices for years.

The open-source angle is more careful than the broad headlines sometimes suggest. The Commission says non-commercial open-source contributions are not treated the same as products made available on the market in commercial activity. It also describes a separate category of open-source software stewards. That distinction matters because modern commercial products often depend on community code, while volunteer maintainers cannot reasonably be treated like device manufacturers by default.

The most tempting version of this story is that Europe is simply getting tougher on insecure tech. That is too blunt. The better reading is that the EU wants connected products to come with a visible security lifecycle: design, updates, support, vulnerability handling and, when things go wrong, fast reporting. The practical burden lands in the spaces between engineering, incident response, customer support and legal review.

For consumers, the change will not necessarily appear as a banner on a product page in September. For businesses, it may show up as more detailed security documentation, clearer support periods, faster incident communications or stricter supplier questionnaires. The quiet shift is that a bug report can no longer be treated as an internal mess to tidy up later. Under the CRA timetable, it becomes a dated event with people, evidence and paperwork attached.

That is where the product roadmap starts to look different. Security work that used to be parked as maintenance now has a deadline of its own.