Skip to main content

Threat Scenario

Under ISO/SAE 21434, a threat scenario describes a potential cause for the compromise of a cybersecurity property of an asset. The standard requires three parts: the targeted asset, the compromised cybersecurity property and the cause. The scenario says what happens. The attack paths describe how it happens.

Three parts, one sentence

A threat scenario fits into one sentence: cause compromises the property of element. Annex H of the standard phrases it like this for the headlamp example: spoofing of a signal compromises the integrity of the “Lamp Request” data communication to the actuator that switches the headlamp. The light may turn off unintentionally.

“Spoofing” on its own is not yet a threat scenario. It is a STRIDE category. Without an asset and a property, there is nothing to connect it to a damage scenario.

Threat and damage

Threat scenarios and damage scenarios are not linked one to one. A damage scenario can have several threat scenarios, and a threat scenario can cause several kinds of damage. For the front collision with a tree, Annex H lists two scenarios: spoofing of the lamp request and tampering with the signal sent by the body control ECU. So two different causes lead to the same damage scenario.

The order is free as well. For threat scenarios, the standard only requires the item definition. Assets and damage scenarios help, but you don’t need them. Conversely, you may derive assets from threat scenarios. If you prefer to start from the attacker’s side, go ahead.

Workshop or catalogue

The standard allows group discussion as well as systematic approaches: playing through misuse cases, or working with frameworks such as STRIDE, EVITA, TVRA or PASTA. It does not prescribe a catalogue.

It does, however, require you to verify against the item definition that the result is correct and complete. “We discussed it for two days” doesn’t help with that. “Every asset was checked against every applicable threat class of the catalogue” does, because someone else can check that statement.

From scenario to risk

The attack paths get rated, not the scenario. Each path receives an attack feasibility rating. In risk determination, the scenario inherits the value of its paths, in the standard’s example the maximum, because the attacker takes the easiest route. Together with the impact of the associated damage scenarios, this yields the risk value of the scenario.

Our article on threat scenarios and attack paths explains how scenario, path and feasibility fit together.

More on this topic

Related terms

Damage Scenario Attack Path Asset Attack Feasibility Threat Modeling

Frequently asked questions

What is the difference between a threat scenario and an attack path?
The threat scenario says what happens: which property of which asset is compromised, and by what. The attack path says how: the steps an attacker takes to carry out the scenario. One scenario often has several paths. Annex H gives three for spoofing the lamp request: via the cellular interface, via Bluetooth and via the OBD connector.
Does ISO/SAE 21434 require STRIDE?
No. The standard names STRIDE, EVITA, TVRA and PASTA as examples and explicitly allows group discussion as well. Only the content of a scenario is fixed: asset, compromised cybersecurity property and cause.
Does a threat scenario need a damage scenario?
Not to find it; the item definition is enough for that. For the risk, it does: the risk value comes from the impact of the associated damage scenarios. A scenario without damage has a feasibility, but no risk.
Reviewed by Jens Bühl, Product Owner on October 30, 2026