A useful CRA threat model describes the product and its trust boundaries, identifies assets and entry points, develops credible attack scenarios, links threats to potential consequences and records the controls intended to reduce risk. It should be revisited when product changes create new interfaces, privileges or deployment assumptions.
Threat Modelling Supports the Article 13 Risk Assessment
Article 13 requires a cybersecurity risk assessment based on the intended purpose, reasonably foreseeable use, conditions of use, operational environment and assets to be protected. Threat modelling can support that assessment by describing how an attacker could interact with the product and which architecture paths could lead to security consequences. The CRA does not require manufacturers to use one named threat-modelling framework. The important result is that relevant cybersecurity risks are identified and influence product design and development.
- Use threat modelling as an input to the cybersecurity risk assessment.
- Focus on product-specific attack scenarios.
- Select a method appropriate to the product and engineering process.
- Retain the reasoning behind important threat decisions.
A Threat Model Is Not the Entire Cybersecurity Risk Assessment
Threat modelling and the CRA cybersecurity risk assessment overlap, but they are not necessarily identical records. A threat model commonly focuses on assets, attackers, entry points, trust boundaries and attack paths. Article 13 requires a broader risk assessment that also considers intended purpose, reasonably foreseeable use, conditions of use, operational environment, assets to be protected, expected use duration and applicability of Annex I requirements. A manufacturer can integrate the two processes, but the final risk record should cover the full Article 13 context.
- Threat model: how attacks could occur.
- Risk assessment: broader product risk and legal applicability analysis.
- Connect threat scenarios to risk consequences.
- Ensure the final CRA record covers all Article 13 factors.
Begin With a Clear Product and Architecture Scope
Threat modelling becomes unreliable when the product boundary is unclear. Teams should identify the relevant software, hardware, cloud services, mobile applications, update services and external integrations that form the product or support its cybersecurity functions. Architecture diagrams should show important communication flows and trust boundaries. The model does not need every implementation detail, but it needs enough structure to identify where untrusted input, privileged functions and sensitive assets intersect.
- Define the product boundary.
- Identify major components.
- Identify external services.
- Identify data and command flows.
- Identify important trust boundaries.
Identify Assets and Security Objectives
Assets are the things whose confidentiality, integrity, availability or authorised use matters to the product. They can include user data, credentials, cryptographic keys, configuration, firmware, update metadata, administrative functions, safety-related controls or availability of essential services. For each important asset, the team should define what must be protected. This creates security objectives that can later become product security requirements.
- Identify sensitive information.
- Identify credentials and cryptographic material.
- Identify configuration and control functions.
- Identify essential availability requirements.
- Define the required security property for each asset.
Map Entry Points and Trust Boundaries
Attackers need a way to interact with the product. Entry points can include APIs, network services, wireless interfaces, local ports, file parsers, update mechanisms, authentication endpoints, administrative consoles and integration interfaces. Trust boundaries identify where information moves between actors or components with different levels of trust. Mapping these areas helps teams focus on the paths where authentication, authorisation, validation, encryption or isolation controls are most important.
- Inventory external interfaces.
- Identify unauthenticated entry points.
- Identify privileged interfaces.
- Mark trust boundaries.
- Identify security controls expected at each boundary.
Develop Credible Threat Scenarios
A useful threat scenario is more specific than a generic statement that the product could be hacked. It describes an attacker action, the relevant entry point or weakness, the asset affected and the potential consequence. Examples can include bypassing authentication to gain administrative privilege, tampering with update metadata to install unauthorised software, extracting a credential from insecure storage or exhausting a service to affect an essential function. The scenarios should reflect realistic product use and architecture rather than an unlimited list of hypothetical attacks.
- Describe the attacker action.
- Identify the entry point.
- Identify the asset or function affected.
- Describe the potential security consequence.
- Record relevant assumptions.
Connect Threats to Annex I Outcomes
Threat scenarios become more useful for CRA readiness when they can be connected to the relevant Annex I outcomes. Unauthorised administrative access can inform authentication and access-control requirements. Data interception can inform confidentiality controls. Update tampering can inform integrity and secure-update controls. Denial-of-service scenarios can inform availability and resilience measures. Exposure through unnecessary interfaces can inform attack-surface reduction. This mapping helps demonstrate why particular product security controls were selected.
- Map threats to relevant Annex I security outcomes.
- Identify controls intended to mitigate each important threat.
- Record which product component implements the control.
- Identify how the mitigation will be verified.
Threat Modelling Should Produce Engineering Actions
A threat model that only produces a diagram is of limited value. Important scenarios should create engineering actions such as a new security requirement, architecture change, interface restriction, privilege reduction, component isolation, logging requirement or targeted test. Each action should have an owner and status. When a threat is accepted rather than mitigated, the rationale and residual risk should be recorded in the cybersecurity risk assessment.
- Create concrete security requirements.
- Create architecture changes where needed.
- Assign mitigation owners.
- Define verification.
- Record justified residual risk.
Update the Threat Model When the Product Changes
Threat models can become obsolete as products evolve. New APIs, remote-management features, cloud integrations, authentication methods, third-party components or deployment environments can introduce new attack paths. Product teams should define change triggers that require threat-model review. The review can focus on the changed architecture rather than repeating every analysis from the beginning, but it should determine whether new threats affect the cybersecurity risk assessment or existing security requirements.
- Review new external interfaces.
- Review changed trust boundaries.
- Review new privileged components.
- Review new deployment assumptions.
- Update related requirements and tests.
Retain Threat-Model Evidence
Useful evidence includes architecture scope, assets, trust boundaries, entry points, threat scenarios, mitigations, accepted residual risks and links to security requirements or tests. The model should identify the product version or architecture baseline it describes. This makes the threat model useful not only to developers but also as evidence showing how cybersecurity risks influenced product design under Article 13.
- Product and architecture scope.
- Assets and security objectives.
- Entry points and trust boundaries.
- Threat scenarios.
- Mitigations and residual risk.
- Links to requirements and verification.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.