Understanding Cybersecurity Relevance in the Automotive Industry

By the example criteria in ISO/SAE 21434, a vehicle component is cybersecurity relevant when it is an electrical or electronic (E/E) item or component that contributes to the safe operation of the vehicle, collects or processes user-related data, or implements vehicle functions through networked components. A relevant component gets cybersecurity planning, which normally leads to a threat analysis and risk assessment (TARA); for a component that is not relevant, the standard's cybersecurity activities stop at that decision.

That first call matters because a TARA takes real engineering time, and nobody wants to spend it on a part that can't be attacked or skip it on a brake controller. This post walks through the check the standard suggests, the modules that usually pass it, and a longer questionnaire for components that sit on the line.

What cybersecurity relevance means in ISO/SAE 21434

ISO/SAE 21434:2021 is the international standard for cybersecurity engineering of road vehicles. It applies to cybersecurity-relevant items and components of series-production vehicles, including aftermarket and service parts, but not prototypes. So the first question for any part is whether it is relevant at all.

Clause 6.4.2 makes that the first step of cybersecurity planning. You analyze the item or component to decide whether it is cybersecurity relevant and, if it is, whether it is a new development or a reuse and whether the activities will be tailored. If it is not relevant, there are no cybersecurity activities and planning stops there. The standard's Annex D offers an example method for the decision, and it also allows relevance to be set by experience and expert judgment, for example from safety and cybersecurity experts.

Regulation gives one more reason to get this right. UN Regulation No. 155 (UN R155), which governs cybersecurity type approval in the markets that apply it, requires the automaker to identify the critical elements of a vehicle type and perform an exhaustive risk assessment for it. We treat the relevance screen as the place where a team decides which of those elements need their own TARA.

The four questions in the Annex D relevance check

Annex D is a short decision flow. A "no" to the first question, or a "no" to all of the last three, means the candidate is not cybersecurity relevant. A "yes" to any of questions 2 to 4 means it is.

1. Is it an E/E item or component? Electronic control units (ECUs) and the software on them, such as an infotainment application, count. A purely mechanical part does not.
2. Does it contribute to the safe operation of the vehicle? The standard's examples are motion control modules and modules with an ASIL designation (automotive safety integrity level, the safety rating from ISO 26262, the functional safety standard). An electronic stability control unit is a typical yes.
3. Does it collect or process user-related data? That means data about drivers or passengers, or sensitive information such as location. A navigation unit that stores trip history is a yes.
4. Does it implement vehicle functions based on networked components? This covers internal connections (controller area network or CAN, Ethernet, media-oriented systems transport or MOST, and the internet protocols TCP/IP), external connections (a backend server, the cellular network, the on-board diagnostics port known as OBD-II) and wireless sensors or actuators (remote keyless entry, near field communication or NFC, tire pressure monitoring). A telematics unit or a vehicle-to-everything (V2X) module that talks to roadside infrastructure fits here.

Vehicle modules that usually come out relevant

Run real modules through those four questions and the usual suspects say yes, often more than once. These are common examples; your own architecture decides the final list.

• Powertrain control module (PCM): runs engine and transmission control, so it affects safe operation.
• Restraint control module (RCM): deploys airbags and other restraints in a collision.
• Power steering control module (PSCM): directly affects how the vehicle steers.
• Anti-lock braking system (ABS) module: keeps control during hard braking by preventing wheel lockup.
• Gateway module: routes messages between the vehicle's networks, so it is networked by definition.
• Body control module (BCM): handles door locks, windows and other body functions, and talks to many other modules.
• Battery management system (BMS): monitors and protects the battery pack in electric and hybrid vehicles.

The same logic works at feature level. Airbag deployment, emergency braking, traction and stability control, door locking, windows and sunroofs that can serve as emergency exits, and disconnecting a charging system to prevent electrical hazards are all features whose components usually answer yes to question 2 or question 4.

A deeper questionnaire for borderline components

When a component sits on the line, or when you need to document why you decided what you decided, these questions go further than Annex D. They are our own checklist, not part of the standard, and the answers feed straight into the item definition if the component goes on to a TARA.

• Vehicle bus connectivity: Does it connect to a vehicle bus such as CAN or the local interconnect network (LIN)? How often does it communicate, which messages does it send and receive, and are they authenticated or encrypted?
• External interfaces: Does it exchange data over Wi-Fi, Bluetooth or another external interface? How are those interfaces protected, does data exchange need user interaction, and can the interfaces be disabled?
• Contribution to safe operation: Does it influence a safety function such as braking? Which ones, and how does it handle redundancy and failsafe behavior?
• Regulations and standards: Are its functions governed by regulation or by standards such as ISO 26262 or ISO/SAE 21434, and how is compliance verified and documented?
• Sensitive or personal data: Does it handle driver information or other personal data? What kind, how is it protected, and how long is it kept?
• Remote connectivity: Does it support cellular links or over-the-air (OTA) updates? What protects those connections, and can they be monitored and audited?
• Integration with critical systems: Is it part of, or connected to, braking, steering or another critical system? What happens to the vehicle if it fails or is compromised?
• Software updates: How are updates and patches delivered, over the air or with physical access, and how are their integrity and authenticity checked?

What happens after the relevance decision

A "relevant" result is where the work starts. Next comes the call on new development or reuse and on tailoring, then the item definition and the TARA in the concept phase. The TARA's impact and attack ratings in turn shape how much assurance rigor the component gets, which we cover in Cybersecurity Assurance Levels in Product Development Lifecycle.

A "not relevant" result deserves a written reason. We recommend recording which question ruled the component out, so a reviewer can follow the logic and the call gets revisited when the design changes, for example when a once-isolated module gains a wireless interface. Bring the engineers who know the component into that call; we explain why in Involving Engineers Early in the TARA Process.

Need help sorting which components need a TARA?

We have done nearly 400 TARAs for automakers and suppliers at every tier, from full vehicles down to single chips. If you have a list of components and need to decide which ones are cybersecurity relevant and how deep each TARA should go, tell us what you're working on and we will talk it through with you.