IN SHORT
Annex I has two parts. Part I lists the cybersecurity properties a product must have, applied on the basis of a documented risk assessment — for example no known exploitable vulnerabilities at release, secure-by-default configuration, security updates, access control, data protection and a limited attack surface. Part II lists the vulnerability handling processes the manufacturer must run, including a software bill of materials, fixing vulnerabilities without delay, coordinated vulnerability disclosure and free security updates. The manufacturer must handle vulnerabilities for a support period that reflects how long the product is expected to be in use — at least five years, unless the product is expected to be in use for less time.
Where the requirements sit in the text
A product may be made available on the market only if it meets Part I of Annex I (when properly installed, maintained, used and updated) and the manufacturer’s processes meet Part II of Annex I (Article 6). Article 13 then translates this into manufacturers’ obligations: design according to Part I (Article 13(1)), handle vulnerabilities according to Part II for the support period (Article 13(8), first subparagraph).
The risk assessment comes first
What the text requires
Manufacturers must assess the cybersecurity risks of the product and take the outcome into account during planning, design, development, production, delivery and maintenance (Article 13(2)). The assessment must be documented and updated as appropriate during the support period (Article 13(3)). It must at least analyse risks based on the intended purpose, reasonably foreseeable use and conditions of use, and indicate whether and how each security requirement of Part I, point (2), applies and is implemented (Article 13(3)). Where a requirement is not applicable, the technical documentation must contain a clear justification (Article 13(4)).
Our interpretation
Part I, point (2), opens with On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable Annex I, Part I, point 2
. The list is therefore not a one-size-fits-all checklist: each item must be considered, applied in a way proportionate to the risk, or justified as not applicable. Point (1) — an appropriate level of cybersecurity based on the risks — applies to every product (Annex I, Part I, point 1).
Part I — properties of the product
| Point | In short | Provision |
|---|---|---|
| (a) | No known exploitable vulnerabilities when made available | Annex I, Part I, point 2(a) |
| (b) | Secure-by-default configuration, with a reset to original state (exception for agreed tailor-made products for business users) | Annex I, Part I, point 2(b) |
| (c) | Vulnerabilities can be addressed through security updates, where applicable automatic by default with an opt-out, notification and postponement | Annex I, Part I, point 2(c) |
| (d) | Protection from unauthorised access (authentication, identity or access management) and reporting of possible unauthorised access | Annex I, Part I, point 2(d) |
| (e) | Confidentiality of stored, transmitted or processed data, e.g. encryption | Annex I, Part I, point 2(e) |
| (f) | Integrity of data, commands, programs and configuration, and reporting on corruptions | Annex I, Part I, point 2(f) |
| (g) | Data minimisation | Annex I, Part I, point 2(g) |
| (h) | Availability of essential and basic functions, including resilience against denial-of-service attacks | Annex I, Part I, point 2(h) |
| (i) | Minimise negative impact on the availability of other devices or networks | Annex I, Part I, point 2(i) |
| (j) | Limit attack surfaces, including external interfaces | Annex I, Part I, point 2(j) |
| (k) | Reduce the impact of incidents with exploitation mitigation mechanisms | Annex I, Part I, point 2(k) |
| (l) | Security-related logging and monitoring of internal activity, with an opt-out for the user | Annex I, Part I, point 2(l) |
| (m) | Secure and easy removal of all data and settings, and secure transfer where data can be transferred | Annex I, Part I, point 2(m) |
Part II — vulnerability handling by the manufacturer
| Point | In short | Provision |
|---|---|---|
| (1) | Identify and document vulnerabilities and components, including a software bill of materials covering at least top-level dependencies | Annex I, Part II, point 1 |
| (2) | Address and remediate vulnerabilities without delay, including by security updates — separate from functionality updates where technically feasible | Annex I, Part II, point 2 |
| (3) | Effective and regular security tests and reviews | Annex I, Part II, point 3 |
| (4) | Once an update is available, publicly disclose information about fixed vulnerabilities (a delay is possible in duly justified cases) | Annex I, Part II, point 4 |
| (5) | Put in place and enforce a coordinated vulnerability disclosure policy | Annex I, Part II, point 5 |
| (6) | Facilitate sharing of information on vulnerabilities, including a contact address for reporting | Annex I, Part II, point 6 |
| (7) | Mechanisms to securely distribute updates, automatic where applicable for security updates | Annex I, Part II, point 7 |
| (8) | Disseminate security updates without delay and free of charge (unless otherwise agreed for tailor-made business products), with advisory messages | Annex I, Part II, point 8 |
These process requirements are developed in our guides on vulnerability management and the software bill of materials. Separately, Article 14 adds reporting obligations for actively exploited vulnerabilities and severe incidents.
The support period
What the text requires
The manufacturer determines the support period so that it reflects the length of time the product is expected to be in use, taking into account in particular reasonable user expectations, the nature and intended purpose of the product, and relevant Union law on product lifetime (Article 13(8), second subparagraph). Then: Without prejudice to the second subparagraph, the support period shall be at least five years. Article 13(8), third subparagraph
And: Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time. Article 13(8), third subparagraph
Other elements of the rule:
- the manufacturer may also take into account comparable products, the availability of the operating environment, the support periods of key third-party components, and guidance from ADCO and the Commission (Article 13(8), second subparagraph);
- the Commission may set minimum support periods for specific product categories by delegated act (Article 13(8), fourth subparagraph);
- the information used to determine the period goes into the technical documentation (Article 13(8), fifth subparagraph);
- the end date (at least month and year) must be clearly specified 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 issue or for the remainder of the support period, whichever is longer (Article 13(9)).
Our interpretation
Five years is therefore a floor tied to expected use, not a fixed duration: a product expected to be used for ten years would normally need a longer support period, while a product genuinely expected to be used for less than five years can have a shorter one. The reasoning should be documented and defensible to a market surveillance authority.
For software products with successive substantially modified versions, the obligation to remediate vulnerabilities (Part II, point (2)) may be met only for the latest version placed on the market, provided earlier users can obtain it free of charge and without additional costs to adapt their environment (Article 13(10)).
Components and third parties
Manufacturers must exercise due diligence when integrating third-party components, including free and open-source components not made available on the market in the course of a commercial activity (Article 13(5)). When they identify a vulnerability in a component, they must report it to whoever manufactures or maintains that component and remediate it under Part II (Article 13(6)).
Documentation and user information
- Technical documentation must be drawn up before placing on the market, kept up to date at least during the support period, and contain at least the elements of Annex VII, including the risk assessment and the information used to set the support period (Article 31(1), Article 31(2), Annex VII, point 3, Annex VII, point 4).
- Information and instructions to the user listed in Annex II must accompany the product: manufacturer contact details, the single point of contact for vulnerability reports, the intended purpose and security properties, the type of security support and the end date of the support period, instructions for secure use, updates and decommissioning (Annex II, Article 13(18)).
Fictional example — Kestrel Cameras
Kestrel Cameras (fictional) makes an indoor security camera. Its risk assessment concludes that remote access is the main exposure, so it enforces unique credentials and multi-factor login on the companion app (Part I, point (2)(d)), encrypts video streams (point (2)(e)) and closes unused network ports (point (2)(j)). It documents why point (2)(m), data portability, is limited to export of saved clips. Customers typically keep such cameras for about seven years, so Kestrel sets a seven-year support period and prints its end month and year on the box and product page.
Uncertain / awaiting guidance
Harmonised standards and common specifications will give more concrete means of meeting Annex I (see Article 27), and the Commission may specify the format of the software bill of materials (Article 13(24)). Until those exist, manufacturers must rely on the risk assessment and document their choices.
Good practice (recommendation, not a legal requirement)
Build a requirement-by-requirement matrix for each product: for every point of Part I and Part II, record whether it applies, how it is implemented, the evidence (tests, configuration, policies) and, where it does not apply, the justification. The same matrix feeds the technical documentation and the conformity assessment.