Who Becomes the Manufacturer When You Patch
A new dossier with every issue. This one covers what happens when an operator changes a product after it ships, and who ends up holding the Cyber Resilience Act obligations for that change.
A security patch, a disabled feature, a forked build pushed out to other users: each looks like ordinary operational work until Article 22 of the CRA asks who actually made it. Get the wrong answer and an emergency fix hands the operator the full Article 13 and 14 manufacturer obligation set, with no technical file to show for it, before anyone has flagged the shift. Guess wrong the other way, and a needed fix does not happen at all, because nobody wants to become the manufacturer by making it.
This issue’s dossier
Downstream Post-Market Modifications and Break-Glass Agreements sets out when a downstream change to a product becomes a substantial modification under the CRA, and how to allocate the obligations it triggers before an emergency forces the question. It is written for product security, compliance and engineering teams handling post-market fixes on someone else’s product.
Get the dossier free until 1 October at comply.land/dossiers/cra-substantial-modifications-manufacturer-obligations.
Article 22 is where responsibility changes hands. Anyone other than the original manufacturer, importer or distributor who carries out a substantial modification and makes the product available on the market becomes a manufacturer under the CRA, for the part they changed, or for the whole product if the change affects its cybersecurity as a whole. The original manufacturer stays responsible for everything it did not touch, so one product can end up with two obligation-holders.
A four-factor test decides whether a given change counts. It asks whether the change opens new threat vectors or attack scenarios, and whether it changes the likelihood or impact of a known one. A security patch that restores a product’s intended security posture generally fails that test, so nothing transfers. Add new connectivity, or fork a build and hand it to other users, and the test passes.
Article 22 also depends on making the product available on the market. An operator patching a system for its own internal use generally is not doing that, and stays outside Article 22, though other duties may still apply. An integrator or managed-service provider supplying a modified product to a customer usually is doing that. Multi-tenant and managed-service setups, where the modified instance never quite changes hands, sit in an unsettled part of that boundary.
A break-glass agreement is what keeps an emergency response inside the first category on purpose. It fixes in advance which actions are pre-classified as non-substantial, what evidence gets captured the moment a change is made, and how the fix finds its way back into the original manufacturer’s supported build, so the two-obligation-holder problem does not outlive the emergency that created it.
Reporting has its own version of the same question. If the emergency response is to an actively exploited vulnerability, the Article 14 clocks from Issue 1 (the first edition of The CRA Fringe) start running, and the notification has to name a reporting entity. Without a break-glass agreement settled in advance, that is a decision made under a 24-hour deadline, by two parties who may each assume the other is filing it.
The dossier sets out the actions worth taking before that moment arrives, and the questions the CRA’s text does not yet answer, among them where a modified product’s support period is actually shared between the two parties holding it.
Like every dossier in the series, it is neither legal advice nor a conformity determination.
What comes next
Issue 4 will introduce the next dossier. When a break-glass fix ships in your stack, who has agreed in advance that they are the one filing the report?
