The Cyber Resilience Act's Clock Has Started: Reporting Since 11 September 2026

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 is no longer available as a position. Since 11 September 2026, the Act's incident and vulnerability reporting obligations have applied, and ENISA opened its Single Reporting Platform for business on the same day at initial operating capability. The bulk of the conformity requirements still follow on 11 December 2027 — but the reporting clock is not a design exercise. It is a service level, and it is already running.

What Is Actually Live Now

Article 14 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 notification within 72 hours, and a final report within 14 days of corrective measures being available, or within a month of the 72-hour notification for a severe incident. Reports go to ENISA through the single platform and to the national computer security incident response teams of the member states where the product is used. The scope is broad: connected consumer devices, most software, and the components inside them, with the Act following the product to the EU market regardless of where the manufacturer is based.

Two pieces of scaffolding landed just before the deadline. The Commission published its Article 26 guidance in July 2026, setting out how manufacturers should interact with the reporting system and what the reports need to contain. Delegated Regulation (EU) 2026/881 then established how delayed dissemination works — the mechanism by which a manufacturer can ask for remediation details to be withheld while customers are still being patched, rather than publishing a roadmap for attackers. Both matter because the hardest part of a 24-hour filing is not the form; it is deciding, under time pressure, what may safely be said in public.

How the Platform Works in Practice

The single platform is one entry point rather than one obligation. A manufacturer files once, and the platform routes the report to the relevant national authorities, which removes the older problem of mapping a distributed customer base to a dozen different national portals. The staged structure is deliberate: the 24-hour early warning can be sparse — something is being exploited, in this product, with this apparent impact — while the 72-hour notification carries severity assessment, affected versions, and initial remediation. The 14-day final report follows once a fix exists and can describe root cause and the corrective action taken.

The delayed-dissemination route is the relief valve, and it is narrower than it looks. It postpones publication of remediation detail; it does not postpone the filing, and it does not turn a reportable incident into an unreportable one. Teams that read it as permission to delay disclosure entirely will discover the distinction at the worst possible moment.

What the First Weeks Have Exposed

The early lesson from the first filings is that the bottleneck sits upstream of the form. Manufacturers can generally write a paragraph under time pressure. What they cannot do is answer the questions behind it: which component version is in which shipped firmware, which customers in which countries are affected, and whether the exploited library was even visible in the bill of materials. In several cases the SBOM that existed had been generated once for a customer security questionnaire and never regenerated — a snapshot of a product line as it stood two years ago.

The second exposure is organizational rather than technical. A 24-hour clock assumes someone is watching, and that the person watching is empowered to escalate on a Sunday. Companies whose vulnerability intake is a shared inbox, whose security contact is an unmonitored form, or whose legal review is a single partner's calendar have found that their effective detection time is measured in days. The third is upstream: if a component supplier does not tell you that its parser is being exploited, your clock starts when the researcher emails you — or when a customer reads it on social media.

One scope point is still widely misread. Reporting for open-source stewards does not begin in September 2026; it applies from 11 December 2027, alongside the main conformity obligations. That is a later start, not an exemption, and commercial manufacturers embedding open-source components remain responsible for the product they ship.

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. Regenerate it per release, not per customer request.
• 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 language requiring them to tell you about exploited vulnerabilities quickly enough to leave time for your own clock.
• No rehearsed decision on disclosure: The delayed-dissemination request has to be drafted while the fix is being built, not argued about afterwards.

What to Do With Fourteen Months Left

The teams that will handle December 2027 well are working backwards from the reporting clock they are already on. Start with an inventory of the product estate and its support windows, then fix the SBOM pipeline so it is regenerated with every release, then the vulnerability intake and triage process, then the reporting runbook with named owners, deputies, and pre-agreed legal thresholds for delayed dissemination. 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? Since September, that question has an answer with legal consequences attached.