Risk-Based Cybersecurity for Products with Digital Elements

• 2026-06-02
• 12-minute read

Table of contents

In my last post, I highlighted the rising number of daily vulnerability disclosures. Furthermore, for the vulnerabilities that are actually exploited, the Time-to-Exploit is projected to drop to an hour during 2026. This has been a trend for years, which motivates the EU’s Cyber Resilience Act (CRA): we need to act to build our infrastructure on resilient building blocks. In the context of CRA, these building blocks are called Products with Digital Elements and we need to understand the cybersecurity risks they entail. But what are Products with Digital Elements exactly? And what does risk-based cybersecurity mean?

Products with Digital Elements

In Article 3 of the CRA we can find the following definitions:

(1) ‘product with digital elements’ means a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately;

(2) ‘remote data processing’ means data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions;

The problem with making these definitions tangible is that they are so broad. A product with digital elements (PDE) can be standalone software installed on a computer like an image processing, accounting or specialized engineering application. It can also be a mobile app on a phone like a mobile game or a fitness tracker. It does not need to be standalone software but can be software that is meant to be integrated into other products like a control firmware to be installed onto a Programmable Logic Controller for factory automation applications. A PDE could also be software that is bundled with hardware like the operating system on a gaming console or a configuration app for an enterprise-grade internet switch.

A PDE does not need to be software, it can be a hardware component like a CPU, microcontroller or hard drive. It can also be a finished device like a smartphone or smart refrigerator, but also an Industrial IoT (Internet of Things) system for predictive maintenance of machinery. If the PDE relies on Remote Data Processing Solutions, which include cloud backends for smart doorbells or Industrial IoT systems as well as over-the-air update servers, these are included as well as part of the PDE.

CRA’s Scope

CRA applies to a wide range of PDEs but not to all of them. Article 2 of the CRA sets CRA’s scope, and essentially says that it applies to PDEs that are (1) put on the EU market, and (2) can be expected to be used in a way that includes some form of data connection¹. Some PDEs are excluded, however, and these are mainly PDEs covered by other regulations: medical devices or in vitro diagnostic medical devices, road vehicles, civil aviation, and maritime equipment². All of these domains have different interpretations of quite similar cybersecurity requirements that are often based on or influenced by the IEC 62443 series of standards. The IEC 62443 series of standards is also very influential in the drafting of standards for CRA, but this is not the topic of this blog post.

Other excluded PDEs are those developed or modified exclusively for national security or defence purposes. The bottom line, however, is that if your product contains or is software and provides some means of communication, there is a very high certainty that it is covered by CRA (or similar requirements under another regulation). While CRA might sound like yet another regulation that you need to follow, and it will be a considerable amount of work, the good news is that CRA adapts to your product. This is what risk-based cybersecurity is about as described in the following.

CRA Is Not a Checklist – Risk-Based Cybersecurity

One common, but false, assumption when companies first approach CRA is that it would behave like the cybersecurity requirements of the Radio Equipment Directive (RED)³. When following the EN 18031 series of standards, i.e., the harmonized standards for the cybersecurity requirements of RED, you practically get a list of cybersecurity controls like “[AUM-5] Password strength” that your product needs to implement. In that sense, EN 18031 serves as a checklist. The approach of CRA is fundamentally different.

Instead of providing you with a checklist that might not really suit your product, CRA aims for an “appropriate level of cybersecurity” for the purpose and foreseeable use of your product. What an appropriate level of cybersecurity is, depends on the cybersecurity risks of your product. But what is risk-based cybersecurity?

The current draft of the CRA standard prEN 40000-1-2, describes risk-based cybersecurity as follows:

A risk-based cybersecurity approach for products ensures that cybersecurity measures are based on identified risks and are proportionate to the identified risks, considering magnitude of loss or disruption and the likelihood of occurrence.

It is important to understand that in the context of CRA, “risk” does not refer to the manufacturer’s business risk, but to the risk posed to the user and the environment. This includes, e.g., risks to data confidentiality, the integrity of the product’s functions, and the availability of its provided services. It can also include societal risks, e.g., where a vulnerability in a widely used product could destabilize our infrastructure.

This means, that the CRA does not expect the same rigor in ensuring cybersecurity of a smart lightbulb as it expects of a control system of a city’s power supply. If the risk is low, the required security measures are lightweight, for example, protecting a function with basic password-based authentication. If the risk is critical, the security measures must be robust, such as requiring two separate authorized users to confirm a critical action via multi-factor authentication.

This shift from a checklist to a risk-based approach to cybersecurity transfers the responsibility from the regulator to the manufacturer. You cannot claim compliance by ticking boxes, but need to justify why the level of security you have implemented is appropriate for the risks that your product faces. For certain products (like the smart lightbulb), this can effectively mean less effort than a one-size-fits-all checklist.

The Risk Assessment Process

Cybersecurity risk assessments are the fundamental activity for implementing risk-based cybersecurity. It is important to understand, that this is not a one-time event but a continuous activity that is iterated throughout the lifecycle of the product, including a support period of at least five years. Further, you need to have a good understanding of the product to be assessed including its intended purpose, reasonably foreseeable use, and operational environment.

In general, risk assessment consists of the following elements (this description is aligned with prEN 40000-1-2 and consistent with similar standards):

• Asset and Cybersecurity Objective Identification. Here you identify what you want to protect, i.e., the elements of value to any of your stakeholders of your product. This could be data (at rest or in transit), functionality, hardware or software components, as well as property that needs to be protected (both physical and virtual).
• Threat Modeling. In this step, the product architecture is analyzed by looking at its logical architecture in the form of a Data Flow Graph (DFD). Threats to your product are identified and analyzed based on the identified assets of Step 1.
• Risk Estimation. The likelihood of a threat becoming reality, and the impact, i.e., magnitude of potential loss or disruption, are estimated. Both, likelihood and impact are commonly estimated in qualitative values (very low, low, medium, …) and based on different parameters, respectively. Eventually, risk is determined as Risk = Likelihood x Impact. How each of these is pursued in detail, depends on the specific method used. There can be more or less advanced methods to identify threats, and rate likelihood or impact.

It is easy to get stuck or waste effort in different ways, e.g., by ending up in deep technical discussions that are of limited use for the big picture; identifying more assets, threats and ultimately risks than can reasonably be handled; or lacking technical expertise to find relevant risks that need to be mitigated. In these cases, it is helpful to apply a structured method, and maybe even have an experienced facilitator, in order to stay on track. With that said, risk assessment is not rocket science but it does take time and technical expertise.

The actual risk assessment methods used under CRA are not very established yet, but several candidates exist. I will get back to this in another post but leave it at this overview of what risk-based cybersecurity means for now. Before describing common misunderstandings and summarizing, I want to clarify that not all PDEs are treated the same under the CRA.

Not All PDEs Are Equal: Important and Critical Products

Risk assessments are not the only way that the CRA ensures that the cybersecurity measures implemented for a PDE are proportionate to the risk inherent to its purpose and use. Around 10% of all PDEs are identified to have a higher risk potential and a potential systemic impact to our infrastructure. For these products, the CRA introduces three product classes:

As shown in the table, the class to which a product belongs determines how the PDE’s conformity with the CRA is assessed. The higher the product class, the more rigorous the assessment needs to be. It is important to understand, however, that the requirements for PDEs under the different classes remain the same.

Which products belong to the Important and Critical classes is determined in Commission Implementing Regulation (EU) 2025/2392 and will presumably be updated over time. Currently, Important - Class I products are, e.g., identity management systems, browsers, password managers, boot managers, and 15 more categories of products (19 product categories in total). Important - Class II products are, e.g., hypervisors, firewalls and tamper-resistant microprocessors (4 product categories in total). Critical products are, e.g., smartcards or similar devices, including secure elements (3 product categories in total). Products that are not mentioned in Implementing Regulation (EU) 2025/2392 ANNEX I or II belong to the default or unclassified product class.

Common Misunderstandings

Before summarizing, I want to list a few common misunderstandings I have encountered concerning cybersecurity risk assessments and product classes, so you can avoid them.

Regarding Risk Assessments

• Misunderstanding 1: Product cybersecurity risk assessment is like organizational cybersecurity risk assessment (e.g., according to ISO 27005).
  While these types of assessments are very similar from a process point of view, the product risk assessment is much more technical. The expertise required to perform threat modeling of a product, i.e., the structured process of identifying potential security threats as part of a risk assessment, is often underestimated.
• Misunderstanding 2: Product cybersecurity risk assessment is STRIDE.
  STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), is very commonly used during threat modeling but it only solves a part of the task: the identification of threats. It can help you to determine the likelihood of an attack but this will not tell you anything about its impact. Both, likelihood and impact need to be determined in product cybersecurity risk assessment in order to evaluate a risk (this is actually similar to organizational cybersecurity risk assessment).
• Misunderstanding 3: Risk acceptance criteria are based on the “risk appetite” of the organization.
  Risk appetite is the amount and type of risk an organization is willing to accept in pursuit of its strategic objectives. It can look different for, e.g., a startup or an established enterprise. While risk appetite plays a role in organizational cybersecurity risk assessment, in product cybersecurity risk assessment it does not. Under the CRA, “the product placed on the market needs to ensure an appropriate level of cybersecurity based on the risks”, as stated in the EU Commissions CRA Guidance. It is not influenced by what kind of organization the product is placed on the market.

Regarding Product Classes

There are two common misunderstandings concerning industrial systems, so-called Operational Technology (OT):

• Misunderstanding 4: OT systems are automatically “Important - Class I” because they are used in critical sectors like energy, water, or manufacturing.
  PDEs used in OT systems are treated like any other PDE: if they are not listed in ANNEX I or II of Implementing Regulation (EU) 2025/2392, they belong to the default product class.
• Misunderstanding 5: “Air-gapped” PDEs, meaning PDEs as part of OT systems that are not connected to any outside network, are not covered by CRA.
  Even air-gapped PDEs are covered by CRA just like any other PDE.

Conclusion

To wrap up, understanding the CRA begins with recognizing that almost any product with digital elements and a data connection falls under its scope. The core of the regulation is not a static checklist, but a risk-based approach which requires you to identify your assets, model your threats, and implement security measures that are proportionate to the risks.

While the classification of a product (Default, Important, Critical) determines how you prove compliance, the applicable cybersecurity requirements remain the same. In contrast to previous regulations like the cybersecurity requirements of the Radio Equipment Directive, CRA adapts to the individual product but puts the burden of proof to justify that the chosen level of cybersecurity is “proportionate” on the manufacturer. Therefore, the CRA means a fundamental shift in how the covered products are developed that will be interesting to follow.

Posts in this series

• Risk Management for the Cyber Resilience Act
• Risk-Based Cybersecurity for Products With Digital Elements
• The Cyber Resilience Act: Why It Matters to You