Threat Modeling
Threat modeling is a structured technique for identifying, prioritising, and mitigating security threats to a system during its design phase by systematically analysing what could go wrong, who might cause it, and what the impact would be. It is the foundational practice that enables manufacturers to meet the CRA's requirement for risk-informed, secure-by-design product development.
Threat modeling is a structured technique for identifying, prioritising, and mitigating security threats to a system during its design phase by systematically analysing what could go wrong, who might cause it, and what the impact would be. It is the foundational practice that enables manufacturers to meet the CRA's requirement for risk-informed, secure-by-design product development.
Technical SecurityWhat Is Threat Modeling?
Threat modeling is a systematic process for identifying security threats to a product or system, evaluating their likelihood and impact, and determining appropriate mitigations - conducted during the design phase rather than after development is complete. A threat model typically defines: what is being built (assets, architecture, data flows); what can go wrong (threats, using frameworks like STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege); how likely each threat is to be exploited; and what controls reduce the risk to an acceptable level. The output is a structured document that guides security decisions throughout development.
Why Threat Modeling Matters Under the CRA
The CRA's requirement in Article 13(1) that manufacturers undertake a cybersecurity risk assessment and incorporate its findings into product design effectively mandates a threat modeling discipline, even if the term is not used explicitly. Threat modeling is the design-phase embodiment of this obligation: it ensures that security decisions are made based on a structured understanding of threats rather than assumptions or experience alone. For conformity assessment purposes - particularly for Important Class I and II products - a documented threat model provides the most credible evidence that the manufacturer applied a systematic, risk-based approach to security design as required by Annex I.
How Manufacturers Conduct Threat Modeling
Effective threat modeling follows a repeatable process. The most common methodology for connected products is STRIDE, applied to Data Flow Diagrams (DFDs) that map all system components, data flows, and trust boundaries. Manufacturers should: (1) create accurate architecture and DFD documentation for the product; (2) identify trust boundaries - every interface between components of different privilege levels; (3) apply STRIDE to each data flow and component systematically; (4) rate each identified threat using CVSS or DREAD scoring; (5) identify existing and planned mitigations; (6) document accepted residual risks with justification; and (7) update the threat model whenever the architecture changes materially. Threat models should be version-controlled alongside the product codebase.
Common Mistakes
The most common threat modeling mistake is creating the threat model as a compliance document after the product architecture is finalised, rather than as an input to architecture decisions. At that point, major architectural changes are costly and the threat model effectively documents risks that cannot be economically mitigated, generating accepted risk entries that weaken the compliance position. A second error is scoping the threat model only to the device itself, omitting the cloud backend, mobile application, update server, and manufacturing/provisioning environment - all of which are part of the product's attack surface and must be included for a complete CRA-compliant assessment.
CVD Portal makes Threat Modeling compliance straightforward.
Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Receiving and tracking reports is free for all manufacturers placing products with digital elements on the EU market. Article 14 filing with the SRP-ready package is on Pro.
Start your free portalFrequently asked
Is threat modeling explicitly required by the EU Cyber Resilience Act?+
The CRA does not use the term 'threat modeling' explicitly, but Article 13(1) requires manufacturers to undertake a cybersecurity risk assessment and incorporate its findings into product design and development. Threat modeling is the industry-standard methodology for performing this type of design-phase risk assessment. Conformity assessment bodies evaluating Important Class products will expect to see evidence of systematic design-phase threat analysis, and a threat model document is the most widely recognised form of this evidence.
Which threat modeling methodology is best for CRA compliance?+
No single methodology is mandated by the CRA. STRIDE is the most widely used and understood method for connected products and maps well to the Annex I essential requirements. PASTA (Process for Attack Simulation and Threat Analysis) is preferred for risk-quantification-heavy assessments. LINDDUN is appropriate for products with significant privacy implications. Manufacturers should choose a methodology appropriate to their product complexity and document their chosen approach consistently. Using a recognised, documented methodology strengthens the presumption of conformity.
How often should a threat model be updated?+
A threat model should be treated as a living document, not a one-time deliverable. It should be updated whenever: significant new features or components are added to the product; the network architecture or integration points change; a new CVE reveals a threat category that was not previously modelled; or a security incident reveals an incorrect threat assessment. At minimum, the threat model should be reviewed annually and re-evaluated with each major product version release.
Related terms
Sector checklists covering Threat Modeling
Browse the full CRA Compliance Checklist
See how Threat Modeling fits into your complete CRA compliance programme.