Stavenor

Guides

CRA Annex I: The 22 Essential Requirements in Plain Language

Updated 20 September 20264 min read

Annex I is the heart of the Cyber Resilience Act: the security your product must have, and how you must handle vulnerabilities after you ship it. It has two parts — 14 requirements for the product itself, and 8 for vulnerability handling. Twenty-two in total.

How Part I works

Point 1 sets the principle: products with digital elements must be designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks.

Point 2 then lists 13 specific requirements, applied on the basis of your cybersecurity risk assessment under Article 13(2), and where applicable. That qualifier matters: not every requirement fits every product. But deciding that one does not apply is a decision you document in the risk assessment, not a shortcut.

Part I — the product: 14 requirements

# Requirement In plain language
1 Appropriate cybersecurity Security proportionate to the product's risks, built in from design
2(a) No known exploitable vulnerabilities Do not ship with vulnerabilities you know can be exploited
2(b) Secure by default Secure out of the box, with a way to reset to the original state. Tailor-made products for business users may agree otherwise
2(c) Security updates Vulnerabilities must be fixable through updates; where applicable, automatic security updates enabled by default, with a clear opt-out, notification and the option to postpone
2(d) Access control Authentication and access management against unauthorised access, and reporting on possible unauthorised access
2(e) Confidentiality Protect stored, transmitted and processed data, for example by encrypting it at rest and in transit with state-of-the-art mechanisms
2(f) Integrity Protect data, commands, programs and configuration against unauthorised modification, and report corruptions
2(g) Data minimisation Process only the data needed for the intended purpose
2(h) Availability Keep essential and basic functions available, also after an incident, including resilience against denial-of-service attacks
2(i) Impact on others Minimise the harm the product causes to the availability of other devices or networks — the botnet scenario
2(j) Attack surface Limit attack surfaces, including external interfaces
2(k) Exploitation mitigation Reduce the impact of an incident with appropriate exploitation mitigation mechanisms
2(l) Security logging Record and monitor relevant internal activity, with an opt-out for the user
2(m) Secure deletion Let users permanently remove all data and settings, and transfer data securely where it is transferable

Part II — vulnerability handling: 8 requirements

# Requirement In plain language
1 Component inventory Identify and document vulnerabilities and components, including an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies
2 Remediation without delay Fix vulnerabilities without delay, including through security updates; where technically feasible, ship security updates separately from feature updates
3 Testing and review Apply effective and regular security tests and reviews
4 Disclosure of fixed vulnerabilities Once an update is available, publish the description, affected product, impact, severity and remediation guidance; publication may be delayed in duly justified cases until users can patch
5 Disclosure policy Put in place and enforce a coordinated vulnerability disclosure policy
6 Contact address Make it easy to report potential vulnerabilities, including in third-party components, by providing a contact address
7 Secure update distribution Distribute updates securely, so that vulnerabilities are fixed in a timely manner, automatically where applicable
8 Free and prompt updates Disseminate security updates without delay and free of charge, unless otherwise agreed for a tailor-made business product, with advisory messages for users

Three things to know

1. When it applies. Annex I applies from 11 December 2027 (Article 71(2)). Products placed on the market before that date are subject to it only if they are substantially modified afterwards (Article 69(2)) — see products already on the market.

2. Part II lasts as long as the support period. The Commission's guidance (C(2026) 5252, paragraph 210) confirms that vulnerability handling obligations run for the support period — see why five years is not the default.

3. Standards can help. Applying harmonised standards cited in the Official Journal gives a presumption of conformity. Check the Official Journal for current citations before relying on any standard.

Sources

Position as at 20 September 2026. General information, not legal advice.