In today’s hyperconnected world, digital elements are embedded in everything from smart home devices to industrial machinery. However, with innovation comes responsibility. The EU Cyber Resilience Act (CRA) is reshaping the landscape by introducing a risk-based approach to cybersecurity, requiring all products with digital components to undergo a thorough cybersecurity risk assessment before hitting the market.
This is a wake-up call for manufacturers, developers, and suppliers to rethink how they design, evaluate, and maintain their products. Whether you are launching a new IoT device or updating legacy software, understanding the cybersecurity risk profile of your product is a legal necessity.
Let us first recap what CRA requires regarding the cyber risk assessment:
- risk assessment is documented and stored as part of the technical documentation (for 10+ years)
- risk assessment is updated as appropriate during the support period (for 5+ years)
- product security context is taken into account during the risk assessment
- essential cybersecurity requirements are considered based on the risk assessment
In practice, this leads to interaction summarised in the following picture:
Let me open this up a bit. Let’s start from the arrow number one. As mentioned above, CRA requires that the product security context is taken into account during the risk assessment. Results of the risk assessment might also affect the assumptions we need to make about the product security context. There may be issues that are best fixed by making assumptions about the operating environment to ensure a sufficient level of security. This is a two-way street – security context definitions such as the intended purpose and foreseeable use and misuse may decrease or increase the risk impact.
For the arrow number two, the arrow from high-level risks to cybersecurity requirements comes directly from CRA. Article 13 paragraph 3 clearly states that cybersecurity risk assessment should indicate how those requirements are implemented as informed by the cybersecurity risk assessment. If the risk level is lower, the implementation of the requirement may be less strict. Naturally, we cannot make informed decisions if we have not considered relevant requirements when creating the risk assessment itself. Therefore, essential requirements also guide what kinds of risks we need to consider.
Arrow number three is possibly the most interesting one. There is a typical misconception that on the product side, risk assessment equals threat modelling. This is not true. Threat modelling is a bit of a misnomer – it does not typically identify threats, but rather weaknesses or vulnerabilities. Threat modelling could identify the usage of a bad encryption algorithm or an unnecessarily open port, for instance. It is very difficult to evaluate magnitude or likelihood for this kind of weaknesses, because a weakness is not a risk in itself. But it may become a risk if it gets exploited by a threat to cause harm to an asset. Therefore, we need to consider both high-level cybersecurity risks and threat models as they serve different purposes, and there needs to be a bidirectional arrow between them.
Threat modelling helps in identifying weaknesses and vulnerabilities, which typically affect the likelihood of risks. Sometimes an identified vulnerability can be so severe that a new risk needs to be created and escalated. High level product cybersecurity risk management needs to be integrated into regular risk management taking place within the information security management system. It can use the same templates, risk evaluation scales and escalation mechanisms, which helps to ensure threat modelling findings get the needed resources. High level risk assessment also supports threat modelling – in areas where risks are bigger, a more thorough threat modelling is needed.
How to do this in practice
If you read carefully between the lines, you may have realised that making all this work smoothly requires
- the possibility to link requirements, cybersecurity risks and security issues identified in threat modelling
- possibility to store snapshots of the risk assessment documentation when new product versions are released
Luckily, both bullet points can easily be solved with the Cyberismo solution and content modules which provide templates, workflows and linking capabilities. The Cyberismo solution also supports the possibility to flexibly add more data types, templates and other configuration as needed. Naturally, there are other tools or their combinations which may also provide similar features.
In any case, the key steps to get started with product cybersecurity risk management and CRA are:
- Document the product security context, including the support period and lifecycle
- Document the assets and the architecture as part of your threat modelling
- Identify and analyse cybersecurity risks
- Evaluate essential cybersecurity requirements in CRA
- Plan the risk treatment and cybersecurity requirement testing as part of your Secure Development Lifecycle (SDL) processes
- Repeat as needed
Read more about the Cyberismo solution and check out the online demo!