Skip to main content

Asset

Under ISO/SAE 21434, an asset is an object of value whose cybersecurity property can be compromised: confidentiality, integrity or availability. The standard requires identifying exactly those assets whose compromise leads to a damage scenario. An element of the item is therefore not automatically an asset. It becomes one when compromising one of its properties leads to damage.

Element plus property

An asset is never the element alone. It always includes the property to be protected. Annex H of the standard marks both confidentiality and integrity for the firmware of the body control ECU. Those are two assets on one element, and each leads to very different damage.

If you list only the element, you silently set the property to “all three”. That inflates the threat analysis and gains nothing.

When is an element an asset?

The candidates come from the item definition: functions, components, channels, data flows and data. A simple test helps you choose: can you complete this sentence? If the property of element is compromised, stakeholder suffers damage. If you can, you have an asset and a damage scenario. If you can’t, it stays an element of the architecture.

In the headlamp example in Annex H, only integrity is marked for the “Lamp Request” data communication, because the damage scenarios are about the light turning off unintentionally. Annex H doesn’t mark the other properties there, because no damage scenario depends on them. The assets it lists are two data communications and one firmware. No ECU is among them.

Order and sources

The standard doesn’t say whether assets or damage scenarios come first. Assets can be derived from the item definition, through the impact rating, from threat scenarios or from predefined catalogues. Annex H states explicitly that the modules of the TARA can be worked through in any order.

Assets in practice

Confidentiality, integrity and availability are the usual set, but not a ceiling. If you want to rate authenticity separately, add it as a fourth property.

The damage can’t always be determined from the element alone. A manipulated data flow does no harm by itself. What matters is which function depends on it and who uses that function. So it pays to list functions as assets too. Then the damage scenario sits where the damage happens.

When assets hang off the elements of a model instead of sitting in a spreadsheet row, the completeness check becomes a query: which elements carry no asset, which assets have no damage scenario? More on this in our article on asset identification and impact rating.

More on this topic

Related terms

Damage Scenario Threat Scenario Item Definition Impact Rating TARA

Frequently asked questions

Is every component of the item definition an asset?
No. Every element of the item definition is a candidate, but it only becomes an asset when its compromise causes damage. An asset list that copies the component list and ticks confidentiality, integrity and availability everywhere says little. It still creates work: every tick drags threat scenarios along with it.
Which cybersecurity properties does an asset have?
The usual ones are confidentiality, integrity and availability, C/I/A for short. That is the common set, but not a ceiling. If you want to rate authenticity separately, add it as a fourth property.
Do assets or damage scenarios come first?
Either works. Annex H names both sequences: first the assets and then their damage scenarios, or first damage scenarios from a catalogue and then the matching assets. The standard also allows deriving assets from threat scenarios.
Reviewed by Jens Bühl, Product Owner on October 30, 2026