The Cyber Resilience Act (CRA)!
The CRA is coming and it's going to be a dramatic change for technology producers
The Cyber Resilience Act is going to change how people build software, because it imposes requirements that technology makers will need to meet to get the CE mark in late 2026, and getting the CE mark is roughly required to sell in Europe.
The CRA requires many things, including SBOMs, secure defaults, updatability and updates through the life of the project, and also...threat modeling. (The Act calls this “risk management,” and I’ll come back to that.)
As a first concrete example, Annex 1, Part 1, can be read as a set of threats. For example:
“protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means;” (Annex I, Part I, para (e))Threats are violations of a desired property. By leading with “protect,” the CRA does jump to the “do something about it part. But where in your architecture do you do that? Threat modeling helps you ensure that you can identify that ‘stored and transmitted’ data. The “other technical means” verbiage leads to a choice of how you address the threat. That choice is easier when you’ve clearly stated the threat. Information disclosure is just one of the 13 threats listed in Part I of Annex I.
Going back to the CRA as a whole, Annex II, para 5 states:
At minimum, the product with digital elements shall be accompanied by: ...any known or foreseeable circumstance, related to the use of the product with digital elements in accordance with its intended purpose or under conditions of reasonably foreseeable misuse, which may lead to significant cybersecurity risks;At the end of the day, threat modeling will be the technical means by which you systematically discover the foreseeable circumstances and reasonably foreseeable misuse.
The cybersecurity risk assessment shall be documented and updated as appropriate during a support period to be determined in accordance with paragraph 8 of this Article. That cybersecurity risk assessment shall comprise at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, of the product with digital elements, such as the operational environment or the assets to be protected, taking into account the length of time the product is expected to be in use. The cybersecurity risk assessment shall indicate whether and, if so in what manner, the security requirements set out in Part I, point (2), of Annex I are applicable to the relevant product with digital elements and how those requirements are implemented as informed by the cybersecurity risk assessment. It shall also indicate how the manufacturer is to apply Part I, point (1), of Annex I and the vulnerability handling requirements set out in Part II of Annex I.
When placing a product with digital elements on the market, the manufacturer shall include the cybersecurity risk assessment referred to in paragraph 3 of this Article in the technical documentation required pursuant to Article 31 and Annex VII. (Article 13, paras 3, 4)
It seems to me that the first paragraph requires you to diligently threat model, while the bolded text is going to require you to publish that threat model, or a meaningful subset of it. If your documentation is behind a paywall, you can keep the risk assessment behind that same wall. The need for the documentation is emphasized in Annex 7’s paragraph 3.
All of these will be required to sell your product in the EU market. “Failure to comply with the Cyber Resilience Act can result in penalties and sanctions, such as of fine of 15 millions euros or 2.5% of annual turnover, which ever is higher.”
Risk management and threat modeling
The terms are frequently used in very similar ways. Threat modeling is often more focused on the “what can go wrong” question than the “how likely is that to happen” that’s at the heart of risk management, and if you use standard approaches like DFDs and STRIDE, you’ll likely be close to where the requirements end up.
“Risk assessment,” is now a term of art which will be defined in the context of several European laws, including the Product Liability Directive, NIS2 and the CRA (there’s a a good overview from Reed Smith.)
The exact requirements are going to be defined by standards bodies, specifically CEN/CENELEC and ETSI, and so I only want to say nice things about them right now. More seriously, they are going to be subject to a lot of pressure for specificity so people can be confident they’ve done the required work. That specificity will carry three costs. There’s a direct cost to doing the work, and a second cost to ensuring that your documentation is up to snuff. Lastly, there’s an indirect cost of reduced flexibility. On the other hand, if the rules are too flexible, they’ll be subject to second guessing by assessors. So more seriously: I don’t envy the standards bodies.
What should you do?
My general perspective is that technology producers should be threat modeling now. Threat modeling with the Four Question Framework is likely to set you up for success. If it’s not something you’re doing yet, it’s important to start developing muscle now and stop accumulating accidental security debt. If you’re at a large enough organization, you want to be engaged with the standards process. Overarchingly, you should be thinking about a CRA readiness project, and since the CRA is a law, you probably want both legal and technical input shaping the requirements and analyzing your policies and your technical capabilities and delivery. We can help.
The first link refers to the official text, this site has a nicely formatted and broken out version.