Risk Management for the Cyber Resilience Act

• 2026-06-26
• 14-minute read

Table of contents

In my previous blog post, I introduced risk-based cybersecurity and how this represents a fundamental shift in how requirements are applied by the Cyber Resilience Act (CRA) compared to previous regulations. With CRA, it becomes the manufacturer’s responsibility to determine an appropriate level of cybersecurity for their product. Furthermore, the CRA requires manufacturers to perform a cybersecurity risk assessment to do this. This fact is clarified in several places of the regulation, e.g., in Annex I “Essential Cybersecurity Requirements”:

(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.

(2) On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall: […]

The EU Commision’s Frequently Asked Questions further clarify that the CRA does not mandate a specific risk assessment methodology.

The purpose of this post is to explain the role of risk assessment in the broader topic of risk management. To do this, we will break down the end-to-end risk management cycle outlined in the draft “horizontal” standard prEN 40000-1-2 for fulfilling the requirements of the CRA. This cycle covers everything from defining the product context to treating and communicating risks. Finally, we will look at the specific risk assessment methodologies referenced in the standard and discuss how to choose the right approach for your product with digital elements (PDE).

Risk Management

The graph below shows the risk management flow according to prEN 40000-1-2, which applies to all phases of the product lifecycle, including design, development, production and maintenance to ensure an appropriate level of cybersecurity¹.

Product Context

Risk management begins with defining the product context which establishes the intended purpose and reasonably foreseeable use of the targeted product with digital elements (PDE). Roughly speaking, the intended purpose is what the PDE is advertised for, while the reasonably foreseeable use includes uses by end users that are busy, non-technical or distracted. The product context further specifies the PDE’s functions, operational environment, high-level architecture and end users. It is the main input to the risk assessment.

Risk Assessment

Risk assessment is a structured analysis based on the product context that results in a list of evaluated risks. The risk assessment in the context of CRA is much more technical than established risk assessments, e.g., in the context of ISO 27001 for information security. For CRA, the core activity during the risk assessment of a PDE is threat modeling.

Threat Modeling

Threat Modeling is a structured approach to identify threats to the cybersecurity of the PDE. It usually involves drawing data flow diagrams (DFDs) which are a logical representations of the PDE that detail information flows, data storages, different actors, and generally provide an important base for discussions with different stakeholders. While the CRA does not explicitly mention threat modeling, it is an established practice, required in prEN 40000-1-2, and achieving the CRA requirements on risk assessments will be difficult without it.

Referencing Adam Shostack’s Four Question Framework², the aim of threat modeling is to answer the questions of “What are we working on?” and “What can go wrong?” at this point. Threat modeling might involve popular techniques like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) to identify threats. There are other techniques as well, however, and it is important to remember that threat modeling generally is not an exact science. There is a lot more to say about threat modeling but for the purpose of this blog post it is sufficient to understand that the manufacturer at least needs to obtain:

1. a list of assets, i.e., logical or physical entities of the PDE that the manufacturer wants to protect
2. a list of threats to our assets that could be exploited or unintentionally happen, and lead to negative consequences for users of the PDE

Risk Estimation

Once the lists of assets and threats are obtained, Risk Estimation in terms of likelihood that a certain threat is realized, and its impact considering potential loss or disruption needs to be performed. The goal is to achieve rated risks based on these two parameters.

Different techniques can be used to estimate likelihood and impact. The CRA and draft standards leave the choice up to the manufacturer. An example for an established method is the Threat Analysis and Risk Assessment (TARA) that is a requirement in the automotive sector when applying the ISO 21434 standard. TARA is suitable for application in other domains as well, but this is a topic for another post. Other methods are mentioned further below.

Risk estimation is usually a qualitative process, where impact, likelihood and the resulting risk are rated using levels like “Very Low, Low, Medium, High”. Consequently and regardless of the specific method used, the risk level is then typically determined as Risk = Likelihood x Impact by looking up the value in a risk matrix like this one:

At this point, the outcome of the risk assessment is a list of rated risks.

Risk Treatment

During Risk Treatment, acceptance criteria defined by the manufacturer will be applied to each rated risk from the risk assessment. The goal is to determine whether the risk is acceptable or needs to be treated in another way. In the context of CRA, risk treatment is the point of risk management that ensures that the final PDE reaches an appropriate level of cybersecurity based on the identified risks, as required by the regulation.

According to prEN 40000-1-2, risk treatment options are as follows and shall be chosen in a specific order of priority:

1. Risk Avoidance: The most preferred option. This involves modifying the product design or context to eliminate the risk entirely. This could mean removing a legacy protocol, choosing not to integrate a problematic third-party component or utilizing a memory-safe programming language to avoid entire classes of vulnerabilities.
2. Risk Mitigation: This option involves implementing security controls or measures to reduce either the likelihood of a threat occurring or its impact. Most often, the likelihood is reduced and this can be done by technical controls, e.g., introducing encryption, or process measures, e.g., governance of who gets access to the source code.
3. Risk Acceptance: Accepting the risk as-is, provided it aligns with the risk acceptance criteria. It is important to note that the EU Commission’s CRA Guidance clarifies that the risk acceptance criteria cannot be based on a manufacturer’s risk appetite. Under CRA, the acceptance criteria need to ensure an appropriate level of cybersecurity based on the products intended purpose and reasonably foreseeable use. Acceptable does often not mean that the risk is zero but despite mitigation there will be so-called residual risk. For example, even when introducing state-of-the-art encryption, there is a residual risk that data is tampered. Besides acceptable residual risks, this option can also be necessary for inherent risks that cannot be avoided or mitigated without compromising the product’s core functionality.
4. Risk Transfer: The residual risks, even accepted ones, are eventually transferred to the user who operates the PDE. This option acknowledges this fact and ensures that inherent risks (mentioned in 3.) are communicated to the affected stakeholders. Note that this communication-based transfer is different from, e.g., enterprise risk management which can imply buying a cyber insurance or outsourcing. Under CRA, the legal liability cannot be transferred.

It is important to note that risk mitigation often triggers a need for risk reassessment, as new controls may introduce new risks or change existing ones.

Risk Communication, Monitoring and Review

The final stages of the risk management cycle ensure that the results of your analysis are not just documented in a static technical file for the CE mark, but are actively managed and communicated to those affected.

Risk Communication

As mentioned in the previous section, the residual risk is effectively transferred to the stakeholders of the PDE in operations, most commonly the end user. Risk Communication ensures that this transfer of residual risk is transparent and enables the stakeholders to take appropriate actions.

It is not sufficient to simply state that the risk exists, but the communication needs to consider accessibility (e.g., simple language or multi-modal formats), and provide the stakeholder with the necessary information to maintain the PDE’s cybersecurity. Following prEN 40000-1-2, the communication shall include the following points. Of course, they can look very differently for different types of PDEs, but I have added a few examples to make the points clearer:

• Disclosure of residual risks: This can be a description of the circumstances in the product context that could lead to cybersecurity risks. For example, a PDE which can connect to WiFi networks could support legacy WiFi encryption protocols and if the end user activates those, they would need to be clearly informed about the risks.
• Recommended mitigation measures: This can mean detailing how to deploy, integrate and operate the PDE. An example would be a PDE which is a sensitive Windows application which needs to be run from a user account with limited rights for secure operation.
• Context assumptions: If assumptions were made about the context during the risk assessment, they need to be communicated. For an enterprise router, e.g., this could mean the assumption that the PDE is physically protected and only accessible by authorized personnel.
• Expectations: Both expectations put on end users and downstream integrators shall be communicated. For many PDEs, this can, e.g., be the expectation that security updates are regularly installed by the end user.

Risk Monitoring and Review

Cybersecurity is a continuous activity, not a one-time event. The threat landscape evolves, geopolitical events can require a reevaluation of third-parties and new tools can make certain attacks more feasible. Furthermore, new vulnerabilities are discovered daily and might target the PDE’s dependencies. Also what we consider “state of the art” shifts over time.

Risk Monitoring and Review ensures that risk management is a feedback loop that takes these external developments into account. It can trigger updates to the PDE’s context, or even a complete reevaluation of the threat model. The review process can be triggered in several ways, e.g., in regular intervals, when the threat landscape changes (e.g., rising use of AI-based attack automation), the discovery of actively exploited vulnerabilities, or a component of the PDE becoming outdated. It should of course also be triggered when the PDE is modified and receives updated or new functionality.

By maintaining the risk management cycle, manufacturers ensure that the “appropriate cybersecurity” is maintained over the whole life cycle of the PDE from planning to decommissioning.

Which Method Shall I Use?

As mentioned above, the CRA does not mandate a specific method for risk assessment. prEN 40000-1-2 clarifies the high-level flow and requirements for the risk management cycle, as well as risk estimation on the basis of likelihood and impact, but it still leaves the choice of method open. This may be unsatisfactory if you read the horizontal standard for complying with CRA and do not get a complete solution, but makes sense for several reasons.

There is no risk assessment method that fits every product or company, even if the high-level framework discussed above will roughly be the same. Choosing the right method for identifying threats, and estimating impact as well as likelihood depends on the product’s complexity and knowledge about the operational environment. For example, an enterprise router and a smart toy will both have to comply with CRA but their contexts and risk assessments will look very differently. Furthermore, the chosen risk assessment method should match the expertise of the teams that will apply it, and integrate into existing processes. This is to ensure that the method is applied consistently and produces auditable results.

Methods Referred to in prEN 40000-1-2

We need to remember that prEN 40000-1-2 is a draft standard and it will still be revised, but the place and choice of methods that prEN 40000-1-2 refers to is a bit odd to me. The methods are referred to in Clause 6.4.3 “Threat Identification”, and contain comprehensive risk assessment frameworks (where threat identification is one of the steps) as well as supporting techniques like STRIDE:

• TVRA (Threat Vulnerability and Risk Analysis, ETSI TS 102 165-1): A comprehensive framework for Threat, Vulnerability, and Risk Analysis developed by ETSI (the European Telecommunication Standards Institute). It provides a structured method to assess risks with a focus on Information and Communications Technology (ICT) systems. It is used in the telecommunications sector, and to be honest, I find it difficult to see it broadly applied to products with digital elements (PDEs). It is quite complex, light on the impact estimation and heavy on the estimation of likelihood.
• Attack Trees: A supporting technique rather than a full methodology. It visually represents the various paths an attacker can take to compromise an asset, helping to estimate the likelihood of specific attacks. Within software security, authorities like Adam Shostack criticize Attack trees for being too time-consuming to build and maintain. They focus on attackers instead of the system being build, which can easily lead to spending a lot of time on trying to figure out what can go wrong instead of focusing on improving the design. Still, attack trees have their uses, e.g., in visualizing complex attack paths.
• PASTA (Process for Attack Simulation and Threat Analysis): A 7-step, risk-centric framework that aligns business objectives with technical requirements, combining threat modeling with risk analysis. PASTA explicitly incorporates risk management. It requires you to define business impact, calculate risk, and map vulnerabilities to specific threat actors. PASTA aligns well with CRA and prEN 40000-1-2. It is thorough but often seen as heavyweight and more suitable for complex and high-risk applications.
• STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege): Another supporting technique used to identify threats based on the categories that this acronym stands for. It is highly effective for finding threats in data flow diagrams but needs to be embedded in a larger risk assessment method to estimate likelihood and impact.
• Additionally, the standard notes that threat catalogues like “TR JT013097:2026” or comparable sector-specific ones (e.g., MITRE) can be used as input to determine common threats. TR JT013097:2026 is a standardization work item that will presumably be published as TR 40000-1-5 “Cybersecurity requirements for products with digital elements - Threats and Security Objectives” sometime in 2027. While writing this, there is no draft available yet.

As you can see, the draft standard mixes full risk assessment frameworks with threat identification techniques. Attack Trees and STRIDE are often components of a risk assessment method, but not complete methods on their own. They help answer “What can go wrong?” but do not provide the complete process for obtaining risk estimation.

The Answer?

For the scope of this blog post and focusing on the information at hand (the CRA text and prEN 40000-1-2), I can only give a somewhat unsatisfying answer to “Which method shall I use?”: the best approach is to select a method that aligns with your industry’s established practices (like TARA in automotive or TVRA in telecom) while ensuring it satisfies the CRA’s horizontal requirements. The method must be documented, applied consistently across the product lifecycle, and tailored to the specific product context.

According to EU’s own impact assessment, the broad approach of the CRA targets ca. 390 000 companies, the vast majority (approx. 99.6%) being small and medium enterprises (SMEs)³. Especially SMEs will require clear guidance, effective methods and practical tools to implement the CRA. The problem is: when it comes to risk assessments, these methods and tools are still elusive.

Conclusion

The Cyber Resilience Act clarifies what must be achieved, i.e., an appropriate level of cybersecurity based on risk, but leaves the how up to the manufacturer of the product with digital elements. As described in this blog post, prEN 40000-1-2 provides high-level requirements for the risk management cycle. The core of this cycle is the risk assessment method that is for the manufacturer to choose.

The “right” method is the one that the team responsible can execute consistently and with auditable results, but the current landscape of tools and guidance for SMEs remains fragmented. The fundamental principles of identifying assets, estimating likelihood and impact, and treating risks are well established, but the details depend on the product, its context, and the expertise available.

This post laid the groundwork by defining the risk management cycle. As mentioned earlier, some methods are more suited to certain domains than others. In a following post, I will revisit risk assessment methods and review them for their suitability for fulfilling the Cyber Resilience Act with a focus on SMEs or individual teams.

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