At 9:00 a.m., a security engineer discovers that a flaw in a company’s router software is being actively exploited. The engineer does not yet know how many customers are affected, whether attackers have stolen data or whether a patch is safe to release.

Under a new European Union rule, the company now has 24 hours to begin reporting it.

That is the immediate significance of September 11, 2026. The European Union’s Cyber Resilience Act has begun imposing its first operational obligation on manufacturers of products with digital components: They must report actively exploited vulnerabilities and severe security incidents through a new platform operated by the EU Agency for Cybersecurity, or ENISA. (European Commission)

The broader act will not fully apply until December 11, 2027. But the reporting system starts today, aimed at a problem that has existed for as long as software has been shipped: Companies often learn that their products are being abused before customers, regulators or other manufacturers do.

The law is an attempt to make that knowledge move faster. The important question is whether a reporting deadline will produce better security—or merely faster paperwork.

What changes today

The rule covers “products with digital elements,” a deliberately broad category that includes hardware and software made available on the EU market. That can include consumer devices, industrial equipment, software applications and components sold separately. (European Commission guidance)

Manufacturers must report two types of events.

The first is an actively exploited vulnerability: a security weakness for which there is reliable evidence that an unauthorized actor has used it. The second is a severe incident that affects, or could affect, a product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions. (ENISA)

The reporting schedule is compressed:

  • An early warning must be submitted within 24 hours of the manufacturer becoming aware of the vulnerability or incident.
  • A fuller notification must follow within 72 hours.
  • For an exploited vulnerability, a final report is due within 14 days after a corrective or mitigating measure becomes available.
  • For a severe incident, the final report is due within one month of the fuller notification.

The manufacturer reports once through ENISA’s Single Reporting Platform. The information is then routed to the appropriate national computer-security incident response teams, or CSIRTs, and to ENISA. In principle, this replaces the process in which a company must determine which countries and regulators need to be contacted individually. (European Commission)

That is an administrative improvement. It is also a technical one. Security incidents rarely respect national borders, and the same router, software package or industrial controller may be sold throughout Europe. A central intake system gives regulators a chance to see the same failure as a cross-border event rather than as a collection of disconnected national reports.

The law does not require companies to know everything immediately

The 24-hour deadline is not a requirement to produce a complete forensic investigation overnight. The first notification is an early warning. Later submissions are expected to add information as the manufacturer understands what happened and what users should do.

That distinction matters. In a serious intrusion, the first confirmed fact may be only that an exploit exists and is being used. The manufacturer may not yet know the identity of the attacker, the full extent of the damage or whether the vulnerability is present in older product versions.

The regulation reflects that reality by dividing the process into stages. The initial warning can be limited; subsequent reports are expected to contain the product involved, the general nature of the exploit, the initial assessment and the corrective or mitigating measures available to users. (Cyber Resilience Act)

The visible deadline is 24 hours. The less visible requirement is organizational knowledge.

A manufacturer cannot report quickly if it does not know which products contain the affected component. It cannot tell customers how to respond if it does not know which versions are still supported. And it cannot determine whether a vulnerability is being actively exploited if its monitoring process is designed only to handle customer complaints after the fact.

The difficult part may be knowing what a company shipped

The reporting obligations apply to products within the act’s scope that were already placed on the market before the act’s main requirements begin in December 2027. The deadline is not limited to devices launched after the new law takes full effect. (ENISA)

That creates an awkward transition for manufacturers.

A company may still be selling a product designed years ago, using third-party software that has changed hands or components whose original developers are no longer available. The product may have been certified under an older process while its security obligations are now being evaluated under a newer one.

This is where software inventories and software bills of materials become more than compliance documents. A software bill of materials is essentially a list of the components inside a product. It does not make the product secure, but it can help a manufacturer identify which products are affected when a shared library or embedded component is compromised.

The European Commission’s guidance addresses vulnerability-handling processes and software bills of materials as part of the act’s broader requirements. (Cyber Resilience Act)

That will be useful for companies with mature engineering organizations. It will be more difficult for companies whose products were assembled through acquisitions, contractors and abandoned code repositories. Those companies may discover that their biggest security problem is not a newly discovered flaw. It is that nobody can say exactly where the flaw exists.

What the law does not do

The Cyber Resilience Act does not instantly turn insecure products into secure ones.

It does not prevent a vulnerability from being introduced. It does not guarantee that a patch will be available quickly. It does not guarantee that customers will install the patch. And it does not eliminate the difficult judgment involved in deciding whether a flaw is being actively exploited or whether an incident is severe enough to report.

It also does not mean every vulnerability must be publicly disclosed within 24 hours. The required reports are sent to designated CSIRTs and ENISA through the platform, and the regulation includes confidentiality provisions. In some circumstances, information can be withheld from wider dissemination for justified cybersecurity reasons. (European Commission)

That restraint is necessary. Publicly describing an unpatched flaw in a widely deployed product can help defenders, but it can also help attackers. A useful reporting system must share information quickly with the people capable of containing the problem without automatically publishing an exploit guide before a fix exists.

The law is therefore trying to balance two competing risks: companies keeping quiet for too long, and regulators or vendors disclosing too much before customers can protect themselves.

The open-source question is more complicated

Open-source software is not treated exactly like commercial software under the act.

The regulation creates a category called an open-source software steward for legal entities that provide sustained, systematic support for software intended for commercial activities and help ensure its viability. Those stewards have cybersecurity responsibilities, but the relevant reporting obligations for them apply later, beginning December 11, 2027. (European Commission)

That distinction matters because open-source software is often maintained by a mixture of volunteers, foundations, companies and informal communities. Treating every individual contributor as a commercial manufacturer would be impractical. Treating no one as responsible would leave widely used infrastructure without an accountable party.

The act’s approach is an attempt to regulate the organizations that effectively maintain and commercialize important projects without treating every person who publishes code as a regulated manufacturer. Whether that boundary holds up in practice will depend on how regulators interpret “sustained” support and commercial intent.

Why American companies should care

The rule is European, but its practical reach is not limited to European companies. It applies to products made available on the EU market, which means a U.S. manufacturer selling covered hardware or software to European customers may need to build its incident-reporting process around these requirements.

That does not necessarily mean the company will create a separate European product. The cheaper approach may be to adopt the strictest reporting and vulnerability-management process across all markets.

This is how European technology regulation often travels: not necessarily through direct legal authority over American operations, but through the cost of maintaining several different versions of a product and its support procedures.

The regulation’s full lifecycle requirements—including security design, vulnerability handling, updates and support—take effect in 2027. The Commission published implementation guidance in July 2026 to clarify product scope, substantial modifications, support periods, risk assessment and reporting. (European Commission)

For U.S. customers, the result could be indirect but meaningful. A product sold in both markets may acquire a longer support process, more formal vulnerability-disclosure procedures or clearer documentation because the manufacturer wants one global system rather than separate European and non-European workflows.

That outcome is not guaranteed. Companies can also choose to withdraw products from the EU, limit their features or pass compliance costs to customers. The effect will vary by product and manufacturer.

The first test is not a cyberattack

The immediate test for the Single Reporting Platform is operational.

Can manufacturers authenticate themselves quickly? Can they determine which authority should receive a report? Can the platform remain available during a major, simultaneous incident? Can national CSIRTs process a sudden increase in reports without turning the system into a queue?

ENISA says the platform’s initial operating capability is deployed and that it has been tested with national CSIRTs, selected manufacturers and other users. It also says the system will continue to be improved based on operational experience. (ENISA)

That last phrase is worth noticing. The platform is being deployed before the broader law takes effect, but it is still a system whose real performance will be learned under pressure.

A reporting system can fail in several ways. It can be unavailable when a manufacturer needs it. It can accept reports that are too vague to help defenders. It can overwhelm small companies that lack round-the-clock security staff. Or it can produce so many low-value notifications that genuinely urgent warnings become harder to identify.

The regulation attempts to ease the burden for small businesses. The EU’s summary says microenterprises and small enterprises may not be fined for missing the 24-hour deadline, although that does not remove the obligation itself. (European Commission)

That distinction will matter. A small company may be legally responsible for reporting but technically unable to maintain the same incident-response operation as a multinational hardware vendor.

The larger change is cultural

For years, product security has often been treated as a customer-support issue: Someone finds a flaw, a company issues a patch, and the incident disappears into a stream of advisories.

The Cyber Resilience Act treats product security more like a product lifecycle responsibility. The manufacturer is expected to know what it shipped, maintain it, respond to evidence of exploitation and coordinate with authorities when the failure affects customers.

That is a meaningful change in the relationship between software companies and the people who depend on their products.

But reporting is not the same as resilience. A company can meet a 24-hour deadline and still ship a poor patch. It can provide a detailed incident report and still leave customers exposed. It can maintain excellent documentation while building products that are too difficult to update.

The act will succeed only if the reports lead to better decisions: faster containment, clearer customer instructions, more durable fixes and better information about which components repeatedly create risk.

Europe has now built the clock. The harder task is making sure the information that enters the system changes what manufacturers do next.