Secure updates
What the Regulation requires
Four requirements, split across the two parts of Annex I:
- vulnerabilities can be addressed through security updates, including, where appropriate, automatic updates enabled by default, with a clear opt-out mechanism and notification of available updates;
- security fixes are provided separately from functional updates where technically feasible;
- secure distribution mechanisms ensure fixes reach users unaltered;
- fixes are distributed without delay and free of charge, accompanied by advisory messages telling users what to do.
The technical mechanism
| Property | Implementation |
|---|---|
| Authenticity | Update package signed, verified by the product before applying |
| Integrity | Hash verified; clean failure if altered |
| Channel confidentiality | Encrypted transport and server authentication |
| Rollback protection | Refuse to install an earlier version, except through an explicit restore procedure |
| Resilience | Recovery after interruption; the product remains functional if the update fails |
| Verifiability | The user can check the installed version and the history |
| Root of trust | Verification key protected, rotation procedure designed and tested |
Key rotation is the most frequently forgotten point. Over a ten-year support period the signing key will have to change. If the mechanism does not allow for it from the design stage, the product becomes unmaintainable.
Automatic updates
Enabled by default where appropriate. That qualifier calls for a documented decision, based on the risk assessment: industrial equipment where an unexpected restart would halt a production line is in a different position from a consumer application.
In every case:
- inform the user that the mechanism exists and what it does;
- provide a clear way to disable it, with information about the consequences;
- provide the ability to defer an update;
- notify available updates where they are not automatic.
These elements must appear in the user notice — see User information.
Separating fixes
This is the requirement with the greatest engineering consequence.
Providing a security fix without functional change requires:
- maintenance branches per supported version line;
- the ability to backport the fix to those branches;
- a numbering scheme that clearly marks a security fix;
- preserved build environments for old branches — over ten years, that means archiving tools, not just code;
- regression tests runnable on those branches.
A continuous-delivery release model with no maintenance branches cannot satisfy this requirement: the customer must then accept functional changes to get the fix. The architectural decision must be taken before the first incident.
Free of charge
Security fixes are free during the support period, except where otherwise agreed for tailor-made products between businesses.
A commercial consequence to work through: a maintenance contract cannot condition access to security fixes. See Turning the support period into commitments.
Advisory messages
Every release is accompanied by a message telling the user what to do. Minimum content: the vulnerabilities fixed, the products and versions concerned, severity, urgency of application, and any manual steps required.
Publishing these in a machine-readable format — CSAF 2.0 — lets your customers process them automatically. It is not expressly required, but it is what large accounts will ask for, and it reduces your own support load.
Embedded and constrained connectivity
Specific constraints, to be handled at design time:
- size of the update package and available bandwidth;
- power: an update interrupted by a power cut must not brick the device — hence dual-partition schemes;
- no user interface: how do you inform and collect an opt-out?
- unreachable deployed estate: how do you reach equipment behind a closed corporate network?
- long hardware life: storage capacity must absorb ten years of fixes.
These constraints remove no requirement. They must be addressed in the risk assessment and reflected in the security environment assumptions communicated to the user.
Evidence to produce
Description of the mechanism in the technical documentation, key management procedure, update test reports — including failure and rollback tests — publication history and advisory messages.