Understanding the 13 Essential Cybersecurity Requirements of the Cyber Resilience Act (CRA)

The Cyber Resilience Act (CRA) introduces a groundbreaking shift in how cybersecurity is handled for connected products across the European market. At the heart of this regulation are 13 essential cybersecurity requirements detailed in Annex I. These are not optional checkboxes but binding obligations for all digital products not covered under sector-specific regulations.

Implementation of these requirements must be based on a product-specific risk assessment. This does not mean you can bypass certain requirements altogether. Instead, it provides a mechanism to determine how each requirement applies in proportion to the identified risks. If a particular requirement is deemed unnecessary or only partially fulfilled, this must be clearly justified in the technical documentation. This documentation will be reviewed by regulators, customers, and importers and should withstand scrutiny.

While specific harmonized standards to support compliance have yet to be finalized, some industry standards are likely candidates. For the industrial IoT sector, IEC 62443 provides a strong foundation. ETSI EN 303 645 and ISO/IEC 18031 also offer valuable guidance for IoT and radio-connected devices more generally. However, these do not fully align with the CRA, and there are already discussions that ISO/IEC 18031 might be replaced by a dedicated CRA compliance standard in the future.

Regardless of how soon new standards become available, the essential cybersecurity requirements will come into effect. Starting from 11 December 2027, all new products placed on the European market must comply. Early action is not just advisable, it is necessary. Analyzing the requirements now and planning a compliance roadmap can help avoid costly last minute overhauls and ensure continued market access.

For a deeper dive into other areas of the Cyber Resilience Act, explore our CRA Knowledge Hub for more insights.

Overview of the 13 Essential Cybersecurity Requirements from the CRA

What Each CRA Requirement Means and How to Address It

🔗 (a) No known exploitable vulnerabilities

Cyber Resilience Act regulation text: (a) be made available on the market without known exploitable vulnerabilities;

This means products must not be shipped with publicly known vulnerabilities that have not been mitigated. A known vulnerability refers to a weakness that is documented in public databases or internal trackers and is technically exploitable.

To meet this requirement, manufacturers should implement a vulnerability management process before product release. This includes regularly checking databases such as the Common Vulnerabilities and Exposures (CVE), using static and dynamic application security testing (SAST/DAST), performing dependency scanning for third-party components, and documenting risk acceptance or mitigation actions for each identified issue.

🔗 (b) Secure by default configuration

Cyber Resilience Act regulation text: (b) be made available on the market with a secure by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state;

Products must operate securely out of the box. This means all unnecessary services should be disabled and weak default credentials must be avoided unless explicitly agreed between the manufacturer and business user.

Implementation may include turning off remote access ports, enforcing strong default authentication mechanisms, restricting administrative functions, and disabling debug interfaces. A secure factory reset mechanism should restore all settings and firmware to a known secure state while ensuring that no user data remains.

🔗 (c) Security updates and opt-out

Cyber Resilience Act regulation text: (c) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them;

The product must support patching mechanisms to address security issues after deployment. By default, security updates should be automatically applied within a reasonable timeframe.

To comply, a secure update system should be implemented using cryptographic signing, verification of update integrity, rollback prevention, and logging of update events. Notification systems should alert users to pending updates, and configuration interfaces should allow users to postpone or disable them if needed, depending on risk profile and use case.

🔗 (d) Protection against unauthorized access

Cyber Resilience Act regulation text: (d) ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access;

Products must include access control measures to prevent unauthorized users from interacting with system functions or data. These controls apply to both local and remote access interfaces.

Typical technical measures include enforcing password complexity policies, implementing multi-factor authentication (MFA), role-based access control (RBAC), and session timeout handling. Logs should capture unsuccessful access attempts, and anomaly detection may be used to flag unauthorized activities.

🔗 (e) Confidentiality of data

Cyber Resilience Act regulation text: (e) protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means;

Sensitive data must remain confidential throughout its lifecycle, whether stored locally, processed by the device, or transmitted to external systems.

To implement this, products should use standardized encryption algorithms (e.g. AES-256 for data at rest, TLS for data in transit), apply secure key management, and segregate confidential data from non-critical components. Data access should be strictly controlled and audit logs maintained for access events.

🔗 (f) Integrity of data and functions

Cyber Resilience Act regulation text: (f) protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions;

This requirement addresses two critical areas: the integrity of the system itself and the integrity of the data it handles.

System integrity: On the system side, the product must ensure that firmware, software, and configuration files are protected against unauthorized changes. Secure boot, signed firmware, and runtime verification are typical mechanisms used to ensure that only trusted code is executed and that tampering attempts are detected and reported.

Data integrity: For data integrity, the product must be able to detect manipulation or corruption of configuration values, control commands, measurement data, or user inputs. This requires the use of cryptographic methods such as hashing and digital signatures to secure and verify critical information. To make this reliable and scalable, an infrastructure is needed that can generate, distribute, and verify cryptographic keys, validate signatures, and provide proof of data authenticity across systems or organizational boundaries.

🔗 (g) Data minimization

Cyber Resilience Act regulation text: (g) process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);

Only the minimum necessary data required to perform the intended functionality of the product may be collected or processed. This includes both personal and technical data.

Data flows should be reviewed through privacy impact assessments or data protection by design exercises. Unused telemetry, extensive diagnostics, or background data collection unrelated to the product's function should be removed or made optional. A flexible configuration system for data telemetry can support compliance by allowing extended data collection to be turned on or off based on context, minimizing unnecessary processing while maintaining transparency and control.

🔗 (h) Resilience and availability

Cyber Resilience Act regulation text: (h) protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks;

Even in the face of security incidents or attacks, key product functionalities must remain operational or fail gracefully.

This can be achieved using circuit breakers, retry logic, fallback mechanisms, watchdog timers, and resource limits. Rate limiting, input validation, and network-level filtering help protect against denial-of-service and overload scenarios.

🔗 (i) No harm to connected systems

Cyber Resilience Act regulation text: (i) minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks;

The product must not interfere with or degrade other systems connected in the same environment. It should behave predictably and not consume shared resources disproportionately.

Implementation may involve traffic shaping, limiting broadcast or multicast use, and ensuring compliance with communication protocol specifications. Self-monitoring should be used to detect and prevent disruptive behaviors such as network flooding or resource exhaustion.

🔗 (j) Limited attack surface

Cyber Resilience Act regulation text: (j) be designed, developed and produced to limit attack surfaces, including external interfaces;

Attack surfaces must be minimized by reducing the number of entry points and exposed functionalities. This includes physical ports, wireless interfaces, APIs, and software components.

Techniques to meet this requirement include disabling unused services, hardening system defaults, limiting user privileges, and modularizing software architectures to isolate components. Secure software design and threat modeling help identify and remove unnecessary exposure.

🔗 (k) Mitigation of incident impact

Cyber Resilience Act regulation text: (k) be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques;

Even if an attack gets through, the system should be built in a way that limits the damage and prevents it from affecting the whole product. The idea is to keep problems contained so they cannot spread or take down the entire system.

To do this, different parts of the system can be separated and run in isolated environments using techniques like sandboxing or containerization. Critical functions should only have the minimum access needed, which can be enforced through privilege separation or by running them with restricted permissions. These technical controls help contain the impact of security issues and reduce the risk of losing control over the full system.

🔗 (l) Logging of security-relevant activity

Cyber Resilience Act regulation text: (l) provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user;

Security-relevant actions, such as access attempts or data modifications, must be recorded for monitoring and audit purposes. Users must have the ability to opt out under certain conditions.

Implementation may include structured logging (e.g. JSON logs with timestamps), local log storage with log rotation, and options for remote log streaming. Events such as login attempts, configuration changes, and software updates should be monitored for anomalies.

🔗 (m) Secure deletion and data portability

Cyber Resilience Act regulation text: (m) provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner.

Users must be able to permanently delete all personal data and configuration from the product, and data transfers to other systems must happen securely.

A secure erase function should overwrite storage regions or cryptographically delete keys. Data portability mechanisms should use authenticated and encrypted channels to prevent exposure during transfer.

The CRA Marks a New Era of Mandatory Product Security

The Cyber Resilience Act fundamentally changes the way security must be treated in the design, development, and maintenance of digital products. For the first time, security is not a differentiator or a best effort, it becomes a legal obligation. The essential cybersecurity requirements outlined in Annex I apply to nearly all connected products, regardless of their industry or function, unless already covered by sector specific regulations.

These requirements raise the baseline. Vendors will need to adopt structured processes for vulnerability management, implement technical safeguards that go beyond traditional IT practices, and ensure that security measures are embedded throughout the entire product lifecycle. In many cases, this will require architectural changes, process adaptations, and in some domains, entirely new security capabilities.

Importantly, the regulation is risk based, but not optional. You cannot simply justify noncompliance by citing low risk, instead, you are expected to apply proportionate protections and document them transparently. Once the CRA enters into force, noncompliant products will no longer be allowed on the EU market, with oversight enforced through regulatory reviews, importer controls, and potentially significant penalties.

For manufacturers and suppliers, now is the time to act. Analyzing the 13 essential requirements, identifying technical gaps, and defining a product level compliance roadmap are necessary steps to ensure uninterrupted market access and avoid costly disruptions. The security expectations in Europe are changing permanently, and the CRA sets the tone for future international regulations to follow.

This content piece is one of many unpacking the CRA in detail, find the full overview in our CRA Guide.