2026-08-05 — The third clock

Article 14 of the Cyber Resilience Act — Regulation (EU) 2024/2847 — applies from 11 September 2026, 37 days after this edition, and it adds a third awareness-anchored notification clock alongside GDPR Article 33 and NIS2 Article 23. Its trigger is different: reliable evidence that a malicious actor has exploited a vulnerability in your product in a system, not necessarily your own, reported within 24 hours to a CSIRT and ENISA rather than to a data protection authority. It reaches you as a manufacturer, a definition that covers software marketed under your name whether for payment, monetisation or free of charge. The upside is Article 12: meeting the CRA's essential requirements gets a high-risk AI system deemed compliance with Article 15 of the AI Act, so the evidence is built once and spent twice.

Post

Your feed spent last week on 2 August. The deadline that will actually land on your engineering team is 11 September.

It is not in the AI Act.

Regulation (EU) 2024/2847 — the Cyber Resilience Act — applies in full from 11 December 2027. But Article 14, the reporting duty, starts on 11 September 2026. Thirty-seven days from today.

Read the trigger carefully, because it is not the one you are used to.

You report when you become aware of an actively exploited vulnerability in your product. The definition is reliable evidence that a malicious actor has exploited it in a system, without permission of the system owner. Not your system. A system.

So your own estate can be entirely quiet — no breach, no alert, nothing in your SIEM — and you still owe an early warning within 24 hours, a notification within 72, and a final report within 14 days of a corrective measure being available. To a CSIRT and to ENISA, through a single reporting platform, not to your data protection authority.

That is the third clock.

GDPR Article 33 gives a controller 72 hours from awareness of a personal data breach. NIS2 Article 23 gives 24 and 72 from awareness of a significant incident. CRA Article 14 gives 24 and 72 from awareness that someone, somewhere, is exploiting your code. Three triggers, three recipients, one event that may start all of them or none of them.

For anyone shipping agents this gets uncomfortably concrete. The product you now have to report on increasingly contains code an agent wrote and dependencies an agent chose.

What I'd do Monday:

  1. Check whether you are a manufacturer. The definition covers software you market under your own name "whether for payment, monetisation or free of charge". Your free tier counts.

  2. Make "which of our shipped releases contains this component" a query, not an investigation. Twenty-four hours is not enough time to go looking.

  3. Name the person who files at 03:00 on a Sunday. Not the policy — the person.

  4. Then take the upside. Article 12 says a high-risk AI system that meets the CRA's essential requirements is deemed to comply with Article 15 of the AI Act. Build the evidence once, spend it twice.

Could your team file a 24-hour early warning this weekend?

#CyberResilienceAct #AIAct #AgenticAI #ProductSecurity #Berlin

First comment

Sources, primary first —

Cyber Resilience Act Article 14 — the 24-hour early warning, 72-hour notification and 14-day final report, and the duty to inform impacted users https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html

Article 71 — Article 14 applies from 11 September 2026; the rest of the Regulation from 11 December 2027 https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_71.html

Article 3 — the definitions of "manufacturer" (13) and "actively exploited vulnerability" (42) quoted above https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_3.html

Article 12 — high-risk AI systems meeting the CRA's essential requirements are deemed to comply with Article 15 of the AI Act https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_12.html

The consolidated Regulation (EU) 2024/2847 on EUR-Lex https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

The Commission's own page on CRA reporting obligations, confirming the 11 September 2026 date https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

ENISA on the Single Reporting Platform — scheduled operational by 11 September 2026 https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

Cut for length: Article 24 softens this for open-source software stewards — the Article 14(1) duty applies to them only "to the extent that they are involved in the development" of the product. If you steward a project but do not ship it, read that one before you panic.

Claims

Sources

Corrections

No corrections. Two items were considered and held back before publication: figures from a vendor telemetry report whose primary landing page did not support the numbers circulating in coverage, and second-hand vulnerability-rate statistics reproduced from a research note rather than from the studies themselves.