Essential Cybersecurity Requirements
Annex I is the CRA baseline for in-scope products with digital elements. Part I describes cybersecurity properties of the product itself. Part II describes the manufacturer's vulnerability-handling process during the support period.
Annex I structure
Annex I has two parts. Part I is about the product. Part II is about the manufacturer's vulnerability-handling process. Article 6 connects them: a product can be placed on the market only when the product meets the applicable Part I requirements and the manufacturer's processes meet Part II.
Part I: product properties
Secure defaults, protected data, controlled access, resilient functions, update capability, activity monitoring, and safe removal of data and settings.
Part II: vulnerability handling
Processes for finding, documenting, remediating, disclosing, and communicating vulnerabilities in the product and its components.
Article 13 still matters, but it is not a third Annex I part. It requires the manufacturer to assess cybersecurity risks and use that assessment when applying the Part I product requirements.
Part I: product cybersecurity properties
Part I starts with the overall product outcome, then lists security properties that apply on the basis of the cybersecurity risk assessment and when applicable. The list is broad because the CRA covers many kinds of software, hardware, components, and remote data processing that support product functions.
Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.
Regulation (EU) 2024/2847, Annex I, Part I, point (1)
A consumer app, an industrial VPN, and a reusable hardware component can face different risks even when a requirement uses the same words. The risk assessment explains how the Part I requirements apply to that product and why a requirement is not applicable if that is the manufacturer's conclusion.
Part I mainly asks whether the product can:
- reach the market without known exploitable vulnerabilities and with a secure default configuration;
- address vulnerabilities through security updates, including automatic updates when they fit the product;
- protect access, confidentiality, integrity, availability, commands, programs, configuration, and processed data;
- limit attack surfaces and reduce the impact of an incident;
- record and monitor relevant security activity with a user opt-out mechanism;
- let users securely remove data and settings, and transfer data securely if transfer is supported.
These are product properties, not one fixed implementation pattern. The same requirement may lead to different technical choices for a consumer device, a professional network product, an SDK, or firmware intended to be integrated into other products.
Part II: vulnerability handling
Part II is about the manufacturer's process. It applies when the product is placed on the market and through the support period. It also covers vulnerabilities in components contained in the product, so component visibility and upstream communication matter.
The manufacturer must identify and document vulnerabilities and components. Annex I expressly includes a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies.
Vulnerabilities must be addressed and remediated without delay in relation to the risks posed to the product. Security updates should be separate from functionality updates when that is technically feasible.
Part II requires a coordinated vulnerability disclosure policy and a contact address for vulnerability reports. Article 13 also requires manufacturers to inform the person or entity maintaining an integrated component when they identify a vulnerability in that component.
Update mechanisms must distribute fixes securely and in a timely manner. When security updates are available, they must be disseminated without delay, normally free of charge, and accompanied by information that helps users act.
Standards and evidence
Harmonised standards can support a presumption of conformity only when the relevant reference is published in the Official Journal of the European Union. Drafts, mappings, and sector standards can still be useful evidence, but they do not replace the product-specific risk assessment required by Article 13.
The Commission's CRA standardisation request M/606 asks the European standardisation organisations for horizontal and vertical standards. The implementation FAQ describes horizontal deliverables for the risk-based product framework, Part I product properties, and Part II vulnerability handling, plus vertical standards for important and critical product categories.
The practical evidence line is simple: technical documentation should connect the product's risk assessment, the selected standards or other technical measures, the implemented product properties, and the vulnerability-handling process. Standards can make that connection easier to assess, but the connection still has to be made for the actual product.
Read prEN 40000-1-4 Public Materials for current public material on the planned generic security requirements standard, and prEN 40000-1-3 Vulnerability Handling for the current vulnerability-handling draft.