Skip to main content

Risk Treatment: Mitigation and Acceptance for Software

You've identified and evaluated the cybersecurity risks for your app, game, or software. Now comes the action part: risk treatment. The Cyber Resilience Act (CRA) expects you to take the outcome of your risk assessment into account to minimize these risks (Article 13, Paragraph 2). For software developers, this usually boils down to a few key strategies.

Treat the Risk​

This is your primary goal for most risks. Mitigation means reducing the likelihood or impact of the risk. For software, this often involves:

  • Fixing the Vulnerability: Patching the code, updating a vulnerable library in your game engine, or reconfiguring a server. This directly addresses Annex I, Part I, point (2a) about shipping without known exploitable vulnerabilities.
  • Adding Security Controls: Implementing stronger authentication for your app, adding input validation to prevent injection attacks, or encrypting data at rest and in transit as per Annex I, Part I, point (2d, 2e).
  • Changing the Design: Maybe a feature in your game is inherently too risky. You might redesign it to be more secure or limit its functionality. This relates to limiting attack surfaces (Annex I, Part I, point (2j)).

Terminate the Risk​

Sometimes, the easiest way to deal with a risk is to eliminate the activity or feature causing it. If a particular third-party library for your app has a terrible security track record and isn't critical, you might choose to remove it entirely and find an alternative or build the feature yourself.

Transfer the Risk (Use with Caution for CRA)​

In some contexts, risk can be transferred, like buying cyber insurance. However, under the CRA, you, the manufacturer, remain responsible for meeting the essential requirements. You can't simply offload your CRA obligations for product security to a third party. Due diligence on components is still your job (Article 13, Paragraph 5).

Tolerate the Risk​

For some very low-likelihood, low-impact risks, you might decide to formally accept them. This means acknowledging the risk exists but deciding that the cost or effort to mitigate it outweighs the potential harm. This should be a conscious, documented decision, especially for any residual risks after mitigation attempts. Make sure your justification is solid, as your risk assessment will be part of your technical documentation.

Key Takeway​

Risk treatment for your software involves actively deciding how to handle each identified risk. Prioritize mitigation by fixing vulnerabilities and implementing security controls to meet CRA requirements. Document all your treatment decisions.