The Cyber Resilience Act (Regulation (EU) 2024/2847) makes compliance with essential cybersecurity requirements a condition for placing products with digital elements on the EU market. These requirements are set out in Annex I of the Regulation. Thirteen of them cover the properties of the product, and eight cover how the manufacturer handles vulnerabilities.
The requirements set security objectives that apply to any product with digital elements. They do not prescribe technical solutions. Based on their cybersecurity risk assessment, manufacturers decide which requirements apply to their product and how to implement them, then show compliance in the technical documentation. This article explains each requirement, what it means in practice, and what evidence can demonstrate compliance.
For an overview of the Regulation (scope, product classification, economic operators, timeline and penalties), see our article The Cyber Resilience Act (CRA): a complete guide to the new European cybersecurity framework for digital products.
How to read the essential requirements
Before listing the detailed requirements, Annex I of the CRA sets a general rule: products must be designed, developed and produced to ensure a level of cybersecurity appropriate to the risks, from the design stage and throughout their development and availability on the market.
The detailed requirements in Part I then apply “on the basis of the cybersecurity risk assessment.” A requirement can therefore be deemed not applicable, as long as this choice is justified in the technical documentation. The requirements in Part II apply to the manufacturer throughout the product’s support period.
Part I: Requirements relating to product properties
a) No known exploitable vulnerabilities
The product must be placed on the market without any known exploitable vulnerabilities. This does not mean the product must be completely free of flaws. It means a product cannot be sold while a known vulnerability that can actually be exploited in that product remains unpatched or unmitigated.
In practice, the manufacturer checks the product’s components against public vulnerability databases and runs scans and penetration tests before placing the product on the market. If a known vulnerability cannot be exploited in the product, for example because the affected code is unreachable, the manufacturer explains why in the documentation.
b) Secure by default configuration
The product must be supplied “with a secure by default configuration.” In other words, it must be secure from first use, without the user having to change any settings. This rules out, for example, identical passwords across all devices and non-essential services enabled by default.
The text also requires that the product can be reset to its original state. Only a tailor-made product can be exempted from this requirement, where the manufacturer and the business user agree otherwise. The factory configuration and the reset procedure are described in the technical documentation and in the user instructions.
c) Fixing vulnerabilities through security updates
The product must be designed so that its vulnerabilities can be fixed through security updates. Where relevant, these updates are automatic and enabled by default. Users must then be able to turn them off easily, be notified of available updates, and postpone them temporarily.
The manufacturer describes the chosen update mechanism and the options available to users. The instructions explain how to turn off automatic installation, which is part of the information they must contain.
d) Protection against unauthorised access
The product must have appropriate access control mechanisms, such as authentication and identity and access management systems, and must report any unauthorised access.
Depending on the risks, this may mean a strong password policy, multi-factor authentication for administrative functions, lockout after several failed attempts, and alerts when suspicious access is detected.
e) Protecting data confidentiality
Data that is stored, transmitted or otherwise processed, whether personal or not, must be protected against unauthorised access. Encryption at rest and in transit, using state-of-the-art mechanisms, is the typical example.
The manufacturer identifies the sensitive data processed by the product and documents the protocols and algorithms used, as well as how encryption keys are generated, stored and renewed.
f) Protecting the integrity of data, commands and programs
The product must prevent any unauthorised manipulation of its data, commands, programs and configuration, and must report corruption.
Common measures include firmware signing and verification, secure boot, and integrity checks on incoming messages, along with alerts when tampering is detected.
g) Data minimisation
The product must only process data that is adequate, relevant and limited to what is necessary for its intended purpose. This requirement applies to personal and non-personal data alike.
A map of the data collected, with a justification for each item based on the intended use, can demonstrate compliance. A connected thermostat, for example, does not need its user’s precise location to regulate temperature.
h) Availability of essential functions
Essential and basic functions must remain available, including after an incident, thanks to resilience and mitigation measures, particularly against denial-of-service attacks.
Rate limiting, a degraded operating mode during an attack, and secure restart mechanisms all help. Their effectiveness is verified through load and stress testing.
i) Limited impact on other devices and networks
The product must minimise any negative impact it could have on the availability of services provided by other devices or networks, for example by being used to relay an attack.
The manufacturer analyses how the product behaves if compromised and limits outbound traffic and network-exposed services accordingly.
j) Limiting attack surfaces
The product must be designed, developed and produced to limit exploitable entry points, particularly external interfaces.
This involves listing all ports, services and interfaces, including debug interfaces, disabling those that are not needed, and justifying why the others are kept.
k) Reducing the impact of an incident
The product must include mechanisms and techniques that limit the consequences of a vulnerability being exploited.
Process isolation, the principle of least privilege, memory protections and isolation of critical components ensure that an exploited flaw does not compromise the entire product.
l) Recording and monitoring activity
The product must provide security-related information by recording and monitoring relevant internal activity, including access to or modification of data, services or functions. Users must be able to turn off this mechanism.
The manufacturer defines which events are logged, protects logs against modification, and documents how users can turn off logging.
m) Secure data deletion and transfer
Users must be able to easily, securely and permanently delete all their data and settings. Where this data can be transferred to another product or system, the transfer must be secure.
A full-wipe function whose effectiveness has been verified meets this requirement. The user instructions explain how to use it, particularly when decommissioning the product.
Part II: Vulnerability handling requirements
1) Identify components and vulnerabilities
The manufacturer must identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the product’s top-level dependencies.
Formats such as SPDX or CycloneDX are commonly used for this. The SBOM is updated with each product version. It does not have to be made public: it is provided to the market surveillance authority upon reasoned request.
2) Address and remediate without delay
The manufacturer must address and remediate vulnerabilities without delay, including by providing security updates. Where technically feasible, these updates are provided separately from functionality updates.
A vulnerability triage and prioritisation process, for example based on a severity score such as CVSS, combined with target remediation times and a history of released patches, can demonstrate compliance.
3) Test security regularly
The product must undergo effective and regular security tests and reviews.
The manufacturer sets up a testing plan (code analysis, penetration testing, fuzzing), defines how often tests run, and keeps the related reports in the technical documentation.
4) Disclose fixed vulnerabilities
Once a security update has been released, the manufacturer shares information about the fixed vulnerabilities: a description, the affected products, the impact, the severity, and clear information to help users remediate them. In duly justified cases, publication can be delayed until users have had a chance to apply the patch.
This information usually takes the form of security advisories published on the manufacturer’s website, possibly in a structured format such as the Common Security Advisory Framework (CSAF). An internal procedure sets out the cases in which publication may be delayed.
5) Apply a coordinated vulnerability disclosure policy
The manufacturer must put in place and enforce a coordinated vulnerability disclosure policy. This policy sets out how reported vulnerabilities are received, handled and then made public.
The policy is published on the manufacturer’s website and can be based on recognised standards such as ISO/IEC 29147 and ISO/IEC 30111.
6) Facilitate information sharing
The manufacturer must take steps to make it easier to share information about potential vulnerabilities in its product and in the third-party components it contains, in particular by providing a contact address for reporting.
A dedicated email address or reporting form meets this requirement. The manufacturer also sets up a process for passing vulnerabilities on to the suppliers of the affected components.
7) Distribute updates securely
The manufacturer must provide mechanisms to distribute updates securely, so that vulnerabilities are fixed or mitigated quickly and, where applicable, automatically.
Common solutions include signed updates, an encrypted distribution channel, integrity checks before installation, and a rollback mechanism if an update fails.
8) Release patches without delay and free of charge
Available security patches and updates must be released without delay, along with advisory messages giving users relevant information, including on any action to take. They are free of charge, unless the manufacturer and a business user have agreed otherwise for a tailor-made product.
The manufacturer’s terms and conditions state that security updates are free, and every patch comes with an advisory for users.
Want to assess your products against the CRA’s essential requirements?
At Naaia, we help organisations structure and manage their compliance. Our platform lets you link each essential requirement to your products, document applicability and justifications, and centralise the related evidence, from risk assessment to vulnerability handling.
Move from reactive AI governance to proactive, managed governance..
