The Cyber Resilience Act has been in force since December 2024. It sets mandatory cybersecurity requirements for products with digital elements that fall within its scope, covering the whole product lifecycle. On 27 July 2026 the European Commission published new guidance on how that regulation is meant to be applied in practice. Six weeks later, on 11 September 2026, the reporting obligations started to apply. Full compliance with the requirements arrives in December 2027.
Guidance in late July, reporting duties in September, full compliance the year after: the order of those dates is the part worth looking at.
What the guidance actually does
According to the Commission, the document clarifies which products fall within scope, what counts as a substantial modification of a product, how to understand the support period during which the manufacturer has to handle vulnerabilities, and how to meet the reporting and risk assessment obligations. It is addressed to manufacturers, developers and businesses of every size, and it includes practical examples and use cases intended to reduce administrative burden.
Those are not footnotes. They are four of the questions a manufacturer has to settle before it can plan with any confidence. Am I in scope? When does a change to my product reset my obligations? How long am I on the hook for vulnerability handling? Who do I notify, and when?
Henna Virkkunen, Executive Vice-President for Tech Sovereignty, Security and Democracy, presented the document as part of the Commission’s simplification agenda, built to help businesses meet their obligations “on time and with confidence”, and argued that a cyber-secure Europe and a business-friendly Europe go hand in hand, the point being to protect products on the market while minimising unnecessary burden and legal uncertainty.
Let us be precise about the vocabulary, because the vocabulary is doing a lot of unpaid work. Explaining to the people you regulate what your own sentences mean is interpretive maintenance of a legal text. It is useful. It is not simplification. Simplification would mean fewer obligations, or obligations drafted clearly enough that a guidance document was not the thing standing between a company and its first deadline. Filing that maintenance under an agenda named simplification is a communications choice, and it deserves to be read as one.
Clarity and capacity are not the same thing
The gap between 27 July and 11 September is real and it is short. What it does not prove is that nobody could prepare. The regulation existed, the obligations existed, and work was possible before the guidance landed.
What the gap does expose is a different problem, and a more durable one. A clarification published in the summer of 2026 does not retroactively reorganise engineering decisions already taken, and no document from Brussels turns a department that does not exist into a vulnerability handling process. Understanding an obligation and being able to discharge it are separate capabilities, built on separate timelines, and only the first one can be delivered as a PDF.
The support period is a budget line
Of everything the guidance touches, the support period is the item most likely to decide whether this regulation changes industrial behaviour or generates paperwork. It is the window during which a manufacturer must keep handling vulnerabilities in something already sold.
That is a commercial question wearing a technical costume. Take a hypothetical that anyone in the sector will recognise: a cheap connected camera, priced on thin margins, assembled around a firmware module bought from an external supplier, shipped through a distributor who will never speak to the designer again. In a case like that the obligation does not bend, but the budget was never built for it. A support period is not a pricing option a manufacturer gets to weigh against gross margin; it is a legal requirement, and honouring it means someone funds vulnerability handling for an object whose price was set without that line in it. The risk is not open refusal. The risk is compliance on paper: a support period declared in a document and attached to a product nobody is resourced to maintain. The guidance explains how to read the concept. It does not pay for the work, and the work is where this regulation either bites or dissolves.
The ones the guidance says it was written for
The Commission gives particular attention to microenterprises and small and medium-sized enterprises, and explicitly acknowledges their resource constraints and implementation difficulties. Good. Acknowledgement is cheap, and it is also the easiest part of a file to publish.
Capacity is not evenly distributed here, and saying so is arithmetic rather than caricature. An organisation that already runs a product security function reads this guidance as an input to an existing process. An organisation without one reads it as a description of work it has nobody to do. For that second company the questions are unglamorous and practical: does this bought-in component sit inside my perimeter, does my supplier’s patch stream count as my vulnerability handling, and who files the notification when something is being exploited at two in the morning. Practical examples help with the first question. They do not answer the third.
The reason given for the hurry
The Commission links the need for swift and correct implementation to recent developments in frontier AI models with offensive cybersecurity capabilities, which in its reading make structured vulnerability management across the product lifecycle more urgent.
Take that at face value. It is the Commission’s own stated motivation and it is not unreasonable. But notice what it implies about the shape of the problem. The deadlines themselves sit in the regulation, not in anybody’s threat model. What the argument reveals is where the pressure is coming from: outside, in capability the institution does not control, while inside, in mid-2026, the conversation was still about what its own words mean.
Full compliance arrives in December 2027, seventeen months after this guidance landed. The questions the document takes on, scope, substantial modification, support period, reporting, are exactly the ones that shape how a product gets designed and priced, and the organisations least equipped to act on the answers are precisely the audience the Commission names in its own text. A document that explains obligations more clearly is worth having. It is not the thing this audience is short of, and calling it simplification does not make it so.
Raffaele Di Marzio
All my “insane” books on cybersecurity and governance are here 👇 https://cyberium.limited/bookshelf.html