A company should not be able to sell a connected product, learn that attackers are exploiting it, and treat that knowledge as nobody else’s business.
Europe has taken a concrete step toward making that principle enforceable. On September 11, 2026, reporting obligations under the European Union’s Cyber Resilience Act began applying to manufacturers of covered digital products. They must provide an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe security incident, followed by a fuller notification within 72 hours. [1]
That is a meaningful change. But the public should judge it by what happens after the report arrives.
A completed form does not secure a router. A notification does not update a vulnerable application. Accountability requires a path from knowing about danger to reducing it.
ENISA, the EU cybersecurity agency, now provides a Single Reporting Platform through which manufacturers can notify the relevant authorities. Its stated purpose is to simplify reporting and support coordinated handling of risks. This is a channel for authorities, not a promise that every submitted technical detail will immediately become public. [2]
The timeline also needs careful explanation. Most of the act’s broader obligations apply from December 11, 2027. September’s milestone should not be presented as the arrival of every product-security requirement at once. [3]
Our position is that early reporting is valuable precisely because it can trigger action. It should never become a substitute for action.
Consider a hypothetical manufacturer that discovers an exploited flaw in a component shared across several products. It files its report on time. Yet its customers cannot determine which models are affected, the update instructions are unclear, and older devices have no obvious recovery path.
The reporting deadline has been met. The people exposed to the flaw still have a problem.
This example is not an allegation about a particular company. It illustrates the difference between measuring an administrative process and measuring protection.
A useful accountability system should ask both kinds of questions. Was the warning timely? Were affected versions identified? Did users receive understandable advice? Was a mitigation available while a repair was being prepared? Could ordinary customers install the fix without losing access to the product they bought?
These are the outcomes we believe regulators should make visible through aggregate reporting and independent evaluation, while protecting sensitive information about unresolved vulnerabilities.
The work also begins before an incident. If a manufacturer cannot identify what software it ships, it starts every emergency by reconstructing its own product. Reporting deadlines make that weakness harder to ignore.
ITPro’s September 11 coverage highlighted industry concerns about identifying affected components and products within the new reporting windows. Those concerns deserve attention, but they should prompt better preparation—not become an argument that customers must accept permanent uncertainty. [4]
There is another responsibility question beneath this: who pays for the repair?
Open-source software requires care here. The European Commission explains that the act distinguishes commercial activity, individual contributions, and a separate category of open-source software stewards. It does not simply treat every person publishing code as a commercial manufacturer. The Commission also says stewards’ reporting obligations begin in December 2027. [5] [1]
Those distinctions matter. Publicly available code is not an unlimited promise of unpaid support.
In our view, a company that builds a commercial product around community-maintained software should budget for maintaining that dependency. That can mean funding upstream work, contributing tested fixes, or providing engineering help during an incident. Sending urgent demands to a volunteer is not a sufficient security strategy.
Regulators have responsibilities, too. A reporting system accumulates sensitive information. It should collect what responders need, restrict access appropriately, and explain how the information is used. More collection is not automatically better coordination.
The public should also resist premature victory claims. The start of reporting duties establishes a process; it does not yet establish how much harm that process will prevent. Evidence of effectiveness must follow.
For Americans, this is a useful model to examine without pretending EU rules automatically provide identical protections here. We can ask the same practical questions of products sold in our own market: Who owns the response when something goes wrong? How long will repairs be available? How will customers learn what they need to do?
At Patch the State, we believe responsibility should follow the ability to act. Manufacturers should know their products. Authorities should turn warnings into coordination. Commercial users of shared code should help sustain it.
The goal is not a larger archive of security failures.
It is fewer people left exposed after a failure becomes known.