The Cyber Resilience Act Has a Clock: What 11 September 2026 Means for Connected Products

The Cyber Resilience Act entered into force in December 2024, and for most of the intervening period product teams treated it as a distant problem. That window is closing. From 11 September 2026, the Act's incident and vulnerability reporting obligations begin to apply, while the bulk of its conformity requirements follow from 11 December 2027. The first deadline is the harder one, because it is not a design exercise — it is an operational service level.

What Actually Starts in September

Article 14 of the Act obliges manufacturers of products with digital elements to report actively exploited vulnerabilities and severe security incidents through a staged process: an early warning within 24 hours of becoming aware, a more detailed vulnerability notification within 72 hours, and a final report within 14 days of corrective measures being available. Reports go to the European Union Agency for Cybersecurity through a single reporting platform and to national computer security incident response teams in the relevant member states. The scope is broad: connected consumer devices, most software, and the components inside them — the Act follows the product to the EU market regardless of where the manufacturer is based.

Why a 24-Hour Clock Is an Engineering Problem

Meeting that clock requires capabilities most product organizations have never built, because they were not previously required to. You must know what is inside your product and in the field, which means a software bill of materials that is maintained rather than generated once for a customer questionnaire. You must have a vulnerability intake process that works at three in the morning on a weekend, an external security contact that researchers can actually find, and telemetry sufficient to learn that something in your fleet is being exploited in the wild — a signal that many vendors currently receive by reading the news.

The Gaps That Sink First Audits

• No SBOM, or a stale one: Component-level awareness is a precondition for the 72-hour notification, not a nice-to-have.
• No coordinated disclosure channel: A published security contact and a documented disclosure policy are the cheapest obligations to satisfy and the most commonly skipped.
• No viable update path: A support period measured in months, an unsigned firmware update mechanism, or an end-of-life device population with no update route makes every reporting obligation unanswerable.
• No contractual upstream reporting: If your information comes from component suppliers, you need contractual language requiring them to tell you about exploited vulnerabilities quickly enough to leave time for your own clock.

What to Do Before December 2027

The teams that will handle this well are working backwards from the reporting clock. Start with an inventory of the product estate and its support windows, then build the SBOM pipeline, then the vulnerability intake and triage process, then the reporting runbook with named owners and pre-agreed legal review thresholds. Enforce cryptographic verification on the update mechanism, since an unverifiable update channel is both a compliance gap and a supply chain liability. Finally, rehearse the reporting path itself: a dry-run notification against a synthetic exploited vulnerability will reveal, in an afternoon, whether your process depends on one person's inbox.

The Act's consumer benefits will take years to be fully visible. The near-term differentiator for manufacturers is narrower and more practical: when a vulnerability is exploited in your fleet, can you learn about it, verify it, and file within 24 hours? If the honest answer is no, the clock has already started.