On 11 September the update path becomes a legal duty

The primary source, and short enough that every product owner should read it once themselves. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents. Early warning within 24 hours, full notification within 72, final report no later than 14 days after a corrective measure is available. The part that gets underestimated: the clock starts once a prompt initial assessment gives you reasonable certainty, and the Commission expects that assessment immediately, not at your next release date. Anyone without a process that produces a first report inside one working day does not have a future compliance problem. They have one from September.

Where the report actually lands, and the reason this particular date makes me uneasy. ENISA’s Single Reporting Platform is meant to be operational on 11 September, with every national CSIRT getting its own notification endpoint inside it. The registration guide for authorised representatives carries a revision date of 3 August 2026. Five weeks between the instructions for the platform and the duty to report through it. The 24-hour clock does not wait for your access to be set up. Registration is not a formality for later, it is the first task.

The practical read that settles the definitional question every discussion gets stuck on. Phillip Ansorge, Managing Security Consultant at usd AG, sets out what "actively exploited" means: evidence of real attacks, not theoretical exploitability. Proof-of-concepts and research results are not enough. That is less of a relief than it sounds, because it inverts the task. You have to be able to tell whether a vulnerability is actually being exploited across your installed base. Anyone who does not observe their devices in the field cannot answer that question, and from September will have to answer it anyway.

The regulation itself, because the distinction that matters usually gets lost in the summaries. Article 69(2) says products placed on the market before 11 December 2027 come under the regulation only if they are substantially modified from that date on. Paragraph 3 takes that straight back for reporting: Article 14 applies to all of them. So your installed base falls under the reporting duty from September even if you never touch it again, and the Commission’s guidance is explicit that no Annex I vulnerability handling duty comes with it. Report yes, fix no. For anything placed on the market after that date, Article 13 applies: the support period has to reflect how long the product is expected to be in use, and five years is the floor rather than the answer. Recital 60 names industrial settings specifically. Sell a machine against a twenty-year service life and you are arguing for twenty years of vulnerability handling, not five.

The part that was fought over hardest and stayed least clean. The regulation creates the open-source steward, a distinct role for organisations that carry a project without being manufacturers, but where commercial activity begins exactly is still unclear. The thought from the discussion that captures the position best: a manufacturer using a thousand open-source projects is responsible for fixing bugs in a thousand projects. I spent four years on the OSGi board and four on the steering committee at the Eclipse Foundation. Governance for shared code does work. It just does not come about by passing liability downwards.