Shipping a security update: the capability and the channel

Practical guidance, not legal advice. Annex, article and recital references are drawn from Regulation (EU) 2024/2847. Check them against the official text before you rely on them.

Two requirements describe updates and they are separate on purpose. Annex I Part I(2)(c) is a property of the product: vulnerabilities in it can be addressed through security updates. Annex I Part II(7) is a process you run: mechanisms exist to distribute those updates securely and, where applicable for security updates, automatically.

One is about what the thing you sold can do. The other is about what your company does for the next five years or more. A product can satisfy the first and fail the second badly, and it usually fails quietly, in year three.

The limb that is unconditional

Point (2)(c) requires products to ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them.

The sentence has several limbs and they are not equally qualified. The where applicable sits on the automatic-update limb. The capability itself carries no such qualifier: a product in which vulnerabilities cannot be addressed through security updates cannot meet point (c), whatever the risk assessment says about it.

That has consequences that are decided long before an assessment, in the bill of materials.

• A mask-ROM microcontroller with no rewritable program memory cannot be patched. If it runs anything that parses untrusted input, that is a design decision to revisit rather than a paragraph to write.
• A device with just enough flash for one image and no room for a second cannot do an atomic A/B update. Updating in place means a power cut during the write leaves a brick, so in practice the field update either does not happen or happens rarely and nervously.
• An appliance whose only update path is an engineer with a laptop and a cable can technically be updated. Whether it will be, across a fleet, at the pace vulnerabilities appear, is a different question, and the adoption numbers will answer it for you.

Work out the flash arithmetic before the board is finalised. A product that runs out of room to hold the patched image has failed this requirement in a way no amount of documentation fixes.

Where the automatic-update limb does not apply

This is the part teams either miss entirely or over-claim, so it is worth being exact.

Recital 46 recognises that automatic installation of security updates can be inappropriate where it would disrupt operation, and the standard cases are professional and industrial installations. A machine controller in a production line, where the operator schedules maintenance windows and an unscheduled restart is itself the hazard, is the example everyone reaches for because it is the clearest. A safety-relevant system where a restart has to be coordinated with a physical process is the same argument.

What the test is not: that your customers prefer to be in control, or that enterprise change management exists. Those are reasons to design notification and staging carefully. On their own they are a weaker argument than an operator-scheduled maintenance window on a machine that moves.

And here is the part that gets lost. Where the automatic limb does not apply, the rest of the point still does. The product must still be updateable. And where updates are installed by an operator rather than pushed, you still have to describe how that operator learns an update exists, because notification of available updates is its own limb. A silent update server that an integrator is expected to poll voluntarily is not a notification mechanism.

Article 13(3) is what lets you record a documented non-applicability determination for a Part I(2) requirement. In this case you are usually not disapplying the point; you are disapplying one limb of it, and the file should say which limb, for which deployment, and why. Write it at the granularity of the limb, because an assessor reading not applicable against the whole of point (c) will ask how the product gets patched at all.

The opt-out, the notification and the postpone option

Three consumer-facing behaviours that are easy to build badly.

Clear and easy-to-use is the standard for the opt-out, and a toggle three levels into a menu called Advanced is not that. It is also worth being clear internally about what an opt-out changes: it changes whether the user receives your update automatically. It changes nothing about your Part II obligations to produce the update, disclose the vulnerability and distribute the fix.

Notification should say what version, what it fixes, and how urgent it is. That is the same information as the advisory message required by Annex I Part II(8), and the sensible design generates both from one source rather than writing the advisory twice.

Postpone means temporarily. If your postpone has no end, you have built a second opt-out and labelled it something else. Decide the maximum deferral, say what happens when it is reached, and make that behaviour visible before the user chooses it.

Part II(7): making the channel trustworthy

Point (7) asks you to provide for mechanisms to securely distribute updates so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner. Almost all of the engineering behind that sentence is signing.

Sign the artefact, not the transport

TLS to your distribution host protects the download in flight. It does not protect against a compromised host, a mirror, a caching proxy inside a customer's network, or an engineer sideloading an image from a USB stick because the site was down. The signature has to be on the update itself and it has to be verified on the device, before installation, against a key that the update path cannot overwrite.

Write down where the root of trust lives and what happens if the signing key is compromised. If the honest answer today is that the key sits on a build server, record that as a risk with a plan rather than describing it as key management. Moving it into a hardware security module, with an auditable list of who can invoke it, is usually a week of work and it is the single most valuable week available in this whole area.

Rollback protection

A common and quiet gap. An attacker who can serve an old but genuinely signed image can move a device back to a version with a vulnerability you already fixed, and every signature check passes. The fix is a monotonic version counter enforced by the device: refuse anything with a security version lower than the one currently installed, and store that counter somewhere an attacker cannot reset.

This is also the point that complicates the reset-to-original-state duty in point (2)(b), which is worth deciding once and documenting in both places.

Installing without bricking

Verify the whole artefact before writing any of it. Write to the inactive slot, switch atomically, and boot with a fallback that returns to the previous slot if the new image does not come up. Keep a measured brick rate from your own testing, because it is the number a customer will ask for and the number that decides whether you dare push a fix on a Friday.

The Update Framework and its automotive profile Uptane describe this problem thoroughly and are worth reading if you are designing an update system from scratch. Neither is required by the CRA and neither gives any presumption of conformity. No CRA harmonised standard has been cited in the Official Journal as of August 2026, so nothing does. Verify the current position before relying on it.

The update has to still be there in year nine

Article 13(9) requires each security update you issue to remain available for at least ten years after it was issued, or for the remainder of the support period, whichever is longer. That turns your distribution infrastructure into a long-term commitment, and it is one of the few CRA obligations with a direct hosting bill attached.

The practical consequence is architectural. An update mechanism that depends on a service you might sunset, a bucket in an account nobody owns, or a signing certificate that expires in three years with no renewal path, will fail this obligation long before anyone notices.

Timely, and appropriate timeframe

Neither phrase is defined, which means the useful move is to define them yourself and then be measured against your own number. Publish an internal target: critical severity fixed and distributed within so many days of a fix being available, high within so many more. Then measure and keep the measurements.

A written target you occasionally miss, with an explanation for each miss, is stronger evidence than no target at all. It shows the process exists. An assessment with no timeframe anywhere in it invites the assessor to supply their own.

One adjacent requirement that shapes your release train

Annex I Part II(2) says that where technically feasible, new security updates shall be provided separately from functionality updates. It is a different requirement from these two, and it is the reason a security fix should not be trapped behind a quarterly feature release or a customer's reluctance to accept new functionality. If your build system cannot produce a patch release from a maintenance branch, that is the constraint to fix, and fixing it improves your answer to all three points at once.

What an assessor will expect

• The update architecture end to end: what is signed, what verifies it, where the key lives, who can use it, and what happens on failure.
• Test evidence that an unsigned image, a tampered image and a downgraded image are all refused. Three separate tests, because they fail differently.
• Fleet adoption figures. What percentage of units are on the current version at seven, thirty and ninety days after release. This is the number that answers whether the fix actually reached anyone, and very few technical files contain it.
• The recorded reason for any limb of point (2)(c) you treated as not applicable, at limb granularity, with the deployment it applies to.
• Your published timeframe target and the measurement against it.
• The arrangement that keeps issued updates available for the Article 13(9) retention period, naming who owns the infrastructure.

The support period article covers how long the clock in Article 13(8) actually runs, and why five years is a floor rather than an answer. The two decisions are connected: the support period is how long you owe updates, and this article is about whether you can deliver them.