Explanation
Start from the risk assessment
What the text requires
When placing a product on the market, manufacturers must ensure it has been designed, developed and produced in accordance with Part I of Annex I (Article 13(1)). To do so, they must assess the cybersecurity risks associated with the product and take the outcome into account in planning, design, development, production, delivery and maintenance (Article 13(2)). The assessment must be documented, updated as appropriate during the support period, and must indicate whether and how each security requirement of Part I, point (2), of Annex I applies (Article 13(3)).
The risk assessment is the hinge of the regulation: many requirements of Annex I apply On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable Annex I, Part I, point 2
. A requirement that does not apply to a product must be justified in the technical documentation (Article 13(4)).
Part I of Annex I: properties of the product
The first requirement sets the principle: products must ensure an appropriate level of cybersecurity based on the risks Annex I, Part I, point 1
. Point (2) then lists the expected properties. In summary, and where applicable on the basis of the risk assessment, products must:
| Point | Requirement (summary — read the official text) |
|---|---|
| (a) | be made available without known exploitable vulnerabilities |
| (b) | have a secure by default configuration, including the possibility to reset to the original state |
| (c) | allow vulnerabilities to be addressed through security updates, including automatic updates where applicable |
| (d) | protect from unauthorised access (authentication, identity or access management) |
| (e), (f) | protect the confidentiality and integrity of data, commands, programs and configuration |
| (g) | process only data that are necessary for the intended purpose (data minimisation) |
| (h), (i) | protect the availability of essential functions and limit the impact on other devices and networks |
| (j), (k) | limit attack surfaces and reduce the impact of incidents through exploitation mitigation |
| (l) | record and monitor relevant internal activity, with an opt-out for the user |
| (m) | allow users to securely remove all data and settings |
See Annex I, Part I, point 2 for the exact wording of each point.
Part II of Annex I: vulnerability handling
Part II addresses the manufacturer's processes rather than the product. Manufacturers must, among other things:
- identify and document vulnerabilities and components, including by drawing up a software bill of materials
in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products Annex I, Part II, point 1
; - address and remediate vulnerabilities without delay, including by providing security updates, separately from functionality updates where technically feasible (Annex I, Part II, point 2);
- test and review the security of the product regularly (Annex I, Part II, point 3);
- share and publicly disclose information about fixed vulnerabilities once a security update is available — publication may be delayed in duly justified cases until users have been able to apply the patch (Annex I, Part II, point 4);
- put in place and enforce a coordinated vulnerability disclosure policy and provide a contact address for reporting vulnerabilities (Annex I, Part II, point 5, Annex I, Part II, point 6);
- distribute updates securely and, unless otherwise agreed with a business user for a tailor-made product, free of charge with advisory messages (Annex I, Part II, point 7, Annex I, Part II, point 8).
Components matter: manufacturers must exercise due diligence when integrating third-party components, including free and open-source components (Article 13(5)), and report vulnerabilities they find in a component to whoever manufactures or maintains it (Article 13(6)).
The support period
What the text requires
Manufacturers must ensure that vulnerabilities are handled in accordance with Part II of Annex I when the product is placed on the market and for the support period (Article 13(8), first subparagraph). The support period must reflect the length of time the product is expected to be in use, taking into account reasonable user expectations, the nature of the product and relevant Union law (Article 13(8), second subparagraph). Without prejudice to that rule, the support period shall be at least five years Article 13(8), third subparagraph
; where the product is expected to be in use for less than five years, the support period corresponds to the expected use time (Article 13(8), third subparagraph).
The support period is therefore not a fixed five years: it can be longer (when the product is expected to be used longer) or shorter (when the expected use time is shorter than five years). Related rules:
- the information used to determine the support period goes into the technical documentation (Article 13(8), fifth subparagraph);
- the end date of the support period, at least month and year, must be specified clearly at the time of purchase (Article 13(19), first subparagraph);
- each security update made available during the support period must remain available for at least 10 years after it has been issued or for the remainder of the support period, whichever is longer (Article 13(9)).
Information, documentation and contact
- Information to users: products must be accompanied by the information and instructions of Annex II, in a language easily understood by users and market surveillance authorities (Article 13(18)).
- Single point of contact: users must be able to report vulnerabilities and communicate directly; the contact must not be limited to automated tools (Article 13(17)).
- Technical documentation: drawn up before placing on the market (Article 13(12), first subparagraph), containing at least the elements of Annex VII (Article 31(1)) and kept, with the EU declaration of conformity, for at least 10 years or for the support period, whichever is longer (Article 13(13)).
- Corrective action: a manufacturer that knows or has reason to believe a product or its processes are not in conformity must immediately take corrective measures, or withdraw or recall the product (Article 13(21)).
Practical case
Fictional example — Brightwave sets its support periods
Brightwave Networks, a fictional manufacturer, sells two products.
- A home router. Brightwave's market data and customer surveys show that customers keep this type of router for about seven years. Brightwave sets a seven-year support period, records the reasoning in the technical documentation and prints "Security support until 06/2034" on the packaging and the product page.
- A disposable data logger designed for a single 18-month shipping campaign. Its expected use time is shorter than five years, so the support period corresponds to that expected use time. Brightwave documents why 18 months reflects the expected use.
In both cases the risk assessment explains which points of Part I, point (2), of Annex I apply. For the data logger, for example, Brightwave justifies in the documentation why a given point does not apply, if that is the conclusion of the assessment.
Exercise
EXERCISE — SET THE SUPPORT PERIOD
For each fictional product, state what Article 13(8) requires for the support period and what must be documented.
- A smart lock expected to be in use for ten years.
- A promotional connected badge expected to be used for three years.
- An industrial controller that the manufacturer would like to support for "five years, because that is the rule", although customers use it for twelve years.
Show a suggested answer
- The support period must reflect the expected use time — here about ten years (and at least five years).
- Expected use is shorter than five years, so the support period corresponds to the expected use time: three years.
- Five years would not reflect the length of time the product is expected to be in use. Five years is a minimum (subject to the shorter-use rule), not a default. The manufacturer must set a period that reflects the expected use, document the information taken into account in the technical documentation and state the end date at the time of purchase.
Key takeaways
KEY TAKEAWAYS
- The documented cybersecurity risk assessment drives how the Annex I requirements apply to a product.
- Annex I, Part I covers product properties; Part II covers vulnerability handling, including a software bill of materials covering at least top-level dependencies.
- The support period reflects the expected use time: at least five years, unless the product is expected to be used for less.
- Security updates must remain available for at least 10 years after issue or for the rest of the support period, whichever is longer.
- Products need Annex II information, a single point of contact and technical documentation kept for at least 10 years or the support period, whichever is longer.