A practical guide to distinguishing cybersecurity risk assessment, threat modelling, risk management and TARA when developing connected products.
Start with the terms
Connected-product teams often use risk assessment, threat model, threat analysis and TARA as though they mean the same thing. They overlap, but they answer different questions and may be used differently across sectors.
A cyber threat is a potentially harmful circumstance, event or action. A vulnerability is a weakness, susceptibility or flaw that can be exploited by a cyber threat. A cybersecurity risk concerns potential loss or disruption and combines the magnitude of that potential loss or disruption with the likelihood of the relevant incident. A list of threats is therefore not, on its own, a completed risk assessment. The definitions used by the Cyber Resilience Act draw on the Cybersecurity Act.
A threat model is a structured representation used to identify security and privacy concerns. It can document system boundaries, assets, data flows, interfaces, attack vectors and possible threats. Methods vary: recognised approaches include STRIDE, PASTA, LINDDUN and attack trees, and OWASP does not prescribe one official method.
A cybersecurity risk assessment takes product context and identified concerns further. It evaluates the risks associated with a product and supports decisions about the applicable requirements and appropriate treatment.
Risk management is wider still. ISO 31000 describes it as a process that includes identifying, analysing, evaluating, treating, monitoring and communicating risk. It is guidance rather than a certifiable standard.
TARA, or Threat Analysis and Risk Assessment, is the named automotive approach used in ISO/SAE 21434. It is a recognised method for road-vehicle electrical and electronic systems, rather than a general legal label that the Cyber Resilience Act requires manufacturers to use.
What the Cyber Resilience Act requires
The Cyber Resilience Act requires manufacturers to carry out a cybersecurity risk assessment for products with digital elements. Under Article 13, the assessment must be documented, used across planning, design, development, production, delivery and maintenance, and updated as appropriate during the support period.
The assessment must take account of the product's intended purpose, reasonably foreseeable use, conditions of use, operational environment, assets requiring protection and expected use time. Its outcome must help determine which applicable essential cybersecurity requirements in Annex I apply to the product, and the assessment forms part of the technical documentation.
The Regulation sets the required context, evidence and outcomes. It does not prescribe one named method, require TARA, mandate threat modelling, or impose a fixed number of assessment steps. A team can select a method suited to its product, provided that its assessment demonstrates coverage of the applicable legal requirements.
| Term | Useful meaning in practice | Cyber Resilience Act position |
|---|---|---|
| Threat | A potentially harmful circumstance, event or action | A threat is distinct from the resulting risk |
| Vulnerability | A weakness, susceptibility or flaw that a cyber threat can exploit | Distinct from both a threat and the resulting risk |
| Threat model | A structured way to identify and describe security concerns | May be useful evidence, but no single method is mandated |
| Cybersecurity risk assessment | Product-specific assessment of cybersecurity risks and relevant requirements | Required under Article 13 |
| Risk management | The wider cycle of assessment, treatment, monitoring and communication | Supports sustained management of the assessment outcome |
| TARA | A defined automotive threat-analysis and risk-assessment approach | Not required by the Regulation |
Using threat modelling within a wider assessment
Threat modelling is often a valuable input to a wider cybersecurity risk assessment. It gives the team a disciplined way to understand the product and identify meaningful threat scenarios before deciding what treatment is needed.
For industrial automation and control system products, IEC 62443-4-1:2018 provides a secure product development lifecycle framework. Its SR-2 product threat-model process includes relevant elements such as trust boundaries, processes, data stores, external entities, protocols, ports, attack vectors, threats, mitigations and external dependencies.
That is a substantial engineering activity, but a threat model alone does not automatically demonstrate that every Cyber Resilience Act requirement has been addressed. The manufacturer still needs product-specific evidence of its assessment, its decisions about applicable requirements and its continuing management through the support period.
Method boundaries also vary. Some organisations describe threat modelling as an input to risk assessment; others use a method that combines threat identification and risk analysis more tightly. What matters is that the chosen approach is clear, repeatable and capable of producing the evidence required for the product.
TARA in the automotive context
ISO/SAE 21434:2021 addresses cybersecurity risk management for road-vehicle electrical and electronic systems. Clause 15 sets out modular TARA activities covering:
- asset identification;
- threat-scenario identification;
- impact rating;
- attack-path analysis;
- attack-feasibility rating;
- risk-value determination; and
- risk-treatment decisions.
The terminology matters. ISO/SAE 21434 determines risk value from impact and attack feasibility. Attack feasibility should not simply be relabelled as occurrence probability: the standard uses its own assessment concept and terms.
Its treatment options include avoiding, reducing, sharing and retaining risk. These are familiar risk-management choices, but the TARA method is specifically scoped to the automotive domain. Outside that scope, teams may still draw on comparable logic, but their documentation should identify the method actually used and avoid implying that ISO/SAE 21434 applies to a product when it does not.
Safety and cybersecurity are connected but different
The Machinery Regulation requires machinery risk assessment and risk reduction. It also addresses protection against corruption and the safety and reliability of control systems. These provisions can make cybersecurity analysis relevant to machinery, particularly where a compromise could affect control behaviour or safety functions.
However, safety and cybersecurity analyses ask different questions:
| Area | Central question | Typical focus |
|---|---|---|
| Machinery safety risk assessment | What hazards could harm people, and how should risk be reduced? | Safety-related hazards and risk reduction |
| Cybersecurity risk assessment | What cybersecurity risks arise from the product and its use, and how should they be managed? | Threat scenarios, protected assets, product context and cybersecurity treatment |
They should inform one another where a cybersecurity event could create or worsen a safety hazard. They should not be collapsed into a single label that obscures either set of requirements.
For products subject to both regimes, Article 13(4) of the Cyber Resilience Act allows the cybersecurity risk assessment to form part of a risk assessment required by other Union law. This can support an integrated evidence set, but it does not remove the need to show how each applicable legal requirement has been covered. Whether one document or linked documents are used, the safety and cybersecurity reasoning should remain traceable.
A practical product assessment workflow
A useful workflow can be tailored to the product and the chosen method without presenting it as the only route to compliance.
Define the product context and assets
Describe the intended purpose, reasonably foreseeable use, operating conditions, deployment environment and expected use time. Identify the assets requiring protection, such as software, configuration, credentials, communications, safety-relevant functions, service interfaces and data.
This provides the product-specific context required by Article 13. It also gives engineering teams a shared basis for deciding which interfaces and dependencies need attention.
Identify threat scenarios
Use the selected threat-modelling or assessment method to identify credible scenarios affecting the assets and their security properties. Record the system boundary, relevant interfaces, external dependencies and assumptions. A scenario should make clear what is targeted, how compromise could arise and what could be affected.
The goal is not to generate an abstract catalogue of every possible cyber event. It is to create a product-specific, reviewable account of the concerns relevant to the product's use and environment.
Evaluate risks using the selected method
Apply the criteria defined for the product and method. This may include impact and likelihood, or, in an automotive TARA, impact and attack feasibility. Do not treat these measures as interchangeable merely because they play related roles in assessing risk.
The assessment should explain the scale used, the assumptions made, the evidence considered and the criteria for accepting or escalating a risk. That makes later review and updating possible.
Select and trace treatment decisions
For each material risk, decide whether to avoid, reduce, share or retain it where those options are appropriate to the method and organisation's criteria. Record the chosen treatment, the resulting requirements or controls, the responsible role and the evidence that implementation has been checked.
For a Cyber Resilience Act product, trace the outcome to the applicable Annex I requirements. This helps show how the assessment informs design and lifecycle activity rather than becoming a document created only at the end of development.
Keep the assessment current
The assessment should remain part of product lifecycle management. Article 13 requires it to be updated as appropriate during the support period. Changes to the product, interfaces, dependencies, operating environment, known vulnerabilities or intended use may require the team to revisit assumptions, scenarios and treatment decisions.
The position of FprEN 40000-1-2
FprEN 40000-1-2 is currently titled Principles, product risk management, and lifecycle activities. Its CEN-CENELEC project record shows that it is under approval and states that no citation is expected for Regulation (EU) 2024/2847.
It may be useful as an indication of current engineering direction, but it should not be presented as a published harmonised standard or as providing a presumption of conformity. Under Article 27 of the Cyber Resilience Act, the limited presumption attached to a harmonised standard arises only after its reference is published in the Official Journal, and only for the requirements covered.
Evidence to retain
A durable cybersecurity risk assessment is not just a risk register. The retained evidence should allow another competent reviewer to understand the product, the reasoning and the decisions made. It should include:
- the product context, intended purpose, foreseeable use, environment and expected use time;
- identified assets, interfaces, dependencies and assumptions;
- the chosen threat-modelling or assessment method and evaluation criteria;
- threat scenarios and the evidence supporting their evaluation;
- risk values or ratings, including the distinction between likelihood and attack feasibility where relevant;
- treatment decisions, implementation traceability and verification evidence;
- the mapping to applicable Cyber Resilience Act Annex I requirements; and
- review records and updates made during the support period.
Clear terminology helps preserve that evidence. Use threat model for the structured identification activity, cybersecurity risk assessment for the required product-specific assessment, risk management for the wider ongoing cycle, and TARA where the ISO/SAE 21434 automotive method is genuinely being applied.