Security update

A security update is the correction with which a manufacturer closes a Vulnerability in a product that has already shipped. The Cyber Resilience Act (CRA) uses the term throughout, yet it does not define it in Article 3. What binds is therefore not a definition but the bundle of duties attached to the update.

The load-bearing sentence sits in Annex I, Part II, point (2): manufacturers must address and remediate vulnerabilities in their products without delay, including by providing security updates. The duty starts on placing the product on the market and runs across the whole Support period, which under Article 13(8) is at least five years unless the product is expected to be in use for less.

Three requirements that belong together

Annex I, Part II splits the topic across three points that only make sense read as one:

• point (2): remediate vulnerabilities without delay, including by providing security updates
• point (7): mechanisms to distribute updates securely, so vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically
• point (8): disseminate available security updates without delay and free of charge, with advisory messages on the action users can take

Point (8) is the one contract negotiations most often miss. Free of charge means free of charge: a maintenance agreement may not turn security updates into a paid deliverable. The only departure concerns tailor-made products where the manufacturer and the business user have agreed otherwise.

Separate from functionality updates

Point (2) carries a second clause that governs delivery rather than the fix itself: where technically feasible, new security updates must be provided separately from functionality updates. Recital 57 gives the reason. Users should not be forced to install new features for the sole purpose of receiving the latest security fixes.

For release planning this is the most consequential single line in the annex. Shipping security fixes only inside the next feature release does not satisfy it. What it takes is a maintenance branch per supported version, or a delivery path on which a fix arrives without the rest of the feature set. The qualifier “where technically feasible” is in the text, but the CRA does not say when it bites. Anyone relying on it should record the reasoning in the Technical documentation, which under Annex VII has to describe the chosen technical solutions for the secure distribution of updates anyway.

Automatic installation and opting out

Annex I, Part I, point (2)(c) makes updatability a property of the product. Vulnerabilities must be addressable through security updates, where applicable including automatic ones that are installed within an appropriate timeframe and enabled as a default setting. Three elements are then mandatory: a clear and easy-to-use opt-out mechanism, notification of available updates, and the option to postpone them temporarily.

The words “where applicable” carry weight. Recital 56 names two groups to which the requirements on automatic updates do not apply: products primarily intended to be integrated as components into other products, and products for which users would not reasonably expect them, such as those meant for professional ICT networks and especially for critical and industrial environments where an automatic update could interfere with operations. In both cases the duty to inform users about vulnerabilities and to make security updates available without delay remains untouched.

Where automatic installation is the default, Annex II, point (8)(e) additionally requires instructions on how to turn that particular default off.

Two clocks that are not the same

Article 13(8) and Article 13(9) are routinely confused, although they answer different questions:

• The support period governs how long new security updates have to be produced at all.
• Article 13(9) governs how long an update, once issued, has to remain retrievable: for a minimum of ten years after it was issued, or for the remainder of the support period, whichever is longer.

In practice: a patch released in the final year of a five-year support period must still be downloadable ten years later. Clearing out download directories when support ends breaches Article 13(9), even though the support period itself has expired.

After the update is issued

Shipping the fix is not the end of it. Annex I, Part II, point (4) requires manufacturers, once a security update has been made available, to share and publicly disclose information about the vulnerabilities fixed: a description, information identifying the affected product, the impacts, the severity, and accessible guidance on remediation. In duly justified cases, where they consider the security risks of publication to outweigh the security benefits, they may delay it until users have had the chance to apply the patch.

Users also need to know in advance what to expect. Annex II, point (7) requires the type of technical security support offered by the manufacturer and the end date of the support period during which users can expect vulnerabilities to be handled and security updates to arrive.

Before the product ships

The duty does not begin in the field. Annex I, Part I, point (2)(a) bars making a product available on the market with known exploitable vulnerabilities, where applicable on the basis of the cybersecurity risk assessment, and recital 38 explains that every individual unit should have received all security patches or updates available to address relevant security issues by the time it is placed on the market. A device shipped on a firmware version for which fixes have long been available does not meet the Essential cybersecurity requirements.