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 is not a checkbox at the end — it is the linchpin of the entire 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 is typically kept for ten years after placing on the market.

In practice this is the most underestimated duty. Anyone who starts only shortly before placing on the market can hardly retroactively evidence the required traceability "from threat to measure". Threat modeling is the established method to produce exactly this chain in a structured, repeatable and audit-proof 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 proven, combinable building blocks have become common practice and map directly onto the Annex I requirements.

Data-flow diagrams (DFD): the map

First the system is modelled — processes, data stores, external entities and, crucially, 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: forcing completeness

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

• Spoofing → requirement authenticity
• Tampering → integrity
• Repudiation → logging/non-repudiation
• Information disclosure → confidentiality
• Denial of service → availability
• Elevation of privilege → access control

STRIDE forces completeness and maps directly onto the essential protection goals of Annex I (authenticity, integrity, confidentiality, availability, minimal attack surface). That is why it suits the CRA evidence so well: 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 follows the expected lifetime; a guideline of at least five years is cited.
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 must be provided machine-readable — in CycloneDX 1.6 or later, or SPDX 3.0.1 or later (cf. BSI TR-03183-2 v2.1.0), at least at the level of the top-level dependencies. It is part of the technical documentation, but there is no general obligation to publish it.

From assessment to a traceable chain

The result of good threat modeling is an audit-proof chain that a notified body or auditor expects: identified threat → assessed risk → chosen Annex I measure → verification. Whether a notified body must be involved at all depends schematically on the product class: most products may self-assess (Module A), while "important" products (Annex III) and "critical" products (Annex IV) trigger stricter conformity routes. For AI products the threat catalogue additionally extends to prompt injection, model extraction and data poisoning — the same methodology carries over here too.

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 — applies from 11 September 2026. Full applicability of all product requirements follows on 11 December 2027. The reporting cascade is staggered: 24 hours early warning, 72 hours full notification — and thereafter different final reports: 14 days after a corrective measure becomes available for actively exploited vulnerabilities, versus one month after the 72-hour notification for severe security incidents. Reporting runs via the ENISA Single Reporting Platform.

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 %. A robust risk assessment is therefore not only technically but economically the most important lever.

What Blackfort does

Blackfort Technology UG (haftungsbeschränkt) brings the attacker's perspective into the risk assessment: drawing on practical penetration-testing and attack-surface expertise (including participation in the ACS AI expert working group and as co-author of a public guideline on penetration testing of LLMs), we model your products with DFD, STRIDE and attack trees and translate the results into the documentable Annex VII chain. The outcome is a threat model that does not merely exist on paper but holds up against real attack paths.

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.