In an increasingly connected digital society, dependence on secure products with a digital component is growing rapidly. To strengthen the resilience of these products, the European Commission introduced the Cyber Resilience Act (CRA). This regulation imposes extensive obligations on manufacturers, distributors and importers of hardware and software.
In our earlier blog, Introduction to the Cyber Resilience Act, we set out the main features of this legislation. In this blog we focus on one specific aspect: the essential security requirements in Annex I to the CRA, which set out the standards that products with digital elements must meet. What does this mean in practice, and how can these requirements be embedded in product development? We explain this using a practical example.
Cybersecurity is no longer optional
The CRA sets a new standard for securing digital products and requires organisations to integrate security throughout the entire product lifecycle. In practice, this means that security is not added afterwards but is an integral part of the product development process from the outset, also referred to as Security by Design. Failure to comply with these cybersecurity requirements, or with the associated obligations relating to risk assessments and conformity procedures (Article 64 of the CRA), may result in substantial fines of up to 15 million euros or 2.5% of global annual turnover in the preceding financial year, whichever is higher. Through this, the EC seeks to ensure that organisations take cybersecurity seriously and no longer treat security as optional.
Example: a smart doorbell
Imagine this: you are developing a smart doorbell with video, audio (detection), a Wi-Fi connection, and an app that lets users see, hear and communicate remotely. A product that processes privacy-sensitive data and is continuously connected to the internet entails significant security risks. To manage such risks in a structured way, manufacturers must comply with the following security requirements:
-
No known vulnerabilities: You must not place products on the market if you know they can be easily hacked. This requires active efforts to systematically test for vulnerabilities before release, for example by updating software components, using dependency scanners and performing penetration tests.
-
Secure configuration by default: The smart doorbell must be configured securely by default. On first use, the user should be required to set a password, and external functions such as live streaming video footage over the internet should be switched off by default unless the user explicitly enables them.
-
Security updates: The product must be designed so that security updates are possible and are installed automatically by default within a reasonable period, unless the user explicitly opts out. For the smart doorbell this means that firmware must be capable of being updated automatically. Users must be informed and updates must be installed by default unless the user actively chooses otherwise.
-
Protection against unauthorised access: Access to the app and the device must be protected through authentication such as multi-factor authentication (MFA). The user session must be secure from login through to logout or automatic logout. Suspicious login attempts must also trigger a warning.
-
Protecting data confidentiality: Video footage, audio recordings and user data must be encrypted in storage and in transit. End-to-end encryption is recommended./p>
-
Protecting data integrity: The smart doorbell must be designed to prevent data, settings, commands or software from being manipulated or changed without detection. It must also be able to detect whether a file or configuration has been altered and report this to the user.
-
Data minimisation: The smart doorbell may collect only the data that are necessary. No unnecessary tracking, profiling or storage of metadata without a clear functional reason.
-
Ensuring availability: The core functionalities of the smart doorbell must remain available in the event of a fault, or recover automatically after a restart. Consider local storage or buffering of video footage if the internet connection drops temporarily.
-
Limiting negative impact on other systems: The doorbell must not overload the network or interfere with other devices, for example by limiting bandwidth use or reducing unnecessary background traffic.
-
Reducing the attack surface: The doorbell must be designed, developed and manufactured so that the attack surface, meaning the points where a hacker can enter the system, is as small as possible. Each external interface, such as Wi-Fi, Bluetooth or an API, must therefore be assessed for risk. Limit open ports to what is strictly necessary and avoid access routes that serve no functional purpose.
-
Limiting the consequences of incidents: The smart doorbell must be designed, developed and manufactured so that if an incident occurs, such as a hack, the damage remains limited. This can be achieved, for example, by implementing fallback mechanisms, logging and automatic resets upon detecting attack signals.
-
Logging and monitoring: The smart doorbell must keep records of who logs in and when, what changes are made, and whether anomalies occur. These logs must be available for audits and forensic investigations.
-
Secure deletion of data: If a user sells or disposes of their smart doorbell, all data must be capable of being permanently erased. Any transfer of data to a new user must be secure and controllable.
More than compliance: building trust
It should be self-evident that a well-designed digital product has security built in, yet in practice we often see it added only afterwards. The Cyber Resilience Act puts an end to this lack of commitment to product security. With Annex I, paragraph 2, sub-points (a) to (m), development teams are not merely encouraged but required to incorporate security from the drawing board onwards, as a structural part of design, development and maintenance. Not as a burden, but as an opportunity to deliver sustainable, reliable and legally compliant products. Those who consciously invest now in a risk-driven development process with built-in security will not only create safer products, but also a stronger competitive advantage.
Do you have questions? We are happy to help!
