GUIDE · Product security
Threat modelling for connected products
A threat model earns its cost when it changes the architecture. If it only produces a report, it was documentation, not engineering.
LAST REVIEWED
What a product threat model has to contain
- The system in scope: hardware, firmware, application software, cloud services, update channels and the boundary you are not claiming to protect.
- Assets worth protecting: keys, credentials, firmware integrity, configuration, user data, availability of a safety function.
- Interfaces and trust boundaries: physical ports, debug interfaces, radio links, network services, local and remote management paths, supply-chain entry points such as the build pipeline.
- Attacker models: the capability and access you assume, stated explicitly, because every requirement that follows depends on it.
- Attack paths and their consequences, including consequences that cross into safety.
- The resulting security requirements and design decisions, each traceable to a specific threat.
Choosing a method
STRIDE remains the most practical starting point for product teams because it maps threat categories onto data flows and is quick to teach. Attack trees are better where one high-consequence outcome needs to be analysed in depth, such as unauthorised firmware installation. For industrial components, IEC 62443-based analysis is usually expected, working from zones, conduits and target security levels. In automotive, ISO/SAE 21434's TARA prescribes the structure, including impact and attack feasibility rating.
The method matters less than the discipline: one agreed diagram of the real system, explicit assumptions, and a decision for every identified threat — mitigate, transfer, accept with justification, or resolve out of scope.
Where threat modelling belongs in the lifecycle
- Concept: a coarse model on the intended architecture, used to make interface and platform choices before they are expensive.
- Design: a detailed model per subsystem, producing testable security requirements.
- Implementation: model updates triggered by new interfaces, new dependencies or changed deployment assumptions.
- Verification: security tests derived from the threat model, so testing is targeted rather than generic.
- Post-release: reassessment when vulnerabilities, incidents or substantial modifications change the picture.
Safety and security interaction
For safety-critical products the threat model must connect to the hazard analysis. A security compromise that can defeat a safety mechanism, disable a limit, or falsify sensor input is a safety concern with a security cause, and it needs to be visible in both analyses with a consistent conclusion. Keeping the two analyses in separate documents with separate owners and no cross-references is the most common way this failure mode is missed.
Turning the model into CRA evidence
The CRA requires a cybersecurity risk assessment that is documented, kept up to date, and used to justify the measures taken. A threat model satisfies this when it records the assessment date and the version of the product it applies to, states the attacker assumptions, links each requirement to a threat, and links each requirement to verification evidence. Reviewers look for that chain rather than for a particular template, so a maintained model with traceability is stronger evidence than an elaborate one-off report.
Frequently asked questions
Does the CRA require threat modelling explicitly?
The CRA requires manufacturers to carry out and document a cybersecurity risk assessment and to base their design and process decisions on it. It does not name a method, so threat modelling is the common engineering practice used to satisfy the requirement rather than a named legal obligation.
How often should a threat model be updated?
Whenever the assumptions change: new interfaces or services, new third-party components, a change in deployment context, a substantial modification of the product, or a vulnerability that shows an attacker capability you had not assumed.
Who should take part in a threat modelling session?
The architect, at least one implementer who knows what the code actually does, someone who understands the deployment environment, and for safety-critical products the safety engineer. A session run only by a security specialist tends to miss real interfaces.
What is the difference between a threat model and a TARA?
A TARA is the threat analysis and risk assessment method prescribed by ISO/SAE 21434 for road vehicles, with defined impact categories and attack feasibility rating. A threat model is the general practice; a TARA is a specific regulated form of it.