The Commission adopted its Article 26(1) guidance on the Cyber Resilience Act on 27 July 2026. Most of the commentary since has focused on the four-factor test for substantial modification and the correction to the support period, which we covered in reading the four-factor test and the support period rules.
This post is about the other half of the document. C(2026) 5252 contains 67 numbered worked examples and 5 remote data processing use cases, and for a manufacturer trying to answer a concrete question they are worth more than the prose around them. We have published all of them, word for word, at the worked examples hub, grouped by the question each one answers.
What follows is what the example set tells you when you read it as a whole, and in particular what the Commission added between the consultation draft and adoption.
The draft-to-final diff
The earlier consultation draft carried 55 numbered examples. Comparing them against the adopted 67 gives a clean picture.
Fifty-four of the draft examples survive. Two of them were merged into one, the spare parts case that now handles a pre-CRA host product and a post-CRA host product in a single example. One draft example was deleted outright. Fourteen examples in the adopted text are new.
Additions are not distributed evenly, and where they cluster is the interesting part.
Where the Commission added examples
Scope of software, four new examples. The draft said little about what kind of software is a product with digital elements. The adopted text says it four times in a row. A mobile app installed from an app store is in scope. A desktop application built with web technologies but packaged for local installation is in scope. A web application reached only through a browser is not, unless it supports the functionality of a product that is. A website that merely presents information is not.
The fourth of these carries a sting that is easy to miss. If a locally installed client relies on data processing at a distance in order to perform one of its functions, that remote processing is part of the product. Moving logic to a back end does not move it out of scope.
Legacy hardware, two new examples. One confirms that components bought before the CRA applied can be integrated, provided the risk assessment finds no specific risk and the finished product complies as a whole. The other confirms that the spare parts exemption applies whether the replacement is a component inside a subassembly or the whole subassembly.
Integration, one new example. A company that buys off-the-shelf modules, writes its own firmware and assembles a connected product under its own name is not substantially modifying anything. It is placing a new product on the market and owns compliance for the whole of it. This one answers a question integrators have been asking since the Regulation was published.
Support periods, three new examples. All three test whether a substantial modification changes the expected use time. Adding cleaning modes to a robot vacuum does not. Rearchitecting the cloud back end of industrial machinery does not. Replacing a programmable logic controller's computing platform with components designed for a significantly longer operational lifetime does, and the manufacturer recalculates.
Risk assessment, two new examples. Both describe treating a risk without building a control. An industrial sensor manufacturer limits the intended purpose to trusted environments and says so in the user information. A software manufacturer relies on the operating system's native encryption rather than writing its own.
Classification, one new example. A unified security suite whose modules are also sold on separate subscriptions is classified module by module. In the Commission's own scenario, one suite produces an important class I product, an important class II product and a default product.
Contributors, one new example. A person who submits a pull request that maintainers review and merge is a contributor and is not subject to the CRA, because they exercise no primary control over releases or distribution.
Read together, the additions are a map of where the Commission expected confusion. Two of the seven clusters are about who owns compliance when more than one party touched the code, which is integration and contributors. One is about products and components that predate the Regulation. The largest single addition, four examples, went to a question the draft barely addressed, which is what kind of software is a product at all.
The example that was deleted
The draft had two physical repair examples. The first described replacing a defective RAM module with a better performing one and concluded the server was not substantially modified. The second described a similar operation that significantly changed the server's behaviour by altering how core functions execute, a change the original risk assessment had not considered, and concluded that the server was substantially modified.
The first survives as Example 35. The second is gone.
The rule it illustrated is still in force at point 95, so the deletion narrows the illustration rather than the rule. It is worth knowing about anyway, for two reasons. Anyone who worked from the draft will remember it and may cite it. And it remains the clearest statement anywhere in either document of what a physical repair has to do before it crosses the line. We reproduce it on the repairs and spare parts page, labelled as removed.
What the examples are actually useful for
Three of the eight groupings will answer a real question for most manufacturers on a normal working day.
The substantial modification examples collect twelve cases, and the useful thing about them is that they refuse to correlate with size. A remember me feature storing authentication tokens locally is a substantial modification. Enabling automated control loops that shipped disabled is not. The difference is whether the original risk assessment covered it, not how much code moved.
Is my back end a remote data processing solution works through five architectures. The banking case is the one to read twice, because a single product contains all three possible answers. A self-hosted interface the app talks to directly is a remote data processing solution. The ledger system behind that interface is not, because the app never talks to it. A third-party support chat inside the app is not either, because the bank did not build it, and is treated as a component instead.
When open source falls under the CRA is the largest group, twenty-two examples, and it is close to a decision procedure. Donations that gate releases or security fixes make the supply commercial. Donations that gate nothing do not. Selling a paid edition makes you a manufacturer. Selling consultancy alongside freely available software does not.
A caution worth keeping
The guidance is not binding on economic operators. Only the Court of Justice of the European Union can give an authoritative interpretation of the Regulation, and the guidance says so about itself.
That matters most where the examples are load-bearing for a decision you would struggle to reverse. An example is a strong indication of how a market surveillance authority will read a provision. It is not the provision. Every page in our example set cites the article or annex the example is illustrating, so the underlying obligation is always one click away.
Two further pieces of guidance have been signalled and not yet published, on the interplay between the CRA and the AI Act and between the CRA and DORA. If either lands, expect more examples.
Where to start
If you are working out whether you are in scope at all, start with what counts as a product with digital elements. If you know you are in scope and are trying to size the obligation, how long must my support period be is where the largest and most commonly misjudged number comes from.
If you want to work out your own classification and conformity route rather than read about someone else's, the free CRA classifier takes a few minutes.