Key Takeaway: The Cyber Resilience Act reporting requirements begin on September 11, 2026, well before most of the regulation applies in December 2027. Manufacturers of covered products must be ready to report certain actively exploited vulnerabilities and severe product-security incidents, with an initial warning due within 24 hours of awareness. Preparing now means knowing which products are affected, where they are sold, and who is responsible for responding.
The Deadline Hidden Inside a Later Deadline
The Cyber Resilience Act starts a new reporting clock on September 11, 2026, and many manufacturers may not realize it. This EU cybersecurity law covers connected hardware, software, and certain remote services tied to those products. If your company sells connected products in Europe, this date deserves attention. The broader product-security framework will eventually reshape design, support, and vulnerability management. Yet one operational duty arrives well before most requirements.
Most provisions begin applying on December 11, 2027. Article 14 begins fifteen months earlier, on September 11, 2026. From that date, manufacturers must report certain actively exploited vulnerabilities and severe product-security incidents. For a qualifying event, the first warning must arrive within 24 hours of awareness. Companies will have little time to identify the product, assess the event, and decide who needs to know.
What Changes When the Cyber Resilience Act Reporting Clock Starts?
September 11 activates a live reporting responsibility, not the regulation’s complete product-compliance framework.
The schedule unfolds in stages. Some rules for organizations that assess product compliance began applying on June 11, 2026. Article 14 reporting starts on September 11, 2026. Most remaining requirements follow on December 11, 2027.
That early date can catch companies off guard. A manufacturer may still be planning its wider 2027 compliance program. Meanwhile, its security team must already recognize and report qualifying events.
The Cyber Resilience Act also reaches older products through its reporting duties. The requirements cover products placed on the EU market before December 11, 2027. Legacy devices, earlier software versions, and long-installed systems may therefore enter the reporting process.
Which Products and Companies May Be Affected?
The regulation uses the term “products with digital elements.” In everyday language, that generally means connected hardware, software, and certain related digital components.
Examples can include routers, smart cameras, industrial controllers, connected sensors, gateways, firmware, commercial software, and device-management applications. Certain remote services may also fall within scope when the product depends on them for a function.
The rules focus mainly on manufacturers that market covered products under their name or trademark. A manufacturer outside Europe may still face the duty when it makes covered products available on the EU market.
Some sectors follow separate European rules, and exclusions exist. Companies should therefore assess coverage product by product rather than relying on a broad label.
Which Security Events Must Manufacturers Report?
The new clock does not start whenever someone discovers a flaw. The law identifies two main reporting triggers.
Does the Cyber Resilience Act require every vulnerability to be reported?
No. The first trigger is an actively exploited vulnerability.
Reliable evidence must show that a malicious actor used the flaw without the system owner’s permission. A newly published vulnerability record does not automatically prove active exploitation. An internal test or good-faith researcher’s demonstration may not meet the threshold either.
Those discoveries can still demand urgent investigation and repair. However, Article 14 focuses mandatory reporting on malicious exploitation that has moved beyond theory.
The difficult question often concerns awareness. When did the company receive enough reliable evidence to recognize active exploitation? A clear internal escalation process can help teams answer that question consistently.
What counts as a severe product-security incident?
The second trigger covers severe incidents affecting product security.
A compromised software-update system offers a useful example. Attackers may tamper with a release channel and introduce malicious code into customer products. The incident can become reportable even when the original breach began inside the manufacturer’s environment.
Such an incident can threaten important data or functions. It can also create a path for malicious code to reach products or user systems.
How Do the 24-Hour and 72-Hour Clocks Work?
The reporting process unfolds in stages. Manufacturers do not need a completed forensic investigation within the first day.
The early warning comes first, without undue delay and no later than 24 hours after awareness.
A fuller notification follows within 72 hours of that same awareness point. It should include available details about the product, event, mitigations, and actions users can take.
The final deadline depends on the trigger. For an actively exploited vulnerability, the final report follows within 14 days after a corrective measure becomes available. For a severe incident, it follows within one month after the 72-hour notification.
So, does the 72-hour clock start after the early warning? No. Both deadlines begin when the manufacturer becomes aware of the reportable event.
Consider a simple example. A gateway manufacturer confirms active exploitation at 9:00 a.m. Monday. Its early warning falls due by 9:00 a.m. Tuesday. Its fuller notification falls due by 9:00 a.m. Thursday.
The Portal Is Not the Hard Part
The Cyber Resilience Act directs manufacturers to a Single Reporting Platform run by the European Union Agency for Cybersecurity, or ENISA. The agency says manufacturers will use the platform for mandatory reporting from September 11, 2026.
The platform provides a route for the notification. It cannot tell a company which products contain a vulnerable component. It also cannot identify affected versions, customers, markets, or suppliers.
That work depends on product visibility. Product teams may need to connect a security alert with several different records. Those records can include component inventories, firmware histories, supplier data, sales channels, and customer support systems.
A small product line may allow manual investigation. A large portfolio quickly makes that approach fragile. The twenty-four-hour clock turns scattered product information into an operational risk.
What Should Manufacturers Prepare Before September 11?
Preparation starts with a current product register. The record should connect products with software versions, firmware releases, important components, support status, and EU markets.
A component-to-product map adds another layer. It helps teams answer a common question quickly: “Which shipped products contain this vulnerable library, chipset, or supplier module?”
Preparation also depends on clear roles and decision authority. Product security, engineering, legal, customer support, communications, and supply-chain teams may each hold part of the answer. A cross-functional response group can connect those pieces before a deadline forces an improvised handoff.
Named decision-makers should understand who can approve and submit the early warning. Backup coverage becomes important during weekends, holidays, and absences.
Supplier communication deserves similar planning. A supplier may discover exploitation before the manufacturer does. Slow escalation can consume most of the reporting window before the product team receives the evidence.
Customer communication also belongs in the process. Manufacturers must inform impacted users and explain relevant mitigation or corrective steps. Current contact records and clear message templates can reduce confusion during an incident.
A Tabletop Exercise Can Expose Hidden Gaps
A short simulation can show whether the process works outside a policy document.
Imagine that a supplier reports active exploitation in a library used by a connected gateway. The supplier has not released a patch. The manufacturer does not know which firmware versions contain the affected code.
Can the team identify the products and EU markets? Can it establish the awareness time and reporting threshold? Does someone have authority to submit the early warning? Can customer teams explain a temporary mitigation?
A useful exercise tests more than cybersecurity knowledge. It tests records, ownership, communication, and decision speed.
The simulation can also reveal where people depend on one employee, one spreadsheet, or one distributor. Those hidden dependencies often become visible only when the clock starts.
Conclusion: The Clock Tests More Than Compliance
September 11 will not require every manufacturer to finish its entire 2027 compliance program. It will require covered companies to operate a live reporting process for qualifying security events.
The practical challenge begins before anyone opens the reporting platform. Companies must connect an alert to products, versions, components, markets, suppliers, and users. Strong records can turn a confusing incident into a manageable response. Fragmented records can consume the few hours available.
The Cyber Resilience Act may look like a reporting rule, but it also tests product visibility and operational readiness. As cybersecurity requirements continue to reshape connected products, Tech Scope Connect explores what these changes mean for technology and business. Join the conversation through our insights, live newscasts, and industry events.
Sources:
- Cyber Resilience Act – Reporting Obligations | digital-strategy.ec.europa.eu
- Eur-Lex – Official Journal of the European Union | eur-lex.europa.eu
- The Cyber Resilience Act – Summary of the Legislative Text | digital-strategy.ec.europa.eu
- Single Reporting Platform (SRP) | enisa.europa.eu
