The third clock

Under Article 71 of Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 applies from 11 September 2026 and Chapter IV (Articles 35 to 51) from 11 June 2026, while the Regulation applies in general from 11 December 2027. Reused from the edition of 5 August 2026.

Why it matters

europeancyb2024cyberb

Article 14(1)-(2) requires a manufacturer that becomes aware of an actively exploited vulnerability in its product with digital elements to notify the CSIRT designated as coordinator and ENISA simultaneously through the single reporting platform: an early warning within 24 hours indicating the Member States affected, a vulnerability notification within 72 hours with general information and any corrective measures, and a final report no later than 14 days after a corrective or mitigating measure is available.

Why it mattersTwenty-four hours is not enough time to go looking. It only works if 'which of our shipped releases contains this component' is already a query, which makes SBOM coverage — including code and dependencies chosen by an agent — an operational control rather than a compliance artefact.

europeancyb2024cyber · europeancom2026cyber

Article 14(3)-(4) applies the same notification route to a severe incident having an impact on the security of the product, with an early warning within 24 hours noting whether unlawful or malicious acts are suspected, an incident notification within 72 hours with an initial assessment, and a final report within one month. Article 14(8) requires the manufacturer to inform impacted users of the vulnerability or incident and of risk mitigation measures, and permits CSIRTs to disseminate that information where the manufacturer does not act in time.

Why it mattersThe duty to inform impacted users, and the CSIRT's power to do it for you if you are late, means the disclosure decision is no longer entirely the vendor's to time.

europeancyb2024cyber

Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. Article 3(13) defines a manufacturer as a person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its own name or trademark, whether for payment, monetisation or free of charge.

Why it mattersTwo scope surprises in one article. The trigger is exploitation in any system, not necessarily the manufacturer's own, so a quiet internal estate is no defence. And 'free of charge' in the manufacturer definition pulls in free tiers and self-published tooling.

europeancyb2024cyberc

Article 12 of the Cyber Resilience Act provides that products with digital elements classified as high-risk AI systems under Article 6 of Regulation (EU) 2024/1689 are deemed to comply with the cybersecurity requirements of Article 15 of that Regulation where they meet the essential requirements of Annex I Part I, the manufacturer's processes meet Annex I Part II, and compliance is demonstrated in the EU declaration of conformity, with the conformity assessment procedure of Article 43 of Regulation (EU) 2024/1689 applying.

Why it mattersThe constructive half of the story. A team that builds Annex I evidence once can spend it against Article 15 of the AI Act as well, instead of running two parallel cybersecurity workstreams.

europeancyb2024cyberd

ENISA states that the Single Reporting Platform established under the Cyber Resilience Act is scheduled to be operational by 11 September 2026, acting as a single entry point for manufacturers and open-source software stewards to submit vulnerability and incident notifications, and supporting voluntary reporting after that date.

Why it mattersThe notification does not go to a data protection authority or to a familiar national regulator. It goes through a platform that does not exist yet in production, on the same day the duty starts. Registration and a dry run belong on the calendar before September.

enisa2026single

Article 24 limits the application of Article 14 to open-source software stewards: the Article 14(1) obligation applies to them only to the extent that they are involved in the development of the product, and the Article 14(3) and 14(8) obligations apply only in respect of severe incidents having an impact on the security of the network and information systems they provide for the development of the product.

Why it mattersPrevents the obvious overreaction. A maintainer who stewards a project without placing a product on the market is not exposed the way a commercial manufacturer is, and the edition should not imply otherwise.

europeancyb2024cybere