The EU Cyber Resilience Act (CRA) reshapes how manufacturers, importers, and distributors must approach cybersecurity. At the centre of this shift is threat modelling – the structured practice of discovering weaknesses before attackers do. Rather than being a checklist activity, threat modelling is the CRA’s foundational requirement for demonstrating secure-by-design thinking from concept through retirement.

This article distils the threat-modelling workflow presented in the CRACoWi project’s first educational session and turns it into a practical, repeatable blueprint for teams preparing for CRA compliance.

Why the CRA Makes Threat Modelling Mandatory

According to Annex I, manufacturers must perform and document a risk assessment for each Target of Evaluation (TOE). Threat modelling provides the structured inputs, such as attack surfaces, weak points, exposure paths, that this assessment depends on.

The CRA’s emphasis on secure-by-design means organisations must consider security before implementation begins. Threat modelling supports this by:

• Revealing blind spots early,
• Helping teams prioritise the most harmful attack paths,
• Guiding secure configuration and update design, and
• Supporting long-term maintenance as the product evolves.

Because the threat model is meant to live throughout the lifecycle, it must be structured, revisited after changes, and backed by evidence. It is important to note that the CRA does not mandate any specific threat-modelling methodology or tools, and the approaches described here represent one practical way to fulfil the CRA’s risk-assessment obligations. Manufacturers are free to adopt any structured method that allows them to identify threats, evaluate risks, and demonstrate secure by design decision-making. The key requirement is the outcome, not the choice of tooling.

Threat Modelling as a Multi-Level System Analysis

A key strength of the approach presented is the three-level zoom. Each layer exposes different threat categories and prevents tunnel vision.

Level 0: The Black-Box System Context

At this stage, we avoid internals and examine the device as an object inside an ecosystem.

Questions include:

• What systems does it communicate with?
• Which protocols does it use?
• What paths allow interaction from users or attackers?
• What is exposed on the local network or wider internet?

Communication matrices; like those generated via Bunkai; help enumerate real network traffic and supporting infrastructure (DNS, NTP, cloud endpoints). Even ancillary flows must be kept, as seemingly harmless protocols can become attack vectors (e.g., NTP spoofing, DNS poisoning).

Level 0 reveals the external threat surface: open ports, exposed interfaces, unencrypted services, remotely reachable management ports, or impersonable systems (e.g. a backend used without validating its identity). At this stage, the physical interfaces of the device are not taken into consideration.

Level 1: Trust Boundaries and Internal Architecture

Now we look inside:

• What components exist?
• Which services run on the device?
• Where are trust boundaries?
• Who controls each component (manufacturer, device user, cloud provider)?

By correlating communication data with an SBOM (CycloneDX or SPDX) produced by OneKey, we match network flows to specific software components. This allows you to distinguish between services that are truly active on the device and libraries that appear in the SBOM only because they were compiled into the firmware but are not exposed or reachable during operation.

At this point, we:

• Define trust zones (edge, internal, user-controlled, attacker-accessible),
• Mark boundaries where authentication or encryption is required, and
• Extend the communication matrix with service purpose, encryption state, and boundary crossings.

This level ties the environment to the architecture and signals where attackers are most likely to focus.

Level 2: Detailed Processes, Software Versions, and Physical Interfaces

This is the deepest zoom level. At this stage, the device is dissected to reveal:

• Runtime processes
• Interactions between the web server, application logic, storage, and the operating system
• Exact service versions and CVEs
• Physical ports (UART, SD card, JTAG)
• Cryptographic strength (TLS version, cipher suites)
• Hard-coded credentials or misconfigurations found in firmware scans

A port scan (via Bunkai) helps validate which SBOM components are truly active. This avoids inflating risk with dormant libraries that attackers cannot reach.

Once all flows – external and internal – are labelled, each becomes a candidate for STRIDE analysis.

Identifying Threats with STRIDE

STRIDE is used at each level, but the detail increases dramatically as we descend:

S — Spoofing

Impersonation of users, devices, or services (e.g., someone pretending to be the SCADA).

T — Tampering

Changing configs, logs, firmware, or traffic; injecting malicious code.

R — Repudiation

Gaps in logging or auditability, including the absence of non-repudiation mechanisms such as secure logging or validated audit records.

I — Information Disclosure

Exposure via unencrypted HTTP, verbose errors, insecure storage.

D — Denial of Service

Overloading services or distracting operators.

E — Elevation of Privilege

Jumping from user to admin, exploiting weak isolation, or leveraging known CVEs.

Each STRIDE category may generate dozens of possible threats; depth is more important than balancing categories. Attackers only need one unprotected path.

Mapping Threats to Real-World Attacks Using MITRE

To turn abstract threats into concrete attack techniques, MITRE frameworks are used:

MITRE ATT&CK

A comprehensive, technical map of adversarial behaviour (reconnaissance, persistence, exploitation, command and control, etc.).

MITRE EMB3D

A simplified version tailored to IoT/ICS devices. Teams select components (e.g., microprocessor, radio module, web server) and receive a CSV of relevant attack patterns.

Each STRIDE threat is translated into keywords (“cleartext HTTP”, “network sniffing”, “device impersonation”, etc.), which are then matched to ATT&CK techniques. MITRE provides mitigation guidance linked to each technique, which teams can use to inform design decisions and later risk prioritisation.

Moving From Threat Modelling to Risk Assessment

Threat modelling generates an enormous list of issues, often hundreds for modern IoT/ICS systems. The next phase—required by the CRA—is prioritisation.

The CVSS calculator helps break threats down into:

• Likelihood
  (Is the attacker remote? Is privilege required? Is user interaction needed?)
• Impact
  (Does it compromise confidentiality, integrity, or availability?)

From these values, teams derive a severity score, and high-severity threats are addressed first to guide engineering effort efficiently. Evidence gathered earlier (SBOM entries, firmware issues, network captures) strengthens confidence ratings. Peer review is recommended to validate assumptions and catch blind spots.

CVSS scoring can be used to evaluate specific vulnerabilities or well-defined threats, but it is not required by the CRA. Organisations may use CVSS or follow their own risk assessment method, provided it produces clear likelihood, impact, and severity evaluations that meet CRA expectations.

Integrating Threat Modelling into the Device Lifecycle

CRA compliance is not about a one-time paperwork exercise. Threat modelling must be:

• Updated whenever the product changes,
• Kept synchronised with new firmware releases,
• Re-evaluated when new CVEs are published,
• Documented in a way importers, authorities, and notified bodies can trust.

This ongoing evaluation also supports compliance with the CRA’s RA 2 vulnerability-handling requirements, which oblige manufacturers to continually monitor, assess, and address newly identified issues throughout the product’s lifecycle. When done properly, the threat model becomes the backbone of CRA documentation and a long-term quality asset—not just an audit requirement.

And to conclude

Threat modelling under the Cyber Resilience Act is a structured, multi-layered process that gives manufacturers the insight needed to produce truly secure-by-design products. By combining environmental analysis, architectural inspection, firmware analysis, STRIDE classification, and MITRE mapping, teams can uncover weak points early and track them across the device’s entire lifetime.

This approach ensures not only CRA compliance but also a fundamentally more secure and resilient product line—something that benefits manufacturers, regulators, and end users alike.