CRA risk assessment & threat modeling

Why the risk assessment is the heart of CRA conformity

Regulation (EU) 2024/2847 (the Cyber Resilience Act, CRA) requires a cybersecurity risk assessment for products with digital elements under Art. 13 in conjunction with Annex I. This assessment sits at the centre of the technical documentation: it schematically determines which of the essential Annex I cybersecurity requirements apply to a given product and how they are implemented. The risk assessment forms part of the technical documentation under Annex VII (not Annex II, which covers the information for users) and must be kept for at least ten years after placing on the market, or for the support period if that is longer.

In practice this duty is easily underestimated. Anyone who starts only shortly before placing on the market can hardly retroactively evidence the required traceability "from threat to measure". Threat modeling is an established method to produce exactly this chain in a structured, repeatable and traceable way - ideally anchored in the design phase (security by design).

Threat modeling as a method: DFD, STRIDE, attack trees

The CRA does not prescribe a specific method. Three established building blocks combine well and can be mapped onto the Annex I requirements.

Data-flow diagrams (DFD): the map

First the system is modelled - processes, data stores, external entities and above all the trust boundaries. A DFD shows where data crosses such a boundary (from the internet into the firmware, from the app into the cloud back end). These crossings are where threats arise. The DFD is thus the map on which everything else is located.

STRIDE: not missing a category

Per element and data flow, six threat categories are checked systematically:

• Spoofing → authentication, protection from unauthorised access
• Tampering → integrity
• Repudiation → logging/non-repudiation
• Information disclosure → confidentiality
• Denial of service → availability
• Elevation of privilege → access control

STRIDE helps avoid missing a category and can be mapped onto the protection goals of Annex I, Part I, point 2 (protection from unauthorised access, integrity, confidentiality, availability, limited attack surface). That is why the method suits the CRA evidence: it provides the rationale why a requirement applies - or, with a factual justification, why it does not.

Attack trees: prioritise and justify residual risk

For the most relevant threats, attack paths are decomposed as a tree: attack goal → sub-goals → concrete techniques. This reveals which countermeasure cuts off an entire branch, prioritises effort and provides the documented rationale for deliberate residual-risk decisions.

A worked example: a connected IoT gateway

The approach can be followed on a fictitious but typical product - a Wi-Fi gateway with cloud connection and mobile app.

1. Scoping: define the product boundary (firmware, web configuration UI, cloud API, app), including the update mechanism and support period. The support period reflects the expected use time: at least five years, shorter only where the expected use time is shorter (Article 13(8)).
2. Assets & trust boundaries: assets include device configuration, user data, firmware signing keys. Trust boundaries lie between internet/device, app/cloud and process/data store.
3. Attacker model: an unauthenticated network attacker on the same LAN, a compromised app, and an attacker with physical device access.
4. STRIDE pass (excerpt): the "app → cloud API" flow surfaces spoofing → countermeasure: mutual authentication/tokens. The firmware update surfaces tampering → signed, verified updates. The config UI surfaces elevation of privilege → role separation, no default password.
5. Risk & countermeasures: per threat, assess likelihood × impact, choose a measure, justify the residual risk.
6. Evidence/documentation: the chain threat → risk → chosen Annex I measure → verification is versioned and carried into the technical documentation (Annex VII) - including the software bill of materials (SBOM).

The SBOM belongs in the technical documentation, in a commonly used machine-readable format covering at least the top-level dependencies (Annex I, Part II, point 1). BSI TR-03183-2 (v2.1.0) specifies CycloneDX 1.6 or later or SPDX 3.0.1 or later for this. There is no general obligation to publish it; it must be provided to the market surveillance authority upon a reasoned request (Annex VII, point 8).

From assessment to a traceable chain

The result of good threat modeling is a traceable chain against which a notified body or a market surveillance authority can check the assessment: identified threat → assessed risk → chosen Annex I measure → verification. Whether a notified body must be involved at all depends schematically on the product class: without an entry in Annex III or IV, internal control (Module A) suffices. The same applies to "important" class I products where harmonised standards, common specifications or a European certification scheme at least at assurance level 'substantial' are fully applied, otherwise Module B+C or H. For class II and for "critical" Annex IV products, Module A is excluded (Article 32). For AI products the threat catalogue additionally extends to prompt injection, model extraction and data poisoning - the same method applies here.

Deadlines: why now is the right time

The CRA entered into force on 10 December 2024. The first hard manufacturer duty, the reporting obligations under Art. 14, has applied since 11 September 2026. Full applicability of all product requirements follows on 11 December 2027. Reporting is staged: early warning without undue delay and in any event within 24 hours of becoming aware; notification with the general information available without undue delay and in any event within 72 hours; final report no later than 14 days after a corrective or mitigating measure is available (actively exploited vulnerability) or within one month of the notification (severe incident having an impact on the security of the product). Notifications go simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform under Article 16.

Infringements of Annex I and Art. 13/14 can be fined up to EUR 15 million or 2.5 % of worldwide annual turnover (whichever is higher); other duties carry 10 million / 2 %, and incorrect information to authorities 5 million / 1 %. Article 64 is not among the provisions that apply early and applies from 11 December 2027 (Article 71(2)); the German implementing act (Bundestag printed paper 21/6134), which is to set the authority and fining procedure, had been neither adopted nor promulgated as of 9 October 2026. A sound risk assessment therefore matters economically as well.

What Blackfort does

Blackfort Technology brings the attacker's perspective into the risk assessment. Blackfort Technology is represented in the AI security expert group of the Alliance for Cyber Security through its managing director, who is co-author of the guideline on penetration testing of large language models published there. Together with your developers, we build a threat model of your products from source code, configuration and documentation, with data flows and trust boundaries, assess the threats using STRIDE and carry the result into the Annex VII technical documentation.

Whether and how the CRA applies to a specific product is a case-by-case question - this article is schematic and does not constitute legal advice. A good first step is our applicability check. Further reading: the Cyber Resilience Act at a glance, guidance for smaller manufacturers at CRA for SMEs, and industry-specific aspects at industries. To talk it through: get in touch.