The Commission's new Cyber Resilience Act guidance answers four questions that were blocking product teams. What it settles, and what it does not.

The short answer

On 27 July 2026, the European Commission published guidance on applying the Cyber Resilience Act — Communication C(2026) 5252 and its annex. It arrives six weeks before the first binding deadline, and it is not a restatement of the regulation.

It addresses, in the Commission's own framing, *"the questions stakeholders have been asking most"*, and it does so with 67 practical examples, use cases, flowcharts and graphs, with particular attention to microenterprises and SMEs.

Four questions are settled:

1. SCOPE       remote data processing solutions, and free and open source software
2. CHANGES     what counts as a "substantial modification"
3. LIFECYCLE   how support periods are understood and applied
4. DUTIES      reporting obligations and risk assessment requirements

The calendar has not moved, and that is the point:

December 2024      the CRA entered into force
11 September 2026  reporting obligations begin to apply
11 December 2027   the main obligations apply

---

Why guidance matters more than it sounds

A regulation tells you what the law requires. Guidance tells you how the authority reads it — and for the CRA, the gap between the two has been where entire product programmes have stalled.

Not because teams were unwilling. Because four determinations decide the cost of everything downstream, and none of them could be made confidently from the text alone. A company that guessed wrong on any of the four was not making a documentation error; it was sizing its entire compliance programme against the wrong obligation.

Guidance does not change the law. It removes the excuse for not deciding.

---

1. Scope — the two hardest cases, addressed directly

The guidance takes on remote data processing solutions and free and open source software — the two scope questions that generate the most disagreement inside product teams.

Remote data processing is the one that changes engineering plans. A device whose features depend on your backend does not have a device scope and a separate cloud scope. Contractual separation between the two does not create regulatory separation, and treating the cloud component as "a service we also happen to sell" has been a common and expensive reading.

Free and open source software is the one that generates the most false confidence. The exclusion attaches to how software is supplied, not to the licence it carries. An open-source component shipped inside a commercial product sits inside that product's scope, and the manufacturer answers for it — including for identifying it and remediating its vulnerabilities.

The regulation also creates a lighter, distinct regime for open-source software stewards. That regime is for the steward. It is not a shelter for the company integrating their work.

---

2. « Substantial modification » — the sleeper, and the one to read first

This is the determination most likely to be discovered late, because it does not arrive at launch. It arrives at the update that follows.

A substantial modification can put a product back through conformity assessment. Which means the practical question is not *"are we compliant today?"* but "which of our releases restarts the clock?" — and that question has to be answerable by the people who ship, not only by the people who file.

A team that cannot tell a routine update from a substantial modification will discover the difference from a market surveillance authority, at a moment it did not choose.

If you read only one part of the guidance, read this one. It is the part that touches your release process rather than your document set.

---

3. Support periods — a commercial commitment, written as a technical one

The support period is where compliance meets the price list.

The CRA requires manufacturers to determine a support period reflecting how long the product is reasonably expected to be in use, at least five years unless the expected lifetime is shorter — and to state it so a buyer knows before purchasing.

Five years of free security updates has a cost, and that cost belongs in the price of the product. Not in a support budget discovered in year three. The guidance clarifying how support periods are understood and applied is not an administrative detail: it is an input to pricing, and it should reach the commercial team, not only the compliance team.

---

4. Reporting and risk assessment — the obligation that binds first

11 September 2026 is six weeks away. It is the date the reporting obligations begin to apply, and it precedes the main body of the regulation by fifteen months.

Almost every compliance plan we see treats the two dates as one. They are not. A manufacturer not yet subject to the full essential requirements can already be subject to the duty to report an actively exploited vulnerability or a severe incident affecting the security of its product.

And reporting is the one obligation that cannot be prepared retroactively, because it is triggered by an event nobody schedules. What it actually requires is unglamorous and cheap: someone reachable with the authority to notify, a written threshold decided in advance for what counts as actively exploited, and a registered reporting path tested before the first incident.

None of that can be improvised inside twenty-four hours.

---

What the guidance does not do

It does not move a deadline. September 2026 and December 2027 are unchanged.

It does not replace the regulation. Guidance is how the Commission reads the text; the text remains what binds, and the harmonised standards and delegated acts continue to be adopted around it.

And it does not make the determination for you. Sixty-seven examples make it far harder to be wrong by accident. They do not make anyone compliant, and they do not remove the need to write down *your* reasoning, *your* classification, and the date you reached it. A market surveillance authority does not ask what the guidance says. It asks what you concluded, and why.

---

What to do this week

1Re-run your scope determination against the two cases the guidance addresses — remote data processing, and open-source components you ship.
2Write your own definition of "substantial modification", and give it to the people who decide releases.
3Confirm your support period, and confirm it is priced.
4Stand up the September reporting path separately from your 2027 programme. It binds first, regardless of how the rest is progressing.

---

Check where you stand — free, no account required

We built two tests for exactly these determinations, and both are free:

[CRA scope test](/assess?reg=cra) — confirm whether your product is in scope, and which class it falls into. Classification decides your conformity route, and therefore your calendar.
[Readiness assessment](/assess) — see which obligations you already meet and which artefacts are missing, across CRA, NIS2, DORA, the AI Act and RED.

No credit card, no sales call to unlock the result.

---

EU Publishes CRA Guidance — What Changes for Products