Part I of Annex I in the Cyber Resilience Act is the technical heart of the regulation: the list of product properties a product with digital elements (PwDE) has to meet before it may be made available on the EU market. In a nutshell: products have to be designed, developed, and produced so that they ensure an appropriate level of cybersecurity. To that end, Annex I Part I defines 13 concrete requirements that spell out what “appropriate” means. What these mean in practice, and for the individual product, is what this article sets out to explain.
Manuel Sandler
The legal text of the CRA is deliberately kept technology-neutral and abstract. After all, it has to cover everything from the smartwatch to the industrial control system. Without interpretation and contextualization, it therefore remains open what a single requirement from the CRA document means for a specific product, and which measures it may call for. At the same time, it is worth keeping in view what manufacturers have in many cases long since implemented, without dedicatedly labeling it as CRA-relevant.
The following attempts to translate all 13 CRA cybersecurity requirements (concerning the properties of products with digital elements) into workable, product-related statements. In doing so, we also draw on the emerging EN 40000 series as the coming tool for making them concrete (already introduced in the previous article on the CRA risk assessment). The CRA legal text names the requirements only in the abstract; the EN 40000 series translates them into concrete technical specifications. To bring the two together, the parts of the 40000 series contain a mapping table in the annex. In DIN EN 40000-1-3:2026-02, for instance, it can be found in Annex ZA. At the same time, the aim is to build the bridge between regulation and practice: an honest inventory of what most manufacturers already have, and where the actual gaps lie.
The basic principle of the CRA: “designed, developed, and produced” in line with cybersecurity requirements
Before the 13 requirements comes the overarching principle from Annex I Part I point (1): PwDE are designed, developed, and produced so that they ensure an appropriate level of cybersecurity in light of the risks.
The three verbs are in no way synonymous. They describe three distinguishable phases of the product creation process, in each of which cybersecurity has to be actively considered. Ultimately, we are talking about the product lifecycle:
- Designed: in the design phase, the architecture decisions are made that define all later cybersecurity needs. This is also where the threat modeling within the risk assessment starts, determining which components and interfaces are worth protecting at all, and against which threats. On this basis, the concrete architecture questions are answered: which interfaces are there? Which hardware base is envisaged? Are security functions such as secure boot or cryptographic acceleration needed, and is the hardware designed for them? These decisions can be corrected afterward only with considerable effort, or not at all.
- Developed: in the development process, the conceptual decisions are implemented. This includes secure coding practices, code reviews from a security standpoint, static and dynamic analyses, as well as an appropriate management of cryptographic keys and certificates. The technical documentation intended for the user also originates here: security notices, configuration instructions, and information on secure operation are new mandatory content for many manufacturers and should therefore be considered as early as development. Cybersecurity belongs woven deep into the process here, not as a final check.
- Produced: the production phase is about secure manufacturing and supply chain: are the components used free of known vulnerabilities? Is the production itself, from loading the software to final inspection, secured against tampering? Are the initial configurations of the delivered products actually secure? And are there sufficient protective measures in production against unauthorized interference? Much of this overlaps with measures manufacturers already know from an existing information security management system (ISMS, for example under ISO 27001) and can reuse here. This aspect is often overlooked in the security discussion, but is explicitly addressed in regulatory terms.
The starting point for all three phases is the CRA risk assessment (from the previous article in our CRA series), specifically together with a clear product definition (item definition): only once it is settled what exactly belongs to the product, which components and interfaces it comprises, and where its boundaries lie, can it be determined which assets are to be protected. On this basis, the risk assessment dictates which requirement is to be implemented concretely in which phase.
Whoever skips this starting point and begins directly with the 13 requirements risks measures that miss the actual risk profile. Or, put in more business terms: avoidable costs arise.
A detailed look at the list of CRA cybersecurity requirements: why does this list look the way it does?
Before we go through the 13 requirements of CRA Annex I one by one, three preliminary remarks are worthwhile, as they make understanding all the following points easier: they show how Part I connects to the manufacturer processes from Part II, that not every requirement applies to every product, and with which tool the implementation can be structured going forward. Whoever has understood these three points no longer reads the 13 requirements as a rigid checklist, but as what they are: a risk-based, interlocking system.
So:
Part I and Part II in Annex I of the CRA mesh with each other. The 13 requirements from Part I describe how the product has to be constituted, at the point of sale and across the entire support period. Part II (more on that also in the fourth article of this series) describes the ongoing processes with which the manufacturer maintains this state throughout the entire product lifecycle. Both are connected, and BSI TR-03183 names the interlocking most clearly at requirement (a): do not ship a product with known, exploitable vulnerabilities. That can only be complied with if one even knows what is inside the product and where vulnerabilities become known. This calls for a functioning vulnerability management. Concretely: whoever keeps no software bill of materials (SBOM, the list of all components contained in the product) and does not continuously reconcile it against vulnerability databases (for example the CVE catalog of publicly known vulnerabilities) cannot, in effect, meet requirement (a), even if they formally claim to. This coupling of product property and manufacturer process is one of the central ideas of the CRA.
Not every requirement applies to every product. The 13 requirements are to be implemented “where applicable.” What applies follows, on the one hand, from the product scope itself, the product definition (item definition): some requirements are simply not applicable if a product does not have certain functions or data at all. On the other hand, the risk assessment determines the depth at which the applicable requirements are to be implemented (see Annex I Part I point (2)). If a requirement drops out for a product, the manufacturer has to justify this in the technical documentation (see Art. 13(4)). Example: requirement (m), secure data deletion by the user, may simply not be applicable in an embedded system without user data. What matters is only this: it has to be explicitly justified, not silently passed over. Market surveillance authorities expect clear statements here.
The EN 40000 series as the coming implementation aid. The legal text says what a product has to achieve, but not how. This is exactly the gap closed by the emerging EN 40000 family of standards (already mentioned in the last article). Especially relevant will be the emerging EN 40000-1-4: a concrete catalog of security requirements, mapped directly onto the CRA requirements. Whoever applies it to their product has a structured tool for justifying the applicability of each requirement, and thereby also meets the documentation obligation from Art. 13(4). What is decisive here is never to work through the catalog blindly: it only unfolds its value in connection with the results of the risk assessment, which dictates which requirements are applicable for the specific product and at what depth. The standards are not yet referenced in the EU Official Journal and therefore establish no presumption of conformity; but as a working basis they are already usable today and will presumably become the first reliable reference for the conformity assessment.
The 13 cybersecurity requirements of the Cyber Resilience Act in detail
Now to the requirements themselves. In the following, they are introduced one by one, from (a) to (m), each following the same pattern:
- What does the requirement demand?
- What does that mean concretely in practice?
- And what have many manufacturers often long since implemented, without knowing it as a CRA topic?
You do not have to know all thirteen by heart; what matters is grasping the principle behind each. Whoever thinks about their own product in parallel will, by the end of this section, already have a first, rough assessment of where they stand.
(a) No known exploitable vulnerabilities at market entry
The product has to be free of vulnerabilities for which known exploits exist when it is placed on the market. That sounds self-evident only until one thinks through the implications.
In practice, meeting requirement (a) rests on two complementary strands. The first is the risk-based path: the risk assessment identifies the relevant vulnerabilities, from which a set of measures is derived and implemented, and before the release it is verified and validated that all envisaged security measures are actually implemented correctly and are active. The second strand runs in parallel: a systematic reconciliation of all contained components, from bought-in building blocks through open-source libraries to self-developed parts, against databases of known vulnerabilities. The technical basis for this is the software bill of materials (SBOM for short), which captures all components and versions; without it, this reconciliation is not possible.
Relevant sources for the CVE check are the National Vulnerability Database (NVD), the European vulnerability database (EUVD, established under Art. 12(2) of the NIS2 Directive), and manufacturer-specific security advisories from the component makers. Products that contain known CVEs with available patches in shipped components violate requirement (a), regardless of whether the vulnerability is exploitable in the specific product context.
Status Quo: (a) No known exploitable vulnerabilities at market entry
What is often already in place in practice
Many companies have already implemented initial security measures, mostly to the best of their knowledge, more rarely following a consistently methodical approach. And there are, as a rule, established procedures for product testing into which the testing of the security measures can be integrated well, instead of building an entirely new process.
What is still missing for CRA compliance
A clean definition of the security measures and the proof of their correct implementation, concretely the formal reference to vulnerability databases, the SBOM basis, and the documentation that the reconciliation took place and with what result.
(b) Secure by default
The factory setting has to be secure, without the user having to actively activate or configure security measures. The classic example is the device that forces the assignment of an individual password at first startup, instead of being shipped with a default password identical for all devices. This is a direct rejection of the model “maximum functionality by default, security optional.”
Concretely: no unnecessarily open ports or activated services beyond the core function; no deactivated security functions in the delivery configuration. In addition, the product has to be resettable to the secure initial state: a full factory reset that removes all user-specific data and configurations.
An often overlooked aspect concerns products that are shipped in several configuration variants, for example for different target markets, regions, or use cases. Here the requirement applies to each individual variant: whichever configuration is set as the default, it has to be secure. It is not enough for one of the possible configurations to meet the requirement while another is shipped with insecure default settings.
The CRA provides an exception for tailor-made products: if manufacturer and business user expressly agree on other terms, the secure default configuration can be departed from (see Annex I Part I point (b)). This would be relevant for industrial cases in which the default configuration of a general product does not fit the specific OT environment.
Status Quo: (b) Secure by Default
What is often already in place in practice
Initial setup wizards that require a password at first startup, or password requirements during initial configuration.
What is still missing for CRA compliance
The systematic check of whether all services and interfaces are actually reduced to what is necessary, and the documentation of what belongs to the factory setting.
(c) Update capability and automatic security updates
Vulnerabilities have to be fixable through security updates. This is the technical precondition for requirement (a) remaining meetable not only at market entry, but across the entire support period.
The CRA specifies two points:
- Automatic security updates should be activated as standard, with a clear, easy-to-use opt-out (that is, the option for the user to deliberately switch off the automatic installation) and the option to temporarily postpone updates; in addition, users should be informed about available updates.
- Security updates should, as far as technically feasible, be provided separately from functional updates (see Annex I Part II point (2)): no one should have to install new functions just to close a vulnerability.
For the industrial and B2B domain, this is especially relevant: automatic updates are often deactivated in production-critical environments, because every software change has to be validated and released. The CRA addresses this: automatic updates do not apply to products for which users would not reasonably expect them, in particular in professional ICT networks and industrial environments in which they could trigger operational disruptions (see Recital 56). Instead, a traceable, documented process for the timely manual installation of available security updates is expected there.
Status Quo: (c) Update capability and automatic security updates
What is often already in place in practice
For connected consumer products with a regular internet connection, auto-update is largely established; many B2B products also bring update mechanisms, but often with deactivated auto-updates and without a clear separation of security and feature updates.
What is still missing for CRA compliance
The opt-out documentation, the separation of security and functional updates, and the notification mechanisms. Added to this is an aspect that goes beyond pure update technology: EN 40000-1-3 (vulnerability handling) requires that cybersecurity issues be handled without undue delay and in an appropriate manner. This presupposes that a manufacturer has defined in advance how it responds to reported vulnerabilities: with which deadlines, in which prioritization, by whom. This forward-looking response planning is new for many companies. (See also our first article on CRA reporting obligations.)
(d) Protection against unauthorized access
The product has to be protected against unauthorized access through appropriate control mechanisms, at least through authentication, identity, or access management systems; unauthorized access attempts have to be detected and reported.
The coming EN 40000 series makes this concrete in verifiable sub-requirements: unique user identification (no shared accounts that make the later attribution of actions impossible), strong password requirements or equivalent mechanisms, multi-factor authentication for privileged access and administrator functions, as well as automatic lockout after a defined number of failed login attempts.
The requirement covers all access paths: not only the primary user interface, but also maintenance interfaces, debug ports, management APIs, and remote access. Maintenance interfaces in particular, created during development and left active in production devices, are a frequent weak point.
Status Quo: (d) Protection against unauthorized access
What is often already in place in practice
Authentication mechanisms in nearly every product.
What is still missing for CRA compliance
The systematic coverage of all access paths (ideally already captured in the risk assessment), the documentation of the authentication requirements, and the detection and reporting of access attempts.
(e) Confidentiality of data
Stored, transmitted, and otherwise processed data have to be protected in their confidentiality. But that does not mean everything is to be encrypted across the board: the requirement applies “on the basis of the risk assessment and where applicable.” So only for the data where the risk justifies it, and to the extent that fits the individual product. The CRA expressly names state-of-the-art encryption as a means (“for instance by encrypting relevant data at rest or in transit”), but not as the only one: alongside it, the regulation text expressly allows “other technical means,” for instance a robust access concept (see Annex I Part I point (e)).
In practice, for data transmission over networks, TLS (Transport Layer Security, the standard protocol that encrypts a connection, such as the “https” in the browser) in a current version is mostly used, at least TLS 1.2, TLS 1.3 recommended. Added to this, where the risk requires it, is the encryption of sensitive data “at rest,” meaning in the stored state on the device, in contrast to data “in transit” during transmission. This typically concerns credentials, cryptographic keys, and personal data. And under no circumstances may access credentials be transmitted in plaintext.
What “state of the art” means is oriented toward recognized cryptographic recommendations: for Germany the BSI TR-02102 (the annually updated BSI catalog of which encryption methods and key lengths are considered secure), at the European level the SOG-IS Agreed Cryptographic Mechanisms.
Frequently overlooked: this requirement applies not only to external communication, but also to the communication between internal components. Microservice architectures whose internal services communicate unencrypted “because it’s on our own network” are the classic example of a gap under (e).
Status Quo: (e) Confidentiality of data
What is often already in place in practice
For classic network and internet communication, TLS is today largely standard. For embedded systems, however, this by no means holds throughout, and the view narrows easily to IP-based connections. Confidentiality, though, concerns every interface over which data flows: Bluetooth too, other radio protocols, local bus or debug interfaces. It is precisely these non-network-based transmission paths that are most often overlooked when it comes to encryption.
What is still missing for CRA compliance
The step actually begins earlier than many think, namely with the classification of the data already in the concept and architecture phase. Which data does the product process at all, and which of them are actually worth protecting (personal or otherwise sensitive)? This classification decides whether and where the requirement applies. If a product processes no such data at all, it may not be applicable in the individual case. Only on this basis do the concrete gaps become visible: the encryption of internal communication, the systematic check of the cryptographic algorithms used for currency, and the encryption of sensitive data “at rest.”
(f) Integrity of data, commands, and configurations
Unauthorized manipulation of data, programs, commands, and configurations has to be prevented and detected. This requirement specifically addresses integrity, one of the three protection dimensions of the CIA triad (see previous articles), applied to all relevant data types. (Confidentiality and availability, the two other dimensions, are not the subject of the requirement at this point; they are treated separately in requirements (e) and (h).)
Concretely, this means:
- cryptographic signatures for software updates: they ensure that an update is unchanged (integrity) and actually originates from the manufacturer (authenticity), so that only genuine, unmanipulated updates are installed. Integrity checking of configuration data (unauthorized changes are detected)
- as well as detection and reporting of manipulations of security-relevant files, databases, or system states.
What matters here is that integrity protection concerns the entire product lifecycle and not just a single moment. It begins in the architecture (where, for instance, it is determined which data have to be tamper-protected at all, and with which mechanisms), continues in the implementation (signature checking, access protection, secure storage), and reaches into ongoing operation (continuous monitoring for manipulations, including reporting). Depending on the phase, different measures come into play.
Often overlooked here is command integrity. In connected systems that receive control commands from external sources, it has to be ensured that these commands arrive unchanged (integrity) and really originate from the legitimate source (authenticity). Both are closely related, but not the same: a command can be technically unchanged and still originate from an attacker. The classic example of this is the replay attack, in which a legitimate, correctly signed command is recorded and later fed in again unchanged. Precisely because the command remains untouched in content, pure integrity protection does not help here; it can be prevented through cryptographic mechanisms such as nonces, timestamps, or challenge-response.
Status Quo: (f) Integrity of data, commands, and configurations
What is often already in place in practice
A first awareness that updates have to be protected against alteration. Often, though, this happens only through simple checksums, which merely detect unintentional transmission errors. They offer no protection against targeted manipulation, because an attacker can simply alter the checksum along with the data. Real cryptographic signatures, which secure integrity and origin, are implemented more rarely than one would expect.
What is still missing for CRA compliance
The switch from simple checksums to real cryptographic signatures for software updates, the integrity protection for configuration data, as well as the detection of manipulations of security-relevant files and system states, including reporting.
(g) Data minimization
The product may only process data that are adequate, relevant, and limited to what is necessary for the respective purpose. This is ultimately the data minimization principle familiar from the GDPR, now a product requirement in the CRA.
In practice:
- telemetry may only comprise what is actually needed for the stated purpose;
- diagnostic data for error analysis are permissible, usage data beyond that without a functional link are not;
- personal data may not be stored longer than necessary for the purpose.
The intersection with the GDPR is relevant, but not identical: the GDPR governs the processing of personal data by the controller, the CRA the data processing by the product itself. A product that collects more data than necessary for its function therefore violates the CRA (regardless of whether the manufacturer meets the GDPR elsewhere).
Status Quo: (g) Data minimization
What is often already in place in practice
Data minimization is not a function one implements, but a deliberate design decision to collect only the data actually needed. Existing telemetry or analytics functions precisely do not count here as fulfillment; on the contrary, they are often the reason why more data accrue than needed. A useful point of connection can be found across industries wherever data catalogs or records of processing activities are already kept in the context of the GDPR. This can be built upon, because it already answers the decisive preliminary question: which data are collected at all, and for what?
What is still missing for CRA compliance
The approach sensibly begins already in the risk assessment, by categorizing the processed data from the outset. Personal and other sensitive data are captured as their own asset worth protecting, which at the same time forms the basis for requirements (e) and (g). Building on that follows the actual work of data minimization: the systematic check of whether the collected data are really necessary for the respective purpose, and the traceable documentation of this decision.
(h) Availability and resilience
Essential functions have to be maintained even after a security incident, including defense and mitigation measures against denial-of-service attacks (see Annex I Part I point (h)). With this, the availability dimension of the CIA triad becomes an explicit product requirement.
In practice, this requires rate limiting on all interfaces abusable for DoS; a graceful degradation, in which the product keeps its core functions under overload or attack, even if additional functions drop out; and beyond that watchdog mechanisms that return the system to a safe state upon crash or malfunction.
For safety-critical applications, industrial control systems, network infrastructure, this carries particular weight. A router that collapses under DDoS and thereby paralyzes the entire network violates (h).
Status Quo: (h) Availability and resilience
What is often already in place in practice
Watchdog mechanisms and automatic restarts are largely standard in embedded systems.
What is still missing for CRA compliance
First of all, the consideration of DoS scenarios in the risk assessment at all, so that availability is deliberately assessed as a goal worth protecting and does not go unnoticed. Building on that follow explicit DoS protection measures at the application level and the assessment of whether rate limiting (the limitation of how many requests a system accepts per time span from one source, in order to prevent overload) is present on all attackable interfaces and dimensioned sufficiently.
(i) Minimizing negative effects on other systems
The product may not, in the event of a compromise, become an attack tool against other devices or networks. In doing so, it should minimize the negative effects of the products themselves or connected devices on the availability of the services provided by other devices or networks (see Annex I Part I point (i)).
The historical motivation is clear: Mirai (the IoT botnet of 2016 that ran large-scale DDoS attacks via hijacked devices) and comparable botnet attacks have shown that poorly secured IoT devices are abused en masse as attack tools against third parties. The CRA makes the avoidance of this external damage effect a product requirement.
Typically, this means the following are needed:
- mechanisms that prevent a compromised device from generating unlimited network traffic against third parties,
- bandwidth limits on outgoing connections,
- monitoring of anomalous communication patterns,
- and automatic isolation upon detected anomalies.
For products with internet access, the restriction to necessary outgoing connections (egress filtering) is a fundamental measure.
Status Quo: (i) Minimizing negative effects on other systems
What is often already in place in practice
Bandwidth limits and rate limiting often exist for performance reasons and meet the requirement along the way.
What is still missing for CRA compliance
The explicit anchoring in the risk assessment. When assessing the damage scenarios, the effects on third parties should be considered from the outset, meaning the question of what damage a compromised product can do to other devices, networks, or users. Building on that follow the assessment from the angle of “what happens upon compromise” and the documentation of the corresponding protective measures.
(j) Minimizing the attack surface
The product is to be designed, developed, and produced so that it offers the smallest possible attack surfaces, including at external interfaces (see Annex I Part I point (j)).
Every external interface, every service, every activated function beyond the core function is a potential attack surface. The principle is called the “principle of least functionality”: the product should only be able to do what it has to do for its purpose, nothing beyond that. This means:
- deactivate unnecessary protocols,
- remove or deactivate unnecessary services,
- block unnecessary interfaces;
- what is unavoidable has to be configured as restrictively as possible and secured against attacks.
The same principle expressly also applies to the interfaces of bought-in COTS components. These often bring interfaces that are not needed at all for the actual product function. If they are not actively deactivated, they easily slip through the cracks in later analyses, even though a danger continues to emanate from them.
Especially relevant for products on general operating systems: a Linux-based IoT device brings numerous services and protocols by default that the product function does not need. Hardening, the systematic deactivation of all components not needed, is not an optional step here, but a direct requirement from (j).
Status Quo: (j) Minimizing the attack surface
What is often already in place in practice
Firewall rules and port configurations.
What is still missing for CRA compliance
The systematic check of all activated services, protocols, and interfaces under the question “what do we really need?”, including the often overlooked interfaces of bought-in COTS components, as well as their documentation. Here too it becomes clear why a clean item definition at the start is so important: only what was fully captured at the outset can later be checked for its necessity at all. What cannot be switched off has to be hardened afterward, meaning specifically secured against attacks, for instance through restrictive configuration, the removal of default access, and the restriction of permissions.
(k) Damage limitation through exploitation mitigation
The product is to be designed, developed, and produced so that the effects of a security incident are reduced through appropriate mechanisms and techniques for mitigating possible exploitation (see Annex I Part I point (k)).
Here the CRA is close to reality and addresses a fundamental truth: no product can be fully immunized. The goal is therefore not only to prevent attacks, but to limit their effects when an attack does succeed.
Requirement (k) follows the principle of layered defense (defense in depth): instead of relying on a single line of protection, several independent protection layers are combined. If one layer is overcome, the ones beneath it continue to prevent an attacker from taking over the entire product. This is the core of this requirement: not to prevent every attack, but to limit its effects when it does succeed.
Typical protection layers for this are:
- Isolation of components (sandboxing): individual functional blocks are sealed off from one another, so that a compromised part cannot access other components or system resources. How this is implemented depends on the product platform. On operating-system-based devices it happens, for instance, through separate, permission-restricted services or access control mechanisms such as SELinux or AppArmor; on microcontrollers through memory partitioning (MPU) or a hardware-backed, trusted execution environment (TEE).
- Memory protection such as ASLR (Address Space Layout Randomization) and stack canaries, which make the exploitation of memory errors harder.
- Least privilege: every component and every service runs only with the minimally necessary permissions, so that a compromise opens up as little room to maneuver as possible.
- Virtualization or containerization as a more far-reaching form of isolation, which confines a compromise to sealed-off areas, provided the product platform supports this.
Status Quo: (k) Damage limitation through exploitation mitigation
What is often already in place in practice
In the classic IT world, memory protection mechanisms such as ASLR are usually already active by default in modern operating systems and compilers. For embedded systems, however, this does not hold automatically. On many small microcontrollers, as are common in the embedded or automotive domain, such protection mechanisms are not available out of the box, but have to be deliberately activated and are in part only enabled by the appropriate hardware. Protection against memory errors is thus an active design decision here, not an automatism.
What is still missing for CRA compliance
The deliberate verification that these mechanisms are actually activated and correctly configured, and the check of whether isolation beyond that is required for the specific risk profile.
(l) Security-relevant logging and monitoring
The product has to provide security-related information through the recording and/or monitoring of relevant internal processes, for instance access to data, services, or functions, and changes to them (see Annex I Part I point (l)).
Important here: users have to be able to deactivate this logging (opt-out).
Security-relevant logging comprises at least:
- authentication and authorization events (successful and failed logins, access attempts to protected resources),
- configuration changes,
- system events with a possible compromise link,
- as well as network communication events for products that actively manage network connections.
Important limitation here: the logs themselves may not contain sensitive data in plaintext. Passwords, keys, or full personal data have no place in logs. Logically so, because logs with sensitive data create new data protection and security risks instead of contributing to security.
Status Quo: (l) Security-relevant logging and monitoring
What is often already in place in practice
Logging is present in most products, often for debugging and support.
What is still missing for CRA compliance
The alignment of the logging with security-relevant events, the check for sensitive data in logs, and the implementation of the opt-out. Frequently, moreover, a practicable way to get at the logging data is missing altogether. In products without an internet connection and without a maintenance interface, as is the case with many electronic devices in everyday life, events are under some circumstances recorded locally, but cannot be read out at all when needed. A logging that no one can inspect when it counts does not fulfill its purpose. Access to the records therefore has to be considered from the start.
(m) Secure and complete data deletion
Users have to be able to delete all data and settings permanently, securely, and easily; a data transfer to other products or systems has to take place securely (see Annex I Part I point (m)).
This becomes relevant with device replacement, resale, and disposal, and in practice it is alarmingly often implemented inadequately. A “factory reset” that only resets the configuration but does not securely overwrite stored data does not meet the requirement. Whoever buys a used device and can read out the previous owner’s data with simple means demonstrates a violation of (m).
For products with flash memory, “secure deletion” is technically non-trivial: simple overwriting does not work reliably because of wear leveling (data automatically migrate to changing memory locations) and bad block management (unusable areas are decommissioned but remain readable). Cryptographic erasure, in which the encryption keys are securely destroyed and the encrypted data thereby become inaccessible, is the practicable alternative for flash-based products.
Status Quo: (m) Secure and complete data deletion
What is often already in place in practice
Factory reset functions are implemented almost everywhere.
What is still missing for CRA compliance
The topic of secure data deletion, and likewise the controlled read-out of data, belongs in the architecture already in the concept phase. If it is not considered there from the outset, it can often only be retrofitted with difficulty later, because it depends on how data are stored and encrypted. Building on that follow the verification that the reset irretrievably removes all sensitive data, and the documentation of the deletion procedure used.
What the CRA cybersecurity requirements add up to, and what follows from it
An honest inventory shows: for product manufacturers who have already implemented security measures, most of the 13 requirements do not sound fundamentally new. That is no coincidence. Ultimately, the CRA merely distills today’s established security best practices into EU-wide legal bindingness. What changes is thus not primarily the what, but the how of the documentation and proof.
The pragmatic approach to CRA preparation is not “start from zero,” but “inventory, map, close gaps.” For most manufacturers, this is less a technical new development than a documentation and gap-analysis task. The basis for everything further is the CRA risk assessment: together with the product scope, it determines which of the 13 requirements are applicable to the specific product at all, and at what depth. Not every requirement applies to every product, and blindly meeting all 13 in particular causes unnecessary effort and avoidable costs. On this basis, the analysis can be approached in four steps:
- Inventory: capture all already existing security measures, technical as well as organizational, including those that today do not count as “CRA-relevant” (such as TLS, update signatures, access concepts, or awareness trainings).
- Map: assign each existing measure to the relevant requirements from Annex I Part I. This makes visible which requirements are already covered, and with which evidence.
- Identify gaps: record, per requirement, what is missing. Usually this is not the measure itself, but its documented, demonstrable link to the requirement.
- Prioritize and close: order the gaps by risk and effort and work through them, document where measures already take effect, retrofit where they are missing, and record a justification for every non-applicable requirement.
Structured this way, a seemingly overwhelming list of 13 requirements turns into a manageable reconciliation task. The gaps that come to light in the process are, in our experience, less a matter of missing technology than of missing evidence, and they recur in similar form across product worlds.
Because such gaps recur structurally and are often overlooked internally, early exchange with security-versed third parties is advisable: it dissolves the tunnel vision and brings the product, the presented requirements from Annex I, and the regulatory objective of the CRA into a consistent line.
- Not every one of the 13 requirements applies to every product. What applies is decided by the product scope and the risk assessment. If one drops out, that has to be justified and documented.
- The CRA says what, not how. The legal text stays abstract. The concrete depth of implementation is steered by the risk assessment; the coming EN 40000 will deliver the technical details later.
- Usually it is not the technology that is missing, but the proof. Most manufacturers have long since implemented much of it (TLS, update signatures, access concepts). What is new is the documented, justified link to the requirements.
- No start without a risk assessment and item definition. Whoever begins directly with the 13 requirements produces measures that miss the actual risk, and thus avoidable costs.
- The path is: inventory, map, close gaps. Not a new development, but a structured reconciliation task. The gap is usually smaller than feared.
- One requirement takes more than a one-time proof: "no known vulnerabilities" (a) works durably only with an ongoing vulnerability handling process, the topic of the fourth article in our CRA series.
- For now, BSI TR-03183 works well as the basis for your risk assessment; later on, EN 40000-1-2 will take over. The two are close in content, so switching later won't mean starting from scratch.
- Key Learnings
With that, the arc comes full circle: the 13 essential requirements from Annex I Part I are not a checklist bureaucracy exercise, but the direct technical consequence of the risk assessment from the second article of our series. Whoever did clean work in the cyber risk assessment finds here the logical continuation, not a list of duties imposed from outside. And whoever systematically maps existing measures against the requirements usually finds: the distance between what is already in place and what the CRA demands is smaller than feared. What is missing is rarely the technical substance, but its documented, justified, and demonstrable link to the requirements.
But: one requirement shows that proof alone is not enough. Requirement (a), not to place a product with known exploitable vulnerabilities on the market, can structurally only be met durably through a functioning vulnerability handling process. How this process is built, from the SBOM through CVE monitoring to the coordinated vulnerability disclosure policy and the secure update distribution mechanisms, we discuss in the fourth article.
