Trainers Treasure - All that makes a perfect trainer: ISO/SAE 21434 — CYBERSECURITY FOR ROAD VEHICLES From Connected Vehicles to Cyber-Resilient Mobility

Course Introduction

The automobile has evolved.

What was once primarily a mechanical machine has become a complex, software-driven, connected and increasingly intelligent system. Modern vehicles contain dozens of Electronic Control Units (ECUs), millions of lines of software code, multiple communication networks, sensors, cameras, cloud connections, mobile applications, diagnostic interfaces and over-the-air (OTA) update capabilities.

This transformation has created enormous opportunities—but it has also created a new class of engineering risks.

A vulnerability in a vehicle component may no longer remain confined to that component. A weakness in an ECU, communication interface, diagnostic port, mobile application, cloud service, software library or supplier component can potentially become an entry point into a much larger vehicle ecosystem.

The question is no longer:

"Can we build a vehicle that works?"

The question is:

"Can we build a vehicle that continues to work safely and securely when someone deliberately tries to make it fail?"

That is the thinking behind ISO/SAE 21434 — Road Vehicles — Cybersecurity Engineering.

WHY THIS COURSE MATTERS

Cybersecurity cannot be treated as something that is added at the end of vehicle development.

It must be considered from the moment a system is conceived, through architecture, software and hardware development, testing, production, deployment, operation, maintenance, software updates and eventual decommissioning.

This requires a fundamental change in mindset:

From:

"Find vulnerabilities before launch."

To:

"Engineer cybersecurity into the product and its lifecycle."

ISO/SAE 21434 provides a structured framework for managing cybersecurity risks throughout the lifecycle of automotive electrical and electronic systems.

But understanding the standard is only the beginning.

The real value comes from being able to apply its principles to real vehicles, real components, real projects and real engineering decisions.

THINK LIKE AN ATTACKER.

ENGINEER LIKE A DEFENDER.

During this programme, participants will be challenged to look at an automobile from two different perspectives.

THE ATTACKER ASKS:

Where can I enter?

What can I access?

What vulnerability can I exploit?

What happens if I modify it?

Can I move from one system to another?

Can I remain undetected?

THE ENGINEER ASKS:

What are our critical assets?

What can go wrong?

What is the potential impact?

How do we assess the risk?

What cybersecurity goal do we need?

What security requirement should we define?

How do we implement the control?

How do we verify that it actually works?

FROM COMPONENT TO VEHICLE

Video on Internet Security

A central idea throughout this programme will be:

A component does not exist in isolation.

Consider a simple ECU.

It may communicate with:

Sensors → ECU → CAN/Ethernet → Gateway → Other ECUs → Telematics → Cloud → Mobile Application

Now imagine that one component contains a vulnerability.

The important question is not simply:

"Is this component vulnerable?"

The more important question is:

"What could an attacker do with that vulnerability, and what could ultimately be affected?"

This is where Threat Analysis and Risk Assessment (TARA) becomes critical.

THE PRACTICAL LEARNING MODEL

Participants will use a simple working framework throughout the programme:

COMPONENT

What are we analysing?

↓

ASSET

What needs to be protected?

↓

VULNERABILITY

Where could the weakness exist?

↓

ATTACK PATH

How could an attacker reach it?

↓

THREAT

What could the attacker do?

↓

DAMAGE

What could happen?

↓

RISK

How significant is the risk?

↓

CYBERSECURITY GOAL

What must we protect?

↓

REQUIREMENT

What must the system do?

↓

CONTROL

How will we protect it?

↓

VERIFY

How will we prove that the protection works?

This transforms cybersecurity from an abstract concept into an engineering decision-making process.

THIS IS NOT JUST AN ISO AWARENESS PROGRAMME

Over these two days, participants will not simply listen to presentations.

They will:

Map vehicle attack surfaces
Identify assets
Analyse vulnerabilities
Build threat scenarios
Conduct practical TARA exercises
Use Fishbone and 5-Why analysis
Develop cybersecurity goals
Convert threats into cybersecurity requirements
Identify security controls
Analyse ECU and vehicle interfaces
Examine OTA security
Explore supplier cybersecurity
Examine production and manufacturing risks
Connect cybersecurity with functional safety
Work through incident-response scenarios
Build cybersecurity checklists
Develop practical action plans
Apply the learning to a real component or system from their work environment

THE MINDSET WE WANT TO BUILD

The objective is not to make every participant a cybersecurity specialist.

The objective is to make every participant cybersecurity-aware in the decisions they already make.

An engineer changing software should think:

"What new cybersecurity risk does this change introduce?"

A designer adding an interface should ask:

"What new attack surface have we created?"

A supplier-quality professional should ask:

"What cybersecurity evidence should I expect from this supplier?"

A manufacturing engineer should ask:

"Can this programming or diagnostic station become an entry point?"

A tester should ask:

"Can I demonstrate that the cybersecurity requirement actually works?"

A project manager should ask:

"What cybersecurity risks remain open before release?"

A leader should ask:

"Who owns this risk, and where is the evidence?"

THE 5-STEP COURSE FRAMEWORK

Throughout the programme, we will use:

C — CONNECT

Understand the vehicle, system and attack surface.

A — ASSESS

Identify assets, vulnerabilities and threats.

R — RISK

Conduct TARA and understand potential consequences.

E — ENGINEER

Develop cybersecurity goals, requirements and controls.

S — SUSTAIN

Verify, monitor, respond and continuously improve.

CONNECT → ASSESS → RISK → ENGINEER → SUSTAIN

THE ULTIMATE OBJECTIVE

At the end of these two days, participants should not merely be able to answer:

"What is ISO/SAE 21434?"

They should be able to answer:

"What does ISO/SAE 21434 mean for MY component, MY project, MY process and MY vehicle?"

And more importantly:

"What can I do differently tomorrow?"

Because automotive cybersecurity is not achieved by a document, a certificate or a single security test.

It is achieved when cybersecurity becomes part of everyday engineering, manufacturing, supplier management, testing, decision-making and continuous improvement.

WELCOME TO CYBERSECURE VEHICLES 4.0

Think Like an Attacker.

Engineer Like a Defender.

Build Vehicles That Can Be Trusted.

ISO/SAE 21434:2021 establishes cybersecurity engineering requirements across the E/E-system lifecycle—from concept and development through production, operation, maintenance and decommissioning. It is technology-neutral and focuses on cybersecurity risk management rather than prescribing particular security technologies. (ISO)

2-Day Training Programme

ISO/SAE 21434 — Cybersecurity for Road Vehicles

Suggested programme title

Cybersecurity for Road Vehicles – ISO/SAE 21434:2021
From Threat Analysis to Cybersecurity Engineering and Operational Resilience

Target participants

Vehicle/System Engineers
E/E Engineers
ECU/Embedded Engineers
Software Engineers
Cybersecurity Engineers
Functional Safety Engineers
R&D
Product Development
Vehicle Architecture
Connected Vehicle/Telematics Teams
OTA Teams
Quality
Supplier Quality
Procurement
Manufacturing/Production Engineering
IT/OT Cybersecurity
Testing & Validation
Project Managers
Technical Programme Managers
Senior HR/L&D stakeholders responsible for technical capability development

PROGRAMME OUTCOMES

By the end of two days, participants should be able to:

Explain the purpose and structure of ISO/SAE 21434.
Understand automotive cybersecurity versus traditional IT cybersecurity.
Identify vehicle attack surfaces.
Identify assets and cybersecurity properties.
Develop an Item Definition.
Conduct a practical TARA.
Identify damage scenarios and threat scenarios.
Develop cybersecurity goals.
Derive cybersecurity requirements.
Understand cybersecurity concept and architecture.
Apply security controls to ECU/vehicle architectures.
Understand verification and validation.
Manage cybersecurity in production and post-production.
Understand cybersecurity monitoring and incident response.
Evaluate supplier cybersecurity evidence.
Understand OTA cybersecurity.
Understand vulnerability and cybersecurity incident management.
Connect ISO/SAE 21434 with UN R155/R156.
Create a practical cybersecurity implementation roadmap for their workplace.
Take back templates/checklists that can be used immediately.

UN Regulation No. 155 specifically addresses vehicle cybersecurity and cybersecurity management systems, while UN R156 addresses software updates. (UNECE)

DAY 1

BUILDING THE AUTOMOTIVE CYBERSECURITY MINDSET

DAY 1 FLOW

Time	Module	Method
09:00–09:30	Opening + Cybersecurity Reality Check	Poll + discussion
09:30–10:30	1. Connected Vehicle Cybersecurity	Case study
10:30–11:15	2. ISO/SAE 21434 Framework	Interactive mapping
11:15–11:30	Tea Break
11:30–12:30	3. Automotive Attack Surface	Group activity
12:30–13:30	4. Item Definition	Hands-on
13:30–14:15	Lunch
14:15–15:30	5. Asset Identification & Damage Scenarios	Workshop
15:30–16:30	6. TARA – Threat Analysis & Risk Assessment	Hands-on
16:30–16:45	Break
16:45–17:30	7. Risk Evaluation & Treatment	Simulation
17:30–18:00	Day 1 Cybersecurity Challenge	Team exercise

MODULE 1

Why Automotive Cybersecurity Is Different

Duration

60 minutes

Learning objectives

Participants understand why a modern automobile is effectively a distributed cyber-physical system.

Discuss:

ECU
CAN/CAN-FD
LIN
Automotive Ethernet
Gateway
Infotainment
Telematics
ADAS
Bluetooth
Wi-Fi
GNSS
Cellular connectivity
OBD
USB
Mobile applications
Cloud backend
OTA
Keyless entry
Digital key
Charging infrastructure
EV battery communication

Key question

“What happens when a cybersecurity incident becomes a physical safety or operational problem?”

ACTIVITY 1 — "My Car Is a Network"

Give every group a vehicle architecture diagram.

Ask them to identify:

External interfaces → Entry points → ECUs → Networks → Critical functions

Example:

Mobile App

↓

Cloud

↓

Telematics

↓

Gateway

↓

CAN / Ethernet

↓

ECUs

↓ ↓ ↓

ADAS BCM Powertrain

↓

Vehicle Functions

Group task

Mark:

🔴 High-value assets
🟠 External interfaces
🟡 Trust boundaries
🔵 Communication paths
🟢 Security controls

Takeaway

Participants begin seeing the automobile as an attack surface, rather than simply a mechanical product.

REAL-WORLD CASE STUDY 1 - Jeep Cherokee Remote Hacking

- Video Link - Hindi - Tamil

TAMIL - VIDEO

How can an apparently harmless infotainment/connectivity pathway potentially become a pathway toward vehicle functions?

Discussion

Participants identify:

Entry point
Attack path
Trust boundary
Vulnerable component
Potential damage
Required controls

Important: use the case only for defensive analysis; do not conduct exploitation against a real vehicle.

Below is a facilitator-ready case study you can insert directly into your ISO/SAE 21434 training workbook. I have kept the technical details sufficient for defensive TARA and architecture analysis, but deliberately avoided operational exploit instructions.

- Video Link - Hindi - Tamil

TAMIL - VIDEO

Case Study: Jeep Cherokee Remote Hacking

"When the Infotainment System Became a Path to Vehicle Functions"

Case-study purpose

This case demonstrates one of the most important lessons in automotive cybersecurity:

A component that appears to be an infotainment or connectivity system can become a cybersecurity pathway to safety- and vehicle-critical functions when appropriate security boundaries and controls are absent.

In 2015, security researchers Charlie Miller and Chris Valasek demonstrated remote compromise of a 2014 Jeep Cherokee. Their research showed that a vulnerability in the vehicle's Uconnect connectivity/infotainment system could be used as a pathway into the vehicle's internal networks and ultimately affect certain physical vehicle functions. (WIRED)

The demonstration became one of the landmark events in automotive cybersecurity and contributed to a recall involving approximately 1.4 million affected vehicles equipped with certain Uconnect systems. (NHTSA)

1. CASE BACKGROUND

Vehicle

2014 Jeep Cherokee

Researchers

Charlie Miller and Chris Valasek

Technology involved

Uconnect infotainment/connectivity system

Connectivity

The Uconnect system had cellular connectivity, which created a pathway between the vehicle and external networks.

Internal vehicle network

The vehicle's electronic control systems communicated over internal networks including the CAN bus.

Core security problem

The critical architectural lesson was not simply "the infotainment system had a vulnerability."

The deeper issue was:

A remotely reachable component was connected deeply enough into the vehicle architecture that compromise could be leveraged toward other vehicle systems.

The researchers demonstrated that the compromised head unit could be used to send messages into the vehicle's internal CAN network and affect certain vehicle functions. (WIRED)

2. WHAT HAPPENED?

The research demonstrated a chain broadly equivalent to:

This is the most important diagram for your training session.

Don't focus the participants on the specific exploit.

Focus them on the architectural journey of the attack.

3. THE "HOW CAN THIS HAPPEN?" QUESTION

Put this question on the screen:

"How can an apparently harmless infotainment/connectivity pathway potentially become a pathway toward vehicle functions?"

Give participants 3 minutes individually.

Then ask them to discuss in groups.

Expected thought process:

Stage 1

The attacker is not necessarily starting with the braking or steering system.

They begin with an externally reachable connected component.

↓

Stage 2

That component has a software vulnerability.

↓

Stage 3

The attacker gains control over the compromised component.

↓

Stage 4

The compromised component has communication pathways into the vehicle's internal network.

↓

Stage 5

Insufficient isolation allows messages to reach systems beyond the original infotainment function.

↓

Stage 6

The attack therefore moves from:

Cyber domain → Vehicle network → Physical consequences

That is the core lesson.

4. ATTACK CHAIN — DEFENSIVE VERSION

For your training, represent the incident as:

Stage	What happened conceptually	ISO/SAE 21434 question
1	External connectivity existed	What is the attack surface?
2	Vulnerability existed in connected software	What vulnerabilities must be considered?
3	Attacker reached the connected component	What is the entry point?
4	Component was compromised	What assets were exposed?
5	Compromised component had internal network access	Is the trust boundary appropriate?
6	Internal messages could reach other systems	Is network segmentation sufficient?
7	Vehicle functions were affected	What is the damage scenario?
8	Physical consequences became possible	How should impact be assessed?
9	Manufacturer developed mitigation	What risk treatment is required?
10	Software update/recall followed	How should vulnerabilities be managed throughout the lifecycle?

5. IDENTIFY THE ENTRY POINT

Ask participants:

Where did the attacker enter the vehicle ecosystem?

Expected answer

The attack leveraged the vehicle's externally connected Uconnect system.

The researchers identified a remotely accessible vulnerability associated with the Uconnect system's connectivity. Contemporary technical reporting described the cellular-connected Uconnect system as the remote entry pathway. (IEEE Spectrum)

Training lesson

The entry point was not an obvious mechanical component.

It was:

Connectivity + software + an externally reachable interface

ISO/SAE 21434 connection

Participants should ask:

What external interfaces exist?
Which interfaces are remotely reachable?
Which services are exposed?
What assets can those interfaces eventually reach?
What trust boundaries exist after initial access?

6. IDENTIFY THE VULNERABLE COMPONENT

Component

Uconnect head unit / infotainment system

It was supplied as part of the vehicle's electronic architecture and provided functions including entertainment, navigation/connectivity and related services.

The researchers found a vulnerability in the head-unit environment that enabled them to gain control of the component and then pivot toward the vehicle network. (WIRED)

Important teaching point

Ask:

"Was the infotainment system itself the final target?"

Not necessarily.

It functioned as an initial foothold and pivot point.

This is an excellent way to explain:

Attack Surface ≠ Final Target

7. IDENTIFY THE TRUST BOUNDARY

"What should happen when an infotainment ECU is compromised?"

Ideal answer

The compromise should remain contained.

A compromised infotainment component should not automatically gain the ability to influence safety- or control-critical systems.

8. THE KEY ARCHITECTURAL LESSON

"COMPROMISE ONE ≠ COMPROMISE EVERYTHING"

This leads directly into:

Segmentation
Least privilege
Gateway security
Authentication
Message validation
Network monitoring
Access control
Intrusion detection
Secure architecture
Defence in depth

9. IDENTIFY THE ATTACK PATH

REMOTE ACTOR

↓

EXTERNAL CONNECTIVITY

↓

UCONNECT

↓

COMPROMISED INFOTAINMENT

↓

INTERNAL VEHICLE NETWORK

↓

CONTROL-RELATED ECUs

↓

VEHICLE FUNCTION

"At which point could we have broken the attack chain?"

Potential answers:

Point 1 - External connectivity → Authentication / access control

Point 2 - Infotainment→ Secure software / vulnerability management

Point 3 Infotainment → internal network → Gateway / segmentation

Point 4 Internal network → Message authentication / filtering

Point 5 Critical ECU → Command validation / least privilege

Point 6 Attack detection → IDS / monitoring / incident response

10. POTENTIAL DAMAGE SCENARIOS

The actual 2015 research demonstrated effects on several vehicle functions, including functions involving braking and steering, under the researchers' controlled test conditions. Contemporary reporting also documented manipulation involving throttle, transmission and other vehicle functions.

For training, don't focus on reproducing those actions.

Instead ask participants to identify the damage scenarios.

Damage Scenario A — Loss of vehicle control

Potential compromise of vehicle-control-related functions could create a safety risk.

Damage Scenario B — Loss of availability

A vehicle function may become unavailable or behave unexpectedly.

Damage Scenario C — Incorrect information

Instrument-cluster or vehicle-status information could potentially be manipulated.

Damage Scenario D — Driver distraction

Unexpected changes to infotainment or vehicle functions could distract the driver.

Damage Scenario E — Privacy impact

Connected systems may expose information such as vehicle/location-related data.

Damage Scenario F — Fleet-level impact

A remotely exploitable vulnerability could potentially affect a large population of similarly configured vehicles.

11. TARA EXERCISE (Threat Analysis and Risk Assessment)

Group assignment

Each group gets one asset.

Group 1 - Infotainment system

Group 2 - Vehicle network

Group 3 - Vehicle-control function

Group 4 - Connected communication service

Group 5 - Software/update mechanism

TARA WORKSHEET

TARA Element	Participant Response
Item	Connected vehicle
Asset
Asset value
Damage scenario
Threat scenario
Attack path
Entry point
Attacker capability
Impact
Attack feasibility
Risk
Existing control
Control gap
Risk treatment
Cybersecurity goal
Cybersecurity requirement
Verification method

Tara worksheet

12. SAMPLE TARA

Asset

Vehicle-control-related functionality

Damage scenario

Unauthorized manipulation of vehicle functionality.

Threat scenario

An attacker compromises a remotely accessible connected vehicle component and uses available internal communication pathways to influence another vehicle system.

Attack path

External connectivity

↓

Connected ECU

↓

Compromise

↓

Internal network

↓

Target ECU

↓

Vehicle function

Impact

Potentially significant safety and operational consequences.

Attack feasibility

Participants should assess this using the organisation's approved TARA methodology rather than simply assigning a number based on intuition.

Risk treatment

Potential measures could include:

Network segmentation
Gateway filtering
Strong authentication
Secure communications
Least-privilege architecture
Secure boot
Software hardening
Vulnerability management
Intrusion detection
Security monitoring
Security testing
Incident response

Absolutely. Your worksheet is a good classroom-level TARA exercise. I recommend giving participants completed examples first, then asking them to analyse a component from their own work area.

Below are 5 practical examples covering different automotive systems. These are deliberately framed at a defensive/conceptual level—not as instructions for exploiting a vehicle.

1. EXAMPLE — INFOTAINMENT / HEAD UNIT

Scenario

A connected infotainment system communicates with cellular services and other vehicle systems through an internal gateway.

TARA Element	Participant Response
Item	Connected Infotainment / Head Unit
Asset	Infotainment software, user data, communication interfaces
Asset value	High – connected to external services and vehicle network
Damage scenario	Unauthorized access could compromise vehicle data or potentially provide a pathway toward internal vehicle networks
Threat scenario	Attacker exploits a weakness in a connected infotainment service
Attack path	External connectivity → connected service → infotainment → gateway → internal network
Entry point	Cellular / Wi-Fi / connected service
Attacker capability	Remote attacker with knowledge of the system and ability to exploit a vulnerability
Impact	Privacy, vehicle availability, cybersecurity; potentially safety depending on downstream connectivity
Attack feasibility	Medium — depends on vulnerability, exposure and required access
Risk	High if the infotainment system has insufficient isolation from safety-related systems
Existing control	Gateway, authentication, network segmentation, secure software development
Control gap	Insufficient isolation or inadequate validation of messages crossing the boundary
Risk treatment	Strengthen segmentation, authentication, input validation and monitoring
Cybersecurity goal	Prevent unauthorised access from the infotainment domain to protected vehicle functions
Cybersecurity requirement	The gateway shall restrict and validate communication between the infotainment domain and protected vehicle networks.
Verification method	Architecture review, configuration review, negative testing, security testing and penetration testing by authorised teams

Teaching point

Ask participants:

"If the infotainment system is compromised, should that automatically mean the attacker can reach every ECU?"

The discussion should lead toward:

Defense-in-depth + segmentation + gateway controls.

2. EXAMPLE — BATTERY MANAGEMENT SYSTEM (BMS)

Scenario

An EV's BMS monitors battery parameters and communicates with other vehicle controllers.

TARA Element	Participant Response
Item	Battery Management System
Asset	Battery monitoring/control software, battery parameters, calibration data
Asset value	Very High – affects battery operation, vehicle availability and potentially safety
Damage scenario	Manipulation of battery-control parameters could result in incorrect battery management
Threat scenario	Unauthorized modification or injection of invalid commands/data
Attack path	External/internal interface → vehicle network → BMS
Entry point	Vehicle network / diagnostic interface / authorised service interface
Attacker capability	Skilled attacker with access to an exposed interface
Impact	Safety, vehicle availability, battery performance, financial/reputational impact
Attack feasibility	Medium
Risk	High
Existing control	Authentication, access control, message validation, diagnostics protection
Control gap	Insufficient command validation or excessive diagnostic privileges
Risk treatment	Strengthen authentication, authorisation and command validation
Cybersecurity goal	Prevent unauthorised modification of safety-relevant battery-control functions
Cybersecurity requirement	The BMS shall validate the authenticity, integrity and authorisation of security-relevant commands before execution.
Verification method	Security requirement testing, negative testing, diagnostic access testing and validation

Teaching question

"What is more important here—the confidentiality of battery data or the integrity of battery-control commands?"

This helps participants understand CIA + safety impact.

3. EXAMPLE — OTA SOFTWARE UPDATE

Scenario

The vehicle receives software updates from an OEM backend.

TARA Element	Participant Response
Item	OTA Software Update System
Asset	Firmware/software update package
Asset value	Very High
Damage scenario	Unauthorised or corrupted software could be installed in the vehicle
Threat scenario	Attacker attempts to introduce an unauthorised software package
Attack path	Backend → OTA service → vehicle → ECU
Entry point	OTA backend / update channel
Attacker capability	Attacker capable of compromising credentials, infrastructure or update delivery
Impact	Vehicle availability, integrity, customer impact, potentially safety depending on affected ECU
Attack feasibility	Medium
Risk	High/Critical depending on affected function and controls
Existing control	Code signing, authentication, secure update mechanism, access control
Control gap	Inadequate protection of signing keys, weak access control or incomplete update validation
Risk treatment	Strong cryptographic signing, key protection, authentication, integrity verification and rollback/recovery mechanisms
Cybersecurity goal	Ensure only authentic and authorised software can be installed
Cybersecurity requirement	The vehicle shall verify the authenticity and integrity of an OTA software package before installation.
Verification method	Update-package validation testing, negative testing, key/certificate testing and authorised security assessment

Great classroom question

Write this on the screen:

"What if the software update itself becomes the attack?"

Then ask participants to identify five controls.

Expected discussion:

Authentication → Signing → Integrity → Authorisation → Recovery

4. EXAMPLE — DIAGNOSTIC INTERFACE

Scenario

A service technician uses a diagnostic interface to communicate with vehicle ECUs.

TARA Element	Participant Response
Item	Diagnostic Interface
Asset	Diagnostic functions and ECU access
Asset value	High
Damage scenario	Unauthorised diagnostic operations could alter vehicle configuration or access protected functions
Threat scenario	Unauthorised person gains access to diagnostic functions
Attack path	Physical/service access → diagnostic interface → gateway → ECU
Entry point	Diagnostic/service interface
Attacker capability	Person with physical access and sufficient technical knowledge
Impact	Vehicle integrity, availability, security and potentially safety
Attack feasibility	Medium to High depending on protection
Risk	High
Existing control	Authentication, diagnostic security access, gateway filtering
Control gap	Excessive privileges or inadequate authentication
Risk treatment	Role-based access, strong authentication, session controls, logging and least privilege
Cybersecurity goal	Prevent unauthorised diagnostic access to protected vehicle functions
Cybersecurity requirement	The diagnostic interface shall require authenticated and authorised access before allowing security-relevant diagnostic functions.
Verification method	Access-control testing, authentication testing, privilege testing and log verification

Teaching question

"Should a technician who can read diagnostic information automatically be allowed to change vehicle configuration?"

This introduces:

LEAST PRIVILEGE

5. EXAMPLE — ADAS CAMERA / ADAS ECU

Scenario

An ADAS ECU processes information from cameras/sensors and exchanges information with other vehicle controllers.

TARA Element	Participant Response
Item	ADAS Camera / ADAS ECU
Asset	Sensor data, ADAS software, calibration parameters
Asset value	Very High
Damage scenario	Manipulated or incorrect data could cause an ADAS function to make an incorrect decision
Threat scenario	Attacker manipulates sensor-related information or compromises the ADAS ECU
Attack path	External/internal interface → network → ADAS ECU
Entry point	Vehicle network / software interface / sensor interface
Attacker capability	Skilled attacker with access to an applicable interface
Impact	Safety, vehicle behaviour, customer trust
Attack feasibility	Medium
Risk	High because of potential safety consequences
Existing control	Authentication, message validation, plausibility checks, secure software
Control gap	Insufficient validation of received data or inadequate isolation
Risk treatment	Message validation, secure communication, anomaly detection and robust architecture
Cybersecurity goal	Protect the integrity and authenticity of information used by safety-relevant ADAS functions
Cybersecurity requirement	The ADAS ECU shall validate security-relevant incoming messages before using them for safety-related decisions.
Verification method	Interface testing, message-validation testing, negative testing, security testing and validation

Teaching question

"What happens if the data is genuine—but deliberately manipulated?"

This is a powerful way of explaining:

Integrity ≠ Availability ≠ Confidentiality

6. EXAMPLE — TELEMATICS CONTROL UNIT (TCU)

This is particularly useful because it connects the outside world to the vehicle.

TARA Element	Participant Response
Item	Telematics Control Unit
Asset	Vehicle connectivity, location data, communication credentials
Asset value	High
Damage scenario	Unauthorised access to vehicle services or exposure/manipulation of sensitive information
Threat scenario	Attacker exploits a weakness in an exposed connectivity service
Attack path	Cellular network → TCU → gateway → internal network
Entry point	Cellular connectivity
Attacker capability	Remote attacker with technical capability
Impact	Privacy, vehicle security, availability and potentially safety depending on connected functions
Attack feasibility	Medium
Risk	High if internal network access is insufficiently controlled
Existing control	Authentication, firewall/gateway, secure communication, monitoring
Control gap	Weak network segmentation or insufficient traffic filtering
Risk treatment	Strong segmentation, allow-listing, authentication, monitoring and anomaly detection
Cybersecurity goal	Prevent compromise of the TCU from providing unauthorised access to protected vehicle functions
Cybersecurity requirement	The vehicle gateway shall restrict communication from the telematics domain to authorised internal vehicle functions.
Verification method	Architecture review, rule verification, interface testing and authorised penetration testing

7. A SIMPLE EXAMPLE FOR NON-CYBERSECURITY PARTICIPANTS

You can also start the workshop with something very simple.

COMPONENT: USB PORT

Ask:

"What could go wrong?"

Participants might say:

USB → malicious file → infotainment system → software compromise

Now complete the worksheet:

TARA Element	Example
Item	USB interface
Asset	Infotainment system/software
Asset value	Medium/High
Damage scenario	Unauthorised software/data modification
Threat scenario	Malicious content introduced through USB
Attack path	USB → infotainment
Entry point	USB port
Attacker capability	Person with physical access
Impact	Data/security/availability
Attack feasibility	Medium
Risk	Medium/High depending on controls
Existing control	File validation, access restrictions
Control gap	Insufficient input validation
Risk treatment	Input validation, device control, privilege restriction
Cybersecurity goal	Prevent unauthorised content from compromising the system
Cybersecurity requirement	The infotainment system shall validate external USB content before processing it.
Verification method	Negative testing using authorised test data

This is a good warm-up exercise before moving to ECU/TARA cases.

THE MOST IMPORTANT PART: COMPARE THE COMPONENTS

After the teams complete their worksheets, put this on the screen:

Component	Asset	Entry Point	Main Concern	Impact
Infotainment	Software/data	Cellular/Wi-Fi	Network access	Security/Privacy/Safety
BMS	Battery control	Vehicle network/diagnostics	Integrity	Safety
OTA	Firmware	Backend/update channel	Unauthorised software	Integrity/Availability
Diagnostic	ECU functions	Service interface	Privilege abuse	Security/Safety
ADAS	Sensor/software	Network/interface	Data integrity	Safety
TCU	Connectivity	Cellular	Network access	Security/Privacy

Then ask:

"Which component should we analyse first?"

Don't give them the answer.

Instead ask them to justify their choice using:

Asset criticality + impact + exposure + attack feasibility + existing controls.

That naturally introduces risk-based prioritisation.

A GREAT "5 WHY" EXAMPLE

Take the BMS example.

PROBLEM

Unauthorised command could potentially reach the BMS.

WHY 1?

Why can an unauthorised command reach it?

→ The command pathway does not sufficiently validate the sender.

WHY 2?

Why is the sender not sufficiently validated?

→ Authentication/authorisation controls are incomplete.

WHY 3?

Why are the controls incomplete?

→ The cybersecurity requirement did not clearly define the required access-control behaviour.

WHY 4?

Why was the requirement unclear?

→ Cybersecurity analysis was not sufficiently connected to the system design process.

WHY 5?

Why wasn't it connected?

→ Cybersecurity responsibilities and review gates were not clearly embedded into the project lifecycle.

ROOT CAUSE

Not simply "weak authentication."

The deeper organisational cause may be:

Insufficient integration of cybersecurity requirements into the engineering lifecycle.

This is an excellent lesson for senior participants:

Fixing the vulnerability is not always the same as fixing the cause.

THE "FISHBONE → 5 WHY → TARA" COMBINATION

I would teach the participants this three-stage method:

1. FISHBONE

Where could the vulnerability come from?

↓

2. 5 WHY

Why does the vulnerability exist?

↓

3. TARA

What could happen, how serious is it, and what cybersecurity controls are required?

Then:

CONTROL → REQUIREMENT → VERIFY → IMPLEMENT

So the complete classroom framework becomes:

FIND → UNDERSTAND → ASSESS → CONTROL → VERIFY

DON'T STOP AT "WHAT CAN GO WRONG?"

ALWAYS FINISH WITH "WHAT WILL WE DO ABOUT IT?"

That ensures every participant leaves the exercise with an actionable cybersecurity requirement or improvement action, rather than just a list of vulnerabilities.

13. "WHERE WOULD YOU STOP THE ATTACK?"

Internet

↓

Cellular

↓

Uconnect

↓

Internal Network

↓

Gateway

↓

ECU

↓

Vehicle Function

"You can install only THREE security controls. Where would you place them?"

Each group must justify its choices.

14. RED TEAM / BLUE TEAM EXERCISE

RED TEAM

Their task:

Identify possible pathways by which compromise of a connected component could propagate toward vehicle functions.

They identify:

☐ External interface
☐ Vulnerable component
☐ Trust boundary
☐ Network pathway
☐ Privilege escalation
☐ Target asset
☐ Potential damage

BLUE TEAM

Their task:

Design controls that prevent the propagation.

They identify:

☐ Authentication
☐ Authorization
☐ Network segmentation
☐ Gateway filtering
☐ Secure boot
☐ Message validation
☐ IDS
☐ Logging
☐ Vulnerability management
☐ Incident response

15. THE "WHAT IF?" EXERCISE

Give participants six hypothetical modifications.

Scenario 1

What if the infotainment system had no connection to the vehicle-control network?

Would the attack path change?

Scenario 2

What if the gateway filtered messages between infotainment and critical ECUs?

Would the potential impact change?

Scenario 3

What if every ECU authenticated critical commands?

What changes?

Scenario 4

What if the vulnerability was discovered before SOP?

What lifecycle activities should have detected/addressed it?

Scenario 5

What if the vulnerability was discovered after 500,000 vehicles were sold?

What changes?

Scenario 6

What if the vulnerability exists in a Tier-1 supplier component?

Who needs to be involved?

This last question naturally leads into:

OEM ↔ Tier-1 ↔ Tier-2 ↔ Software Supplier

and supplier cybersecurity management.

16. INCIDENT RESPONSE EXERCISE

Now change the scenario:

Monday 09:00: Security researchers report a vulnerability.

Monday 10:00: Engineering confirms the affected component.

Monday 14:00: 250,000 vehicles may be affected.

Tuesday: A workaround is identified.

Wednesday: A permanent software update is being developed.

Ask:

What do you do?

First 24 hours

☐ Establish incident team
☐ Validate vulnerability
☐ Identify affected products
☐ Assess severity
☐ Identify affected software versions
☐ Contact relevant suppliers
☐ Assess exploitation evidence
☐ Define containment measures
☐ Establish management communication

First 7 days

☐ Root-cause analysis
☐ TARA reassessment
☐ Develop mitigation
☐ Develop patch
☐ Security testing
☐ Regression testing
☐ Deployment planning
☐ Customer/service communication as appropriate

Longer term

☐ Lessons learned
☐ Update TARA
☐ Update cybersecurity requirements
☐ Update architecture
☐ Update supplier controls
☐ Update security testing
☐ Update cybersecurity knowledge base

17. WHAT ACTUALLY HAPPENED AFTER THE RESEARCH?

This is important because the case should not end with "hackers controlled the Jeep."

The industry response is equally valuable.

The researchers had shared aspects of their findings with Chrysler before the public demonstration, allowing the company to prepare a software fix. FCA subsequently implemented network-level measures and issued a safety recall for approximately 1.4 million vehicles with affected Uconnect configurations.

NHTSA's investigation documents that FCA and its network provider blocked the relevant remote access pathway and that further security evaluation and regression testing identified additional vulnerabilities addressed through network or software changes. (NHTSA)

The FCA recall covered specified 2013–2015 vehicles equipped with certain Uconnect 8.4-inch systems, including the 2014–2015 Jeep Cherokee.

18. THE ISO/SAE 21434 CONNECTION

Now ask:

"If ISO/SAE 21434 principles had been applied rigorously throughout the lifecycle, where could this type of risk have been identified or reduced?"

Build the following mapping with participants.

Jeep Case Lesson	ISO/SAE 21434 Activity
External connectivity	Item Definition
Uconnect interface	Attack Surface Analysis
Internal network connectivity	Architecture Analysis
Vulnerability	Cybersecurity Risk Management
Vehicle-control exposure	Damage Scenario
Attack pathway	Threat Scenario / Attack Path
Potential safety/operational consequence	Impact Assessment
Network isolation	Cybersecurity Concept
Security controls	Cybersecurity Requirements
Security testing	Verification/Validation
Vulnerability discovery	Post-development cybersecurity activities
Software update	Cybersecurity maintenance
Recall	Incident/Vulnerability response
Supplier component	Supplier Cybersecurity Management
Lessons learned	Continuous improvement

19. THE BIGGEST LESSON

"The attack did not begin with the brakes."

It began with connectivity.

Then:

CONNECTIVITY

↓

SOFTWARE

↓

VULNERABILITY

↓

COMPROMISED COMPONENT

↓

NETWORK ACCESS

↓

VEHICLE SYSTEM

↓

PHYSICAL CONSEQUENCE

That is the perfect introduction to cyber-physical risk.

20. PARTICIPANT TAKEAWAY CARD

CONNECTED VEHICLE CYBERSECURITY — 10 QUESTIONS

Before approving a connected automotive system, ask:

☐ 1. What are our external interfaces?

☐ 2. What assets are reachable through those interfaces?

☐ 3. What happens if the connected component is compromised?

☐ 4. What trust boundaries exist?

☐ 5. Can compromise propagate to another ECU?

☐ 6. Is the communication path necessary?

☐ 7. Is the communication appropriately authenticated/authorised?

☐ 8. Can abnormal behaviour be detected?

☐ 9. Can the affected software be updated securely?

☐ 10. Can we demonstrate evidence that the controls work?

21. FINAL FACILITATOR QUESTION

"If the infotainment system in our next vehicle programme were completely compromised tomorrow, what could the attacker reach?"

5 minutes.

"What should the attacker NOT be able to reach—and what architectural control guarantees that?"

This takes participants from awareness → TARA → architecture → cybersecurity requirements, which is exactly the behaviour you want from an ISO/SAE 21434 workshop.

Recommended reference material

The original Miller–Valasek research paper, "Remote Exploitation of an Unaltered Passenger Vehicle," is particularly useful for the facilitator because it documents the research methodology and architecture at a technical level. (IOActive)

The 2015 Black Hat presentation provides the researchers' own technical presentation of the research and its limitations. (infocondb.org)

For a later reflection, Miller and Valasek's 2025 USENIX retrospective, "Ten Years After the Jeep Hack," is useful for discussing what the automotive cybersecurity ecosystem learned during the decade following the demonstration. (USENIX)

Facilitator safety note: For an OEM classroom, use the case to analyse assets, attack surfaces, trust boundaries, TARA, controls and lifecycle response. Do not reproduce the exploit, scan live vehicles, inject CAN messages into production systems, or attempt remote access to vehicles.

MODULE 2

ISO/SAE 21434 — Understanding the Framework

Duration

45 minutes

Introduce:

Four lifecycle perspectives

1. Concept

↓

2. Product Development

↓

3. Production

↓

4. Operations / Maintenance / Decommissioning

ISO describes the standard as covering the cybersecurity lifecycle of vehicle E/E systems and their components/interfaces.

ACTIVITY 2

"Where Does Cybersecurity Begin?"

Give teams 10 cards:

Vehicle concept
Supplier selection
ECU design
Software development
Testing
Production
Vehicle delivery
OTA update
Service centre
End-of-life

Arrange these cards according to cybersecurity responsibility.

Cybersecurity is not a testing activity added at the end.

It must be considered throughout the lifecycle.

ISO/SAE 21434 WORKPLACE MAPPING

Activity	Current practice	Gap	Owner	Evidence
Cybersecurity governance
Item definition
TARA
Cybersecurity goals
Requirements
Verification
Validation
Production
Incident response
Supplier management

Takeaway

Each participant identifies three gaps in their current project/process.

MODULE 3

AUTOMOTIVE ATTACK SURFACE MAPPING

Duration

60 minutes

Attack surfaces

In automotive cybersecurity, a vehicle is no longer an isolated mechanical system—it is a connected ecosystem of in-vehicle networks, external interfaces, software, mobile applications, cloud services, manufacturing systems, and service tools. Each connection creates an attack surface that must be identified, assessed, protected, and monitored throughout the vehicle lifecycle under ISO/SAE 21434. The table below gives a quick practical understanding of each interface with an automotive example.

Interface / System	Short Introduction	Automotive Example	Cybersecurity Concern
CAN	Controller Area Network used for communication between ECUs.	Engine ECU ↔ Transmission ECU ↔ ABS ECU	Unauthorized messages, spoofing, lack of authentication
CAN-FD	Enhanced CAN supporting larger data payloads and higher data rates.	ADAS, powertrain and body-control communication	Message injection, compromised ECU communication
Ethernet	High-speed networking used for modern vehicle systems and diagnostics.	ADAS cameras, infotainment, gateway, zonal controllers	Network intrusion, unauthorized access, malware
OBD	On-Board Diagnostics interface used to access vehicle diagnostic information.	Technician connects a diagnostic scanner during service	Unauthorized diagnostic access, ECU manipulation
USB	Physical interface for data transfer, media and software updates.	USB drive used to update infotainment software	Malicious files, infected USB devices, unauthorized updates
Bluetooth	Short-range wireless communication between vehicle and devices.	Driver connects smartphone to infotainment	Unauthorized pairing, device compromise, data leakage
Wi-Fi	Wireless network connectivity for vehicle occupants and vehicle systems.	In-car Wi-Fi hotspot or wireless software update	Rogue access, credential theft, network intrusion
Cellular	Mobile-network connectivity enabling remote vehicle services.	Connected vehicle communicates with OEM cloud through 4G/5G	Remote attack, unauthorized commands, service disruption
GNSS	Satellite-based positioning system used for navigation and location services.	GPS/GNSS provides vehicle location to navigation system	Spoofing, jamming, manipulated location data
Keyless Systems	Electronic systems that authenticate a key/fob without conventional mechanical keys.	Passive keyless entry and push-button start	Relay attacks, unauthorized vehicle access
Mobile Apps	Smartphone applications that allow owners to interact with vehicles remotely.	Lock/unlock vehicle or check vehicle status through an app	Account takeover, API abuse, unauthorized commands
Cloud	Backend infrastructure supporting connected-vehicle services and data.	OEM cloud receives vehicle telemetry and sends authorised services	API attacks, data breaches, account compromise
OTA	Over-the-Air technology for remotely delivering software/firmware updates.	OEM remotely updates infotainment or ECU software	Malicious update, compromised update server, rollback attacks
Charging Infrastructure	EV charging ecosystem connecting vehicle, charger and backend systems.	EV communicates with an AC/DC charger and charging network	Authentication attacks, charging manipulation, data exposure
Diagnostic Tools	Software/hardware used by technicians to diagnose and configure vehicles.	Workshop technician uses OEM diagnostic equipment	Unauthorized ECU access, credential misuse
Supplier Software	Software, firmware or libraries supplied by Tier-1/Tier-2 vendors.	Supplier provides ECU firmware to an OEM	Vulnerabilities, insecure components, supply-chain compromise
Manufacturing Equipment	Production machines and systems that interact with vehicle ECUs/software.	ECU programming station flashes firmware during assembly	Unauthorized firmware, compromised programming station
Service Tools	Tools used during maintenance, repair, calibration and configuration.	ADAS calibration or ECU configuration tool	Privilege misuse, unauthorized configuration, infected tools

A simple way to remember the attack surface

Vehicle Cybersecurity = Inside the Vehicle + Outside the Vehicle + Vehicle Lifecycle

Area	Examples
Inside Vehicle	CAN, CAN-FD, Ethernet, ECUs, OBD
Wireless / External	Bluetooth, Wi-Fi, Cellular, GNSS, Keyless
Digital Ecosystem	Mobile Apps, Cloud, OTA
EV Ecosystem	Charging Infrastructure
Service Lifecycle	Diagnostic Tools, Service Tools
Supply Chain	Supplier Software
Manufacturing	Manufacturing Equipment

Training takeaway:

“Every interface is a potential entry point; every connection needs a reason, a boundary, a control and evidence that the control works.”

This is an excellent starting point for an ISO/SAE 21434 Attack Surface Identification activity: give each participant/team one interface and ask them to identify Entry Point → Asset → Threat → Attack Path → Damage Scenario → Cybersecurity Control.

ACTIVITY 3

Attack Surface Bingo

Give participants a vehicle architecture.

They have 10 minutes to identify:

5 external interfaces
5 internal interfaces
3 trust boundaries
3 high-value assets
3 possible attack paths
3 security controls

First team completing the matrix gets a "Cybersecurity Architect" challenge card.

WORKSHEET — ATTACK SURFACE MAP

Component	Interface	Connected to	Trust Level	Potential Threat
TCU	Cellular	Cloud	External
Infotainment	Bluetooth	Mobile	External
Gateway	CAN	ECU	Internal
ADAS ECU	Ethernet	Sensor	Internal
OTA Server	Internet	Vehicle	External

MODULE 4

ITEM DEFINITION

Duration

60 minutes

This is one of the most important practical exercises.

Participants select one vehicle function.

Recommended options:

Team A - Connected infotainment

Team B – ADAS - Advanced Driver Assistance Systems, which are electronic safety technologies in modern cars designed to prevent crashes by helping drivers sense hazards or taking automated action

Team C - Digital key

Team D - Battery Management System

Team E - OTA update An over-the-air (OTA) update is the wireless delivery of new software, firmware, or operating system upgrades to a device via Wi-Fi or cellular networks

Team F – Telematics (Telematics is the integration of telecommunications and informatics (computer science) used to monitor, send, and analyze data from remote assets like cars and trucks)

HANDS-ON EXERCISE

Build an Item Definition

Each team documents:

1. Item - Connected Vehicle Telematics System

2. Function What does it do?

3. Components What ECUs/components are involved?

4. Interfaces What communicates with it?

5. Assets What needs protection?

6. Communication paths How does information flow?

7. Dependencies What external systems are required?

ITEM DEFINITION WORKSHEET

Question	Team Answer
What is the item?
What function does it provide?
Which ECUs are involved?
Which sensors?
Which networks?
Which external interfaces?
Which cloud systems?
Which mobile applications?
Which suppliers?
What are the critical assets?

MODULE 5

ASSET IDENTIFICATION & DAMAGE SCENARIOS

Duration

60 minutes

CIA + Authenticity + Accountability

Participants identify:

Confidentiality
Integrity
Availability
Authenticity
Traceability/accountability

ACTIVITY 4

"What Happens If This Is Compromised?"

Asset: Vehicle Speed Signal

What happens if an attacker modifies it?

Asset: Battery SOC

What happens if incorrect information is injected?

Asset: OTA Package

What happens if it is modified?

Asset: Digital Key

What happens if authentication is bypassed?

DAMAGE SCENARIO WORKSHEET

Asset	Compromise	Possible consequence
Speed information	Integrity loss	Incorrect vehicle behaviour
OTA package	Integrity loss	Unauthorized software
Digital key	Authenticity loss	Unauthorized access
Battery data	Integrity loss	Incorrect energy management
Location	Confidentiality loss	Privacy exposure

MODULE 6

TARA — THREAT ANALYSIS AND RISK ASSESSMENT

Duration 90 minutes

Recent automotive research continues to focus on improving TARA scalability and consistency. For example, a 2026 SAE paper from researchers associated with Tata Motors Passenger Vehicles and Tata Elxsi proposed a modular approach called MOSAIC-TARA to make TARA more reusable across ECUs, domains and vehicle platforms. (SAE Mobilus)

TARA STEP-BY-STEP

STEP 1 Identify asset.

STEP 2 Identify damage scenario.

STEP 3 Identify threat scenario.

STEP 4 Identify attack path.

STEP 5 Evaluate impact.

STEP 6 Evaluate attack feasibility.

STEP 7 Determine risk.

STEP 8 Define treatment.

STEP 9 Define cybersecurity goal.

STEP 10 Trace to cybersecurity requirements.

HANDS-ON TARA CASE

CASE:OTA Software Update

Asset: Vehicle software image

Threat: Unauthorized modification of software package.

Possible attack path:

Attacker

↓

Compromised Credential

↓

Backend

↓

OTA Infrastructure

↓

Vehicle

↓

ECU

Teams determine:

Damage scenario
Impact
Attack feasibility
Risk
Treatment
Cybersecurity goal

TARA WORKSHEET

Field	Participant Response
Asset
Damage scenario
Threat scenario
Attack path
Impact
Attack feasibility
Risk
Treatment
Cybersecurity goal
Security requirement
Verification method

MODULE 7

RISK TREATMENT

Duration 45 minutes

AVOID Remove the risky function/interface.

REDUCE Add security controls.

TRANSFER Shift responsibility through contractual/supplier arrangements.

ACCEPT Accept residual risk based on documented decision authority.

ACTIVITY 5

Cybersecurity Board Meeting

Give each team a TARA.

One participant becomes:

Cybersecurity Manager

Product Manager

Engineering Manager

Cost Controller

Safety Representative

Supplier

They must negotiate:

What should we do with this cybersecurity risk?

This develops the real-world skill of risk-based decision making rather than simply filling a TARA spreadsheet.

DAY 1 FINAL CHALLENGE

"Secure This Vehicle"

Each team receives:

A connected vehicle launching in six months.

Given:

80 ECUs
OTA
Smartphone application
Cloud connectivity
ADAS
Digital key
EV battery
Multiple Tier-1 suppliers

20 minutes to identify:

Top 5 cybersecurity concerns and Top 5 actions before SOP.

DAY 1 KEY TAKEAWAYS

☐ Attack Surface Map
☐ Item Definition
☐ Asset Register
☐ Damage Scenario Register
☐ TARA Worksheet
☐ Risk Treatment Matrix
☐ Cybersecurity Gap List

DAY 2

FROM TARA TO CYBERSECURITY ENGINEERING & IMPLEMENTATION

DAY 2 FLOW

Time	Module
09:00–09:20	Day 1 Recap
09:20–10:20	8. Cybersecurity Goals & Requirements
10:20–11:15	9. Cybersecurity Concept & Architecture
11:15–11:30	Break
11:30–12:30	10. Secure Development & Verification
12:30–13:15	11. Supplier Cybersecurity
13:15–14:00	Lunch
14:00–15:00	12. OTA & Software Update Security
15:00–15:45	13. Vulnerability & Incident Management
15:45–16:00	Break
16:00–16:45	14. Production & Operations
16:45–17:20	15. UN R155/R156 + Cybersecurity Management
17:20–18:00	16. 60-Day Implementation Roadmap + Capstone

MODULE 8

CYBERSECURITY GOALS & REQUIREMENTS

Duration 60 minutes

Threat

↓

Risk

↓

Cybersecurity Goal

↓

Cybersecurity Requirement

↓

Technical Implementation

↓

Verification

ACTIVITY 6

Requirement Writing Challenge

"The system must be secure."

"The ECU should have good authentication."

"The software should prevent hacking."

Teams rewrite them into:

specific + testable + traceable requirements.

REQUIREMENT WORKSHEET

Threat	Cybersecurity Goal	Requirement	Verification
Unauthorized ECU access	Prevent unauthorized access
Modified OTA package	Ensure software integrity
Diagnostic abuse	Restrict diagnostic access
Credential compromise	Protect authentication

MODULE 9

CYBERSECURITY ARCHITECTURE

Duration 60 minutes

Discuss:

Secure gateway
Segmentation
Secure communication
Authentication
Authorization
Cryptography
Secure boot
Hardware Security Module
Intrusion Detection
Logging
Key management
Certificate management
Firewalling
Secure diagnostics

ACTIVITY 7

DESIGN A SECURE VEHICLE

Components

Here is a simple, training-friendly version you can use directly in your ISO/SAE 21434 automotive cybersecurity module:

Component / System	Short Definition	Automotive Example	Cybersecurity Relevance
TCU	Telematics Control Unit – connects the vehicle to external networks such as cellular and cloud services.	Sends vehicle location and diagnostic data to the OEM cloud through 4G/5G.	Remote access, authentication, data protection, cellular attack surface
Gateway	A network controller that manages and filters communication between different vehicle networks.	Allows selected messages to pass between CAN and Ethernet networks.	Critical security boundary; message filtering, segmentation and access control
ADAS ECU	Electronic Control Unit responsible for Advanced Driver Assistance System functions.	Processes radar/camera inputs for Adaptive Cruise Control or Lane Keeping Assist.	Sensor spoofing, malicious inputs, unauthorized commands, data integrity
Infotainment	Vehicle system providing entertainment, navigation, connectivity and driver/passenger information.	Touchscreen system providing navigation, music, Bluetooth and smartphone integration.	Large attack surface through USB, Bluetooth, Wi-Fi and cellular connectivity
Powertrain ECU	ECU that controls or manages vehicle propulsion-related functions.	Engine ECU controls fuel injection, ignition and engine operation.	Unauthorized commands could affect vehicle performance or availability
BMS	Battery Management System – monitors and controls an EV's battery system.	Monitors battery voltage, temperature, State of Charge (SoC) and charging conditions.	Manipulated battery data, unauthorized commands, charging and safety impacts
Cloud	Remote computing infrastructure that stores, processes and exchanges vehicle-related data and services.	OEM cloud receives vehicle telemetry and supports connected-car services.	API security, authentication, data protection and unauthorized remote access
Mobile App	Smartphone application that allows users to access vehicle-related services remotely.	Owner checks battery status or locks/unlocks the vehicle using a smartphone.	Account takeover, insecure APIs, unauthorized vehicle commands and privacy risks

Mobile App → Cloud → Cellular → TCU → Gateway → Vehicle ECUs

For example:

“A simple mobile-app command such as ‘check vehicle status’ may travel through several connected components before reaching the vehicle. Each connection and trust boundary must therefore be considered during cybersecurity analysis.”

Key training question:
If the infotainment system or TCU is compromised, what should the attacker not be able to reach—and which gateway/security control prevents that?

Teams design:

A cybersecurity architecture that limits the attacker's movement.

RED TEAM vs BLUE TEAM

Red Team

Identifies:

Attack paths
Weak trust boundaries
Single points of failure
Excessive privileges
Unprotected interfaces

Blue Team

Designs:

Segmentation
Authentication
Monitoring
Access controls
Detection
Recovery

This can be performed entirely on a paper/simulation architecture, avoiding live vehicle exploitation.

MODULE 10

SECURE DEVELOPMENT, VERIFICATION & VALIDATION

Key concepts

Here is a short, training-friendly table for these automotive cybersecurity verification and testing techniques:

Technique	Short Definition	Automotive Example	Main Purpose
Secure Coding	Developing software using practices that prevent common security weaknesses.	ECU software validates inputs before processing CAN/Ethernet data.	Prevent vulnerabilities at the source
Static Analysis	Examining source code or binaries without executing the software.	Tool detects buffer overflow or insecure function usage in ECU code.	Find coding weaknesses early
Dynamic Analysis	Testing software while it is running to identify abnormal or vulnerable behaviour.	Monitor an infotainment application while feeding different inputs.	Detect runtime security problems
Code Review	Human examination of code to identify security, quality and design issues.	Cybersecurity engineer reviews authentication and access-control code in a TCU.	Identify issues automated tools may miss
Vulnerability Scanning	Automatically checking systems, software or components for known vulnerabilities.	Scan an automotive Ethernet system for known vulnerable services or libraries.	Identify known weaknesses
Penetration Testing	Controlled security testing that attempts to exploit identified weaknesses within an authorized test environment.	Security testers assess whether an infotainment interface can be abused to cross a network boundary.	Validate real-world security resilience
Fuzz Testing	Sending large amounts of unexpected, malformed or randomised inputs to discover failures.	Send malformed diagnostic or network messages to an ECU in a test bench.	Find crashes, unexpected behaviour and input-handling weaknesses
Interface Testing	Testing communication interfaces to ensure only expected and authorized interactions occur.	Verify that a diagnostic interface cannot access functions outside its permitted scope.	Validate interface security and boundaries
Security Requirements Verification	Checking that implemented software/system controls satisfy defined cybersecurity requirements.	Requirement: “Only authenticated users can initiate a software update.” Test whether the control works as specified.	Demonstrate requirements are actually implemented
Regression Testing	Re-testing previously verified functionality after changes to ensure security controls have not been broken.	After an ECU firmware update, repeat authentication, access-control and communication-security tests.	Prevent previously fixed vulnerabilities from returning

Easy way to remember the sequence

Prevent → Inspect → Review → Scan → Attack → Stress → Verify → Re-test

Secure Coding → Prevent
Static Analysis → Inspect code
Code Review → Human review
Vulnerability Scanning → Find known weaknesses
Penetration Testing → Controlled attack simulation
Fuzz Testing → Stress with unexpected inputs
Interface Testing → Test boundaries
Security Requirements Verification → Confirm requirements
Regression Testing → Make sure fixes stay fixed

Training takeaway:

“Finding a vulnerability is not the finish line—verification must demonstrate that the risk has been addressed and remains addressed after every change.”

HANDS-ON

"Find the Cybersecurity Defect"

Provide participants with a fictional ECU development package containing:

Architecture
Requirements
Interface list
Test cases
Supplier declaration

Teams identify:

☐ Missing requirement
☐ Missing authentication
☐ Excessive privilege
☐ Unprotected interface
☐ Missing logging
☐ Missing test case
☐ Unclear ownership
☐ Supplier evidence gap

MODULE 11

SUPPLIER & SUPPLY-CHAIN CYBERSECURITY

OEM → Tier 1 → Tier 2 → Software supplier → Open-source software → Cloud

Supplier cybersecurity checklist

☐ Supplier TARA available
☐ Item definition available
☐ Cybersecurity goals defined
☐ Security requirements traced
☐ Vulnerability management process
☐ SBOM availability
☐ Secure development evidence
☐ Security testing evidence
☐ Incident notification process
☐ Patch management
☐ Access control
☐ Cryptographic key management
☐ End-of-life plan

CASE STUDY

Supplier Software Compromise

Scenario:

A Tier-1 supplier provides an ECU.

Three months before SOP:

A critical vulnerability is discovered in a third-party software component.

Ask:

What happens?

Participants must determine:

Who must be informed?
Who owns the risk?
How is the vulnerability assessed?
Is the ECU affected?
Is the vehicle affected?
Does software need modification?
How is the change verified?
What evidence must be retained?

MODULE 12

OTA CYBERSECURITY

Duration 60 minutes

A 2026 SAE technical paper specifically examines cybersecurity of automotive OTA update systems and software stores in relation to ISO/SAE 21434, UN R155 and UN R156, including Uptane-based approaches. (SAE Mobilus)

ACTIVITY 8

"Secure the OTA Pipeline"

Developer

↓

Build System

↓

Software Repository

↓

Release

↓

OTA Server

↓

Vehicle

↓

ECU

Where could an attacker interfere?

Then identify controls at every stage.

OTA SECURITY CHECKLIST

Development

☐ Source control
☐ Developer authentication
☐ Code review
☐ Build security

Release

☐ Signing
☐ Integrity verification
☐ Version control

Distribution

☐ Authentication
☐ Authorization
☐ Secure communication

Vehicle

☐ Package verification
☐ Secure installation
☐ Rollback/recovery
☐ Logging

MODULE 13

VULNERABILITY & INCIDENT MANAGEMENT

Scenario

A researcher reports a vulnerability affecting an ECU already installed in 250,000 vehicles.

Teams develop:

FIRST 24 HOURS

☐ Validate report
☐ Identify affected component
☐ Establish incident team
☐ Assess severity
☐ Identify affected vehicles
☐ Freeze relevant releases if necessary
☐ Start supplier coordination

FIRST 7 DAYS

☐ Root cause
☐ TARA reassessment
☐ Mitigation
☐ Patch development
☐ Test
☐ Deployment plan

LONGER TERM

☐ Lessons learned
☐ Update cybersecurity knowledge
☐ Update requirements
☐ Update TARA
☐ Update architecture/process

MODULE 14

PRODUCTION & OPERATIONS

Manufacturing Attack Surfaces in Automotive Cybersecurity

Automotive cybersecurity does not stop at the vehicle. Manufacturing and production environments can become attack paths into vehicle software, ECUs, production systems, and intellectual property. A compromised programming station, engineering laptop, supplier connection, or calibration system could potentially introduce malicious or unauthorized changes during vehicle production. Therefore, manufacturing cybersecurity should be considered as part of the vehicle's broader cybersecurity lifecycle.

Manufacturing Attack Surface	Short Definition	Automotive Example	Key Cybersecurity Concern
Programming Stations	Systems used to load software or configuration into vehicle ECUs during production.	Station programs firmware into an engine or body-control ECU.	Unauthorized or malicious firmware
ECU Flashing	Process of installing or updating ECU firmware/software.	Production line flashes approved software into 500 ECUs.	Wrong, outdated or tampered software
Diagnostic Tools	Tools used to diagnose, configure or communicate with vehicle systems.	Technician uses an OEM diagnostic device to configure an ECU.	Unauthorized commands or access
Production Networks	Networks connecting manufacturing machines, computers, PLCs and production systems.	Factory Ethernet connects assembly-line controllers and servers.	Lateral movement and production disruption
Engineering Laptops	Computers used by engineers for development, testing, configuration and troubleshooting.	Engineer connects a laptop to an ECU test environment.	Malware, credentials and sensitive data exposure
USB Devices	Removable storage used to transfer software, configuration files or data.	USB drive transfers ECU calibration data to a production station.	Malware or unauthorized files
Supplier Connections	Digital connections between OEM facilities and suppliers.	Tier-1 supplier remotely provides software or production support.	Supply-chain compromise and unauthorized access
MES	Manufacturing Execution System that monitors and manages production activities.	MES tracks vehicle build status and ECU programming results.	Unauthorized access, data manipulation or production disruption
Manufacturing Servers	Servers supporting production applications, software repositories and manufacturing data.	Server stores approved ECU firmware packages.	Firmware tampering, ransomware, data theft
Test Equipment	Equipment used to test vehicle components and systems during manufacturing.	End-of-line tester verifies ECU communication and functionality.	Unauthorized test commands or compromised equipment
Calibration Systems	Systems used to configure and calibrate vehicle components or ECUs.	ADAS calibration equipment configures camera/radar parameters.	Incorrect or unauthorized calibration

Simple Attack Path

A useful training scenario is:

Supplier Software → Manufacturing Server → Programming Station → ECU Flashing → Vehicle

Ask participants:

“If an attacker compromises the manufacturing environment, what could potentially reach the vehicle—and where should we place controls to stop the attack?”

Manufacturing Cybersecurity Control Points

Stage	Example Control
Software received	Supplier verification + digital signatures
Software stored	Access control + integrity protection
Software transferred	Secure communication + authentication
ECU flashing	Authorised programming + firmware validation
Production network	Network segmentation
USB usage	Controlled/approved removable media
Engineering laptops	Endpoint protection + least privilege
Supplier access	MFA + restricted access + monitoring
Calibration	Authorised configurations + change control
Final vehicle	Software integrity verification + production cybersecurity records

Key message for ISO/SAE 21434 training:

“The vehicle can inherit cybersecurity risk from the factory. Secure the software before it becomes part of the vehicle.”

ACTIVITY 9

"Secure the Production Line"

Scenario:

An operator uses a USB device to update ECU software during production.

Teams identify:

Risks

Malware
Wrong software version
Unauthorized software
Credential compromise
Configuration error
Production disruption

Controls

☐ Approved media
☐ Access control
☐ Software verification
☐ Version control
☐ Logging
☐ Segmentation
☐ Endpoint protection
☐ Change control

MODULE 15

ISO/SAE 21434 + UN R155/R156

(UNECE)

IMPORTANT 2026 INDIA CASE

A very relevant discussion case for an Indian OEM is the July 2026 report that India's Ministry of Heavy Industries urged automobile and parts manufacturers to audit connected-vehicle and EV software/devices, with particular attention reported around battery communication interfaces, weak authentication, unsecured defaults and OTA pathways. (Business Standard)

Workshop question

"If your organisation received such an advisory tomorrow, what evidence would you need to produce?"

Participants create:

Cybersecurity Evidence Pack

MODULE 16

CYBERSECURITY CAPSTONE

"90-DAY VEHICLE CYBERSECURITY LAUNCH"

Each team receives this situation:

Your company is launching a connected EV platform in 90 days.

Architecture includes:

ADAS
OTA
TCU
Mobile application
Cloud
BMS
Digital key
Infotainment
Multiple Tier-1 suppliers

Teams must produce:

Deliverable 1 Attack Surface Map

Deliverable 2 Item Definition

Deliverable 3 Top 10 Assets

Deliverable 4 Top 5 Damage Scenarios

Deliverable 5 TARA

Deliverable 6 Top Cybersecurity Goals

Deliverable 7 Top Cybersecurity Requirements

Deliverable 8 Security Architecture

Deliverable 9 Supplier Controls

Deliverable 10 Incident Response Plan

Deliverable 11 OTA Security Plan

Deliverable 12 90-Day Action Plan

PARTICIPANT TAKEAWAY KIT

1. Automotive Cybersecurity Daily Checklist

Before starting work

☐ What asset am I protecting?

☐ What interface am I working on?

☐ Who can access it?

☐ What happens if integrity is compromised?

☐ What happens if availability is lost?

☐ What external dependency exists?

☐ What supplier is involved?

☐ Has the cybersecurity requirement changed?

DAILY CYBERSECURITY "5 QUESTIONS"

Participants can use this every day:

1. ASSET What am I protecting?

2. ENTRY How can someone reach it?

3. IMPACT What happens if it is compromised?

4. CONTROL What prevents/detects/reduces the risk?

5. EVIDENCE Can I prove that the control works?

A very practical behavioural takeaway.

CYBERSECURITY PROJECT GATE CHECKLIST

☐ Item Definition complete

☐ Asset identification complete

☐ TARA complete

☐ Cybersecurity goals approved

☐ Cybersecurity requirements defined

☐ Architecture reviewed

☐ Supplier requirements communicated

☐ Security implementation verified

☐ Testing completed

☐ Vulnerabilities addressed

☐ Residual risk documented

☐ Cybersecurity case/evidence completed

IMPLEMENTATION ROADMAP

IMMEDIATE — WITHIN 24–48 HOURS

Every participant selects one real project/system.

Action 1 Identify one asset.

Action 2 Identify its interfaces.

Action 3 Identify one damage scenario.

Action 4 Identify one threat scenario.

Action 5 Identify one existing control.

Action 6 Identify one gap.

Action 7 Assign an owner.

15-DAY ROADMAP

Individual

☐ Complete attack-surface map

☐ Complete preliminary asset register

☐ Conduct mini-TARA

☐ Identify top 5 cybersecurity risks

☐ Review supplier dependencies

Team

☐ Conduct cybersecurity review meeting

☐ Identify missing requirements

☐ Identify missing evidence

☐ Review access controls

30-DAY ROADMAP

Engineering

☐ Complete formal TARA

☐ Review architecture

☐ Map cybersecurity goals

☐ Trace requirements

☐ Identify security test cases

Supplier Management

☐ Review supplier cybersecurity evidence

☐ Identify supplier gaps

☐ Establish vulnerability notification process

60-DAY ROADMAP

Organisation

☐ Establish cybersecurity governance

☐ Establish project cybersecurity gates

☐ Standardise TARA templates

☐ Establish supplier cybersecurity checklist

☐ Establish vulnerability-management workflow

☐ Establish incident-response workflow

☐ Create cybersecurity evidence repository

☐ Conduct cybersecurity awareness sessions

ONGOING

MONTHLY

☐ Vulnerability review

☐ Open-risk review

☐ Supplier cybersecurity review

☐ Incident review

☐ New threat review

☐ Security testing status

QUARTERLY

☐ TARA reassessment

☐ Architecture review

☐ Cybersecurity maturity assessment

☐ Supplier assessment

☐ Incident simulation

☐ OTA security review

☐ Lessons learned

ANNUALLY

☐ Cybersecurity governance review

☐ Organisation-wide assessment

☐ Training refresh

☐ Threat landscape review

☐ Incident-response exercise

☐ Lifecycle/decommissioning review

"CYBERSECURITY GEAR SHIFT"

G — GOVERN Cybersecurity governance

E — EXAMINE Attack surface + assets

A — ASSESS TARA

R — RESPOND Risk treatment

S — SECURE Requirements + architecture

H — HARDEN Implementation + testing

I — IDENTIFY Monitoring + vulnerabilities

F — FIX Incident response

T — TRACE Evidence + continuous improvement

GEAR SHIFT = move cybersecurity from theory into engineering practice.

MOVIES / CINEMA AS TRAINING TRIGGERS

1. 2.0 — Indian/Tamil Cinema

Use the technology/AI theme to ask:

"What happens when an intelligent connected system behaves outside its intended boundaries?"

Connect to:

Connected systems
AI
Autonomous behaviour
Trust
System control

· This is a particularly good transition into ISO 26262 + ISO/SAE 21434.

2. Enthiran / Robot

Use selected technology-related scenes to introduce:

"Technology capability ≠ technology security."

Discussion:

What happens when capability increases faster than governance?

3. Irumbu Thirai

Useful for:

Identity
Digital information
Cybercrime
Social engineering
Data protection

"Where is the weakest link—the technology or the human?"

4. Kee

Useful for:

Connected devices
AI
Digital identity
Cyberattack concepts

5. Bollywood: 2.0 / technology-focused cinema

The broader technology theme can be used to introduce:

"As vehicles become software-defined, cybersecurity becomes a product characteristic."

OPTIONAL HOLLYWOOD CLIPS

For vehicle-specific cybersecurity, Fast & Furious 8 provides a highly recognizable visual trigger involving connected vehicles being manipulated remotely.

Don't present the movie scenario as technically accurate.

Ask:

"Which parts are Hollywood fiction and which underlying attack concepts are realistic?"

This makes a very engaging cybersecurity discussion.

NEWS & CURRENT INDUSTRY CASES

CASE 1 — INDIA: CONNECTED VEHICLES

The July 2026 Indian government/OEM advisory reported by Business Standard is particularly relevant for this audience because it connects cybersecurity directly to India's automotive industry, including connected vehicles and EVs. (Business Standard)

Classroom question

"If our OEM were asked to audit every connected vehicle today, where would we start?"

CASE 2 — CYBER RESILIENCE IN INDIA

Deloitte India announced ConnectSafe in March 2026, describing a facility designed to simulate cyber threats across connected ecosystems including automotive and industrial environments. (Deloitte)

Discussion

Ask:

Prevention alone or resilience?

Then introduce:

Prevent → Detect → Respond → Recover → Learn

RESEARCH PAPERS FOR ADVANCED PARTICIPANTS

These are particularly useful as post-training reading.

1. MOSAIC-TARA — 2026

Goyal et al., Tata Motors Passenger Vehicles / Tata Elxsi

A modular TARA methodology intended to improve scalability and reuse across ECUs and vehicle platforms. (SAE Mobilus)

Excellent for:

Advanced TARA workshop

2. Automotive OTA Cybersecurity — 2026

Cybersecurity in Automotive OTA Update Systems and Automotive Software Stores

Useful for:

OTA
Software update security
Uptane
R155
R156
Attack vectors

3. TARA 2.0 — IEEE

Research on Threat Analysis and Risk Assessment for connected and automated vehicles, including challenges associated with highly automated vehicles. (IEEE Xplore)

Excellent for:

Advanced TARA discussion

4. STRIDE-based automotive cybersecurity

A 2023 Computers & Security study applied STRIDE, attack-tree analysis and CVSS to automotive scenarios, including ADAS. (ScienceDirect)

Excellent exercise:

STRIDE vs TARA

5. Enhanced TARA for Heavy-Duty Vehicles

A 2025 Expert Systems with Applications paper examined an enhanced TARA approach for heavy-duty vehicles using fuzzy analytic hierarchy methods. (ScienceDirect)

Useful if the organisation has:

Trucks
Buses
Commercial vehicles

6. CyberROAD

Research on an automotive cybersecurity risk-assessment ontology aligned with ISO/SAE 21434:2021. (ScienceDirect)

7. Supplier/OEM TARA Orchestration

A 2026 paper examines coordination of TARA across vehicle manufacturers and suppliers in software-defined vehicles. (ScienceDirect)

This is particularly valuable for an OEM because cybersecurity does not stop at the OEM boundary.

ADVANCED ACTIVITY

OEM vs TIER-1 CYBERSECURITY NEGOTIATION

Scenario

OEM says: "Your ECU has a cybersecurity risk."

Supplier says: "Our ECU is secure. The problem is the vehicle architecture."

Participants are divided into:

OEM Cybersecurity

Tier-1 Supplier

Vehicle Architecture

Functional Safety

Quality

Project Management

You must resolve:

Who owns the risk?
What evidence is required?
What changes are needed?
What residual risk remains?
Who signs off?

This directly mirrors the collaborative reality of modern vehicle cybersecurity.

FINAL PARTICIPANT WORKSHEET

MY 60-DAY CYBERSECURITY COMMITMENT

My project/system: ______________________

Asset: ______________________

Biggest cybersecurity risk: ______________________

Current control: ______________________

Gap: ______________________

Action: ______________________

Owner: ______________________

Deadline: ______________________

24–48 hours

15 days

30 days

60 days

Ongoing

FINAL "TAKE BACK TO WORK" CARD

Give every participant a one-page card:

BEFORE I DESIGN - Have I identified the assets?

BEFORE I CONNECT - Have I identified the attack surface?

BEFORE I RELEASE - Have I completed TARA?

BEFORE I APPROVE - Are cybersecurity requirements verified?

BEFORE SOP - Is residual risk documented?

AFTER SOP - How will we monitor vulnerabilities?

AFTER AN INCIDENT - What did we learn?

THE BIG MESSAGE OF THE TWO DAYS

VEHICLE CYBERSECURITY

↓

IDENTIFY THE ASSET

↓

MAP THE ATTACK SURFACE

↓

CONDUCT TARA

↓

DEFINE CYBERSECURITY GOALS

↓

DERIVE SECURITY REQUIREMENTS

↓

DESIGN ARCHITECTURE

↓

IMPLEMENT SECURITY CONTROLS

↓

VERIFY + VALIDATE + TEST

↓

PRODUCTION + DEPLOYMENT

↓

MONITOR + DETECT + RESPOND

↓

UPDATE + RECOVER

↓

CONTINUOUS TARA

↺

The key behavioural change should be:

Don't ask only, "Is the vehicle working?"
Ask "Can the vehicle continue to perform its intended function when its digital environment is under attack?"

That is the mindset shift I would want the participants to take back to the engineering floor.

1. Hollywood Movies

Movie	Year	Training Connection	Suggested Discussion
The Italian Job	2003	Connected/vehicle manipulation and technology	How can vehicle systems become attack surfaces?
Fast & Furious 8	2017	Connected cars remotely manipulated	Which parts are Hollywood fiction and which attack concepts are realistic?
Blackhat	2015	Cyberattack, critical infrastructure, malware	Attack → impact → response
Eagle Eye	2008	Connected systems, surveillance, remote control	What happens when interconnected systems are compromised?
Live Free or Die Hard	2007	Cyberattack against critical infrastructure	Cybersecurity as a national/industrial resilience issue
Enemy of the State	1998	Surveillance, tracking and privacy	Confidentiality and privacy of vehicle-generated data
The Net	1995	Identity theft and digital identity	Authentication and identity management
Hackers	1995	Hacking culture and social engineering	Human factor in cybersecurity
Sneakers	1992	Security testing and trust	Ethical security testing
Swordfish	2001	Social engineering and cybercrime	Attack chain and human vulnerabilities
Mission: Impossible – Ghost Protocol	2011	Connected technology / infrastructure	Technology dependency and cascading failures
Minority Report	2002	Autonomous/connected systems	Trust in automated systems
I, Robot	2004	AI, autonomous systems, human-machine trust	Safety vs security vs autonomy
Upgrade	2018	Connected vehicle / embedded technology	What if control of an embedded system is compromised?

⭐ Best 5 for your programme

I would actually use only these five rather than showing too many:

Fast & Furious 8 → connected vehicles

Blackhat → attack lifecycle

Eagle Eye → interconnected systems

I, Robot → autonomous systems

Sneakers → security testing

2. Bollywood / Indian Cinema

1. A Wednesday!

Connection

Cyber/terrorism/security mindset and threat response.

Activity

Show a short relevant scene and ask:

"If the threat were digital instead of physical, what would our incident-response process look like?"

2. Special 26

Connection

Social engineering, deception and human vulnerability.

Training topic

"The weakest link may not always be the technology."

Use it when introducing:

Social engineering
Insider threats
Authentication
Human factors

3. Mard Ko Dard Nahi Hota

Not directly a cybersecurity movie, but selected scenes can be used for a different discussion:

"What happens when a system behaves outside the assumptions made by its designer?"

Useful as a bridge into assumptions, unintended behaviour and risk analysis.

4. Irumbu Thirai

⭐ Strongest Indian cybersecurity choice

This is particularly suitable for your training.

The film directly deals with data theft, hacking and digital crime; contemporary coverage described it as bringing data-theft issues into mainstream Tamil cinema. (India Today)

Use it for:

Data protection
Social engineering
Identity
Credential theft
Human vulnerabilities
Cybercrime

Activity

Ask:

"If this attack happened through a connected vehicle ecosystem, which assets could be compromised?"

5. Kee

Connection

Connected technology, AI, hacking and digital manipulation.

Training question

"What happens when connectivity is designed without sufficient cybersecurity?"

6. Anegan / other technology-related Indian cinema

Use selectively for discussions around:

Identity
Data
Technology dependence
Human behaviour

Recommended Cinema Exercise

Don't simply play movie clips.

Use the:

"HOLLYWOOD vs ISO/SAE 21434" GAME

Show a 2–3 minute scene.

Then give teams this worksheet:

Movie Event	ISO/SAE 21434 Question
System is accessed	What is the attack surface?
Attacker gains access	What asset is compromised?
System behaviour changes	What is the damage scenario?
Attack propagates	What is the attack path?
Vehicle/system affected	What is the impact?
Defence activated	What cybersecurity control is required?
Recovery	How do we restore trust?

This converts entertainment into a TARA exercise.

3. Current Indian Automotive Cybersecurity News

News Case 1 — India's Centre asks OEMs to audit connected vehicles

Business Standard — July 7, 2026

This is probably the single most relevant current news article for your Indian OEM audience.

Business Standard reported that the Ministry of Heavy Industries had asked automobile and component manufacturers to audit software and devices controlling connected cars and EVs. The report specifically mentioned concerns around battery communication interfaces, unsecured defaults, weak authentication and unprotected OTA pathways. (Business Standard)

Training module

TARA + Attack Surface

Participant question

"If our organisation received this advisory today, what would we audit first?"

Teams produce:

10-point Connected Vehicle Cybersecurity Audit Checklist

News Case 2 — India's proposed automotive cybersecurity framework

Economic Times / ETAuto — June 2026

A proposed Indian regulatory roadmap reported by ETAuto describes phased cybersecurity and software-update requirements, including requirements for governance, risk assessment, monitoring and secure updates. The reported roadmap includes increasingly broad coverage of OTA-enabled and other vehicles through 2029. (ETAuto.com)

Training module

ISO/SAE 21434 + R155/R156 + Indian regulatory preparedness

Activity

Ask:

"Are we designing cybersecurity for today's vehicle—or the vehicle that will be on the road five years from now?"

News Case 3 — Who Really Secures Your EV?

Autocar Professional — September 15, 2026

A very recent discussion involving Simple Energy and HackersEra examines how cybersecurity responsibility extends beyond the OEM to Tier-1 suppliers, software partners and charging infrastructure providers. It also discusses ISO 21434, UN R155 and the growing importance of continuous monitoring. (Autocar Professional)

Training module

Supplier Cybersecurity

Role play

Divide participants into:

OEM
Tier-1
Tier-2
Software supplier
Cloud provider
Charging infrastructure provider

Question:

"Who owns the cybersecurity risk?"

This is an excellent senior-management exercise.

News Case 4 — Connected Vehicle Attack Surface

Use the Indian connected-car ecosystem as the case:

Vehicle → TCU → Cellular → Cloud → Mobile App → User

The July 2026 Business Standard report provides a particularly useful Indian context because it identifies connected services and remote vehicle functions as growing areas of exposure. (Business Standard)

Exercise

Participants identify:

6 attack surfaces

5 assets

3 damage scenarios

3 cybersecurity goals

4. Research Papers — Highly Relevant

Paper 1 — Automotive OTA Security

Cybersecurity in Automotive OTA Update Systems and Automotive Software Stores

SAE Technical Paper 2026-26-0621

Published January 2026.

This paper examines:

Automotive OTA
ISO/SAE 21434
UN R155
UN R156
Uptane
OTA threat models
Attack vectors
Mitigation strategies

(SAE Mobilus)

Use in training

Module: OTA Cybersecurity

Participant exercise

Map the attack surface of an OTA update pipeline.

Paper 2 — PeTARA

PeTARA: A privacy-enhanced threat analysis and risk assessment method for intelligent connected vehicles

Published in Journal of Information Security and Applications, 2026.

The paper extends the ISO/SAE 21434 TARA concept to integrate privacy considerations, using an Uptane OTA architecture as a case study. (ScienceDirect)

Use in training

Module: TARA

Discussion

"Should privacy be treated separately from cybersecurity—or integrated into the risk assessment?"

Paper 3 — TARA Across OEMs and Suppliers

An Orchestration Model for TARA across Vehicle Manufacturers and Suppliers in Software-Defined Vehicles

This is highly relevant to an automobile manufacturing giant because it focuses on coordinating TARA between vehicle manufacturers and suppliers in software-defined vehicles. (ScienceDirect)

Use in training

Supplier Cybersecurity Module

Activity

Give the OEM one TARA and the Tier-1 another TARA.

Ask them to reconcile the two.

Paper 4 — ThreatSurf

ThreatSurf: A method for automated Threat Surface assessment in automotive cybersecurity engineering

Microprocessors and Microsystems, 2022.

It discusses automated attack-surface assessment using:

Asset identification
Threat scenario identification
Attack-path analysis
Attack-feasibility rating

and explicitly connects the approach with ISO/SAE 21434 and UN R155. (ScienceDirect)

Use in training

Attack Surface + TARA workshop

Paper 5 — Automotive Cybersecurity Testing

Cybersecurity Testing for Automotive Domain: A Survey

This research reviews automotive cybersecurity testing approaches including:

Penetration testing
Fuzzing
Model-based testing
Testbeds
Verification and validation

It specifically discusses ISO/SAE 21434 and UNECE R155/R156. (PubMed Central (PMC))

Use in training

Verification & Validation module

Activity

Participants create:

Cybersecurity Test Plan for an ECU

Paper 6 — Attack Trees in Connected Vehicles

Identification and Verification of Attack-Tree Threat Models in Connected Vehicles

SAE Technical Paper, 2022.

The paper examines attack-tree threat modelling in connected vehicles and relates it to ISO/SAE 21434 and UN R155. (SAE Mobilus)

Use in training

Threat Modelling

Hands-on - "Compromise the OTA update."

Paper 7 — Practical TARA

Delivering Threat Analysis and Risk Assessment Based on ISO 21434: Practical and Tooling Considerations

SAE Journal article by Kamil Svancara and Martin J. Thompson.

It covers practical TARA considerations including:

System modelling
Asset identification
Attack modelling
Consequence analysis

and explains the relationship between ISO/SAE 21434 and UN R155. (SAE Mobilus)

Use in training

90-minute TARA workshop

This is particularly useful for your participants because it bridges the gap between standard language and engineering implementation.

Paper 8 — Automotive Cyber Threat Intelligence

Combining Cyber Security Intelligence to Refine Automotive Cyber Threats

Published in ACM Transactions on Privacy and Security.

The paper discusses the relationship between:

ISO/SAE 21434 → TARA → security concepts → mitigation → security testing

and examines ways to improve automotive cyber-threat analysis. (DOI)

Use in training

Threat Intelligence + Continuous Monitoring

Paper 9 — Connected & Automated Vehicle Standards

Analyses on standards and regulations for connected and automated vehicles: Identifying the certifications roadmap

Transportation Engineering, 2023.

It examines:

ISO/SAE 21434
ISO/PAS 5112
UNECE R155
UNECE R156
GDPR
Cybersecurity
Data privacy
Connected and automated vehicles

(ScienceDirect)

Use in training

Standards & Regulations Mapping

5. Best Combination for Your 2-Day Programme

Rather than overwhelming participants with 15 movies and 20 papers, I would structure the content like this:

Training Module	Movie Trigger	News/Case	Research
Automotive Cybersecurity Mindset	Fast & Furious 8	Connected vehicle attacks	ThreatSurf
Attack Surface	Eagle Eye	Indian connected-car ecosystem	ThreatSurf
Item Definition	I, Robot	Connected vehicle expansion	CAV standards paper
Asset Identification	Irumbu Thirai	Data/connected services	PeTARA
TARA	Blackhat	Indian EV security concerns	Practical TARA paper
Attack Trees	Sneakers	Connected vehicle threat	SAE Attack Tree paper
Cybersecurity Requirements	Enthiran	Indian regulatory development	Standards roadmap
Secure Architecture	2.0	Connected vehicle ecosystem	Automotive cybersecurity research
Supplier Cybersecurity	Special 26	OEM/Tier-1 responsibility	OEM-supplier TARA paper
OTA	Fast & Furious 8	Indian OTA security concerns	SAE OTA 2026
Testing	Blackhat	Vulnerability management	Automotive Testing Survey
Incident Response	A Wednesday!	Cybersecurity advisories	Cyber-threat intelligence
Production	The Italian Job	Automotive manufacturing	Automotive security research
Continuous Monitoring	Eagle Eye	EV ecosystem	PeTARA / TARA research

6. My Recommended "Movie → Module" Sequence

For maximum engagement, I would actually run the two days like this:

DAY 1

🎬 Fast & Furious 8

Question:

"Can a car really be remotely controlled like this?"

↓

Attack Surface

↓

Item Definition

↓

Asset Identification

↓

🎬 Irumbu Thirai

Question:

"What is the most valuable asset—the vehicle, the data, the identity or the access?"

↓

Damage Scenarios

↓

TARA

↓

🎬 Blackhat

Question:

"How does an attacker move from entry point to impact?"

↓

Attack Path

↓

Risk Evaluation

DAY 2

🎬 I, Robot / Enthiran

Question:

"What happens when intelligent systems become interconnected?"

↓

Cybersecurity Goals

↓

Security Requirements

↓

🎬 Eagle Eye

Question:

"What happens when everything is connected?"

↓

Secure Architecture

↓

Supplier Cybersecurity

↓

OTA

↓

Testing

↓

🎬 Sneakers

Question:

"How do we prove that our security controls actually work?"

↓

Verification & Validation

↓

Incident Management

↓

60-Day Implementation Roadmap

7. The "2026 India Automotive Cybersecurity" Case Study

I strongly recommend making this the final capstone case rather than using only foreign examples.

Scenario

Your OEM has 500,000 connected vehicles on the road.

A vulnerability is discovered involving a connected EV subsystem.

The issue potentially involves:

Mobile App → Bluetooth → BMS → TCU → Cloud → OTA

Participants must answer:

STEP 1 — IDENTIFY

What assets are involved?

STEP 2 — MAP

What is the attack surface?

STEP 3 — TARA

What are the damage and threat scenarios?

STEP 4 — PRIORITISE

Which risks require immediate treatment?

STEP 5 — PROTECT

What cybersecurity controls are required?

STEP 6 — VERIFY

How will we test them?

STEP 7 — RESPOND

What happens if exploitation is confirmed?

STEP 8 — RECOVER

How do we restore the affected vehicles?

STEP 9 — LEARN

What must change in the next vehicle programme?

This scenario is particularly timely because India's 2026 automotive cybersecurity developments are explicitly focusing attention on connected vehicles, EV software, authentication, OTA security and lifecycle cybersecurity. (Business Standard)

8. The 10 Resources I Would Put in the Participant Workbook

ISO/SAE 21434:2021 — official standard overview (ISO)
Indian connected-vehicle cybersecurity advisory — July 2026 (Business Standard)
India's proposed automotive cybersecurity roadmap — 2026 (ETAuto.com)
OEM/Tier-1 EV cybersecurity discussion — September 2026 (Autocar Professional)
SAE OTA Cybersecurity Paper — 2026 (SAE Mobilus)
PeTARA — 2026 (ScienceDirect)
OEM-Supplier TARA orchestration — 2026 (ScienceDirect)
ThreatSurf — Automotive Attack Surface (ScienceDirect)
Automotive Cybersecurity Testing Survey (PubMed Central (PMC))
Practical ISO 21434 TARA methodology (SAE Mobilus)

A comprehensive glossary of the abbreviations used in the ISO/SAE 21434 automobile cybersecurity training module, including the abbreviations appearing in the activities, case studies, architecture discussions, regulatory references, and research section.

Glossary of Abbreviations

ISO/SAE 21434 – Cybersecurity for Road Vehicles

Abbreviation	Full Form	Relevance to Automotive Cybersecurity
ADAS	Advanced Driver Assistance Systems	Vehicle systems that assist the driver, such as adaptive cruise control, lane keeping and automatic emergency braking.
AI	Artificial Intelligence	Used in ADAS, autonomous driving, predictive systems and connected-vehicle applications.
BCM	Body Control Module	ECU controlling functions such as lighting, doors, windows, wipers and other body functions.
BMS	Battery Management System	Monitors and controls EV battery parameters such as state of charge, temperature and voltage.
CAN	Controller Area Network	Major in-vehicle communication protocol used by ECUs.
CAN-FD	Controller Area Network – Flexible Data Rate	Enhanced CAN protocol supporting larger data payloads and higher data rates.
CIA	Confidentiality, Integrity and Availability	Three fundamental information-security properties.
CSMS	Cyber Security Management System	Organisational framework for managing vehicle cybersecurity, particularly relevant to UN R155.
CVSS	Common Vulnerability Scoring System	Framework for assessing the severity of cybersecurity vulnerabilities.
E/E	Electrical/Electronic	Refers to vehicle electrical and electronic systems and architectures.
ECU	Electronic Control Unit	Embedded computer that controls a specific vehicle function or system.
EV	Electric Vehicle	Vehicle powered fully or partly by electrical energy; particularly relevant to connected cybersecurity and BMS security.
GNSS	Global Navigation Satellite System	Satellite-based positioning technology used for vehicle location and navigation.
HSM	Hardware Security Module	Hardware-based security component used for cryptographic operations and protection of keys.
IT	Information Technology	Traditional computing/network environment; contrasted with automotive and OT environments.
LIN	Local Interconnect Network	Low-cost vehicle communication network commonly used for body electronics.
MES	Manufacturing Execution System	System used to monitor and manage manufacturing operations and production processes.
OBD	On-Board Diagnostics	Vehicle diagnostic interface used to access vehicle diagnostic information and functions.
OEM	Original Equipment Manufacturer	Vehicle manufacturer responsible for designing/producing the vehicle and coordinating its ecosystem.
OTA	Over-the-Air	Remote delivery of software or firmware updates to vehicles.
OT	Operational Technology	Hardware/software that monitors or controls physical processes; relevant to manufacturing environments.
R&D	Research and Development	Vehicle/product development function involved in engineering and innovation.
R155	UN Regulation No. 155	UNECE regulation concerning vehicle cybersecurity and Cyber Security Management Systems.
R156	UN Regulation No. 156	UNECE regulation concerning software update management systems.
SAE	SAE International	Standards organisation that jointly developed ISO/SAE 21434 with ISO.
SBOM	Software Bill of Materials	Inventory of software components, dependencies and libraries used in a software product.
SOP	Start of Production	Point at which a vehicle/product officially enters production.
STRIDE	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege	Threat-modelling methodology used to identify categories of cybersecurity threats.
TARA	Threat Analysis and Risk Assessment	Core cybersecurity risk-analysis activity in ISO/SAE 21434.
TCU	Telematics Control Unit	ECU responsible for vehicle connectivity and communication with external networks/cloud services.
USB	Universal Serial Bus	Physical interface that can be used to connect external devices to vehicle or manufacturing systems.
UN	United Nations	Organisation under which UNECE vehicle regulations are developed.
UNECE	United Nations Economic Commission for Europe	Organisation responsible for international vehicle regulations including R155 and R156.
Wi-Fi	Wireless Fidelity	Wireless networking technology that can provide an external attack surface.

ISO/SAE 21434-Specific Terminology

Some important terms in the training are not abbreviations, but participants should know them because they appear repeatedly in the standard.

Term	Meaning
Cybersecurity	Protection of vehicle E/E systems, components, communication and associated information against threats that could compromise security properties or vehicle functions.
Cybersecurity Case	Structured argument/evidence demonstrating that cybersecurity claims and requirements have been adequately addressed.
Cybersecurity Goal	High-level cybersecurity objective derived from TARA.
Cybersecurity Requirement	Specific requirement derived from cybersecurity goals and used to implement cybersecurity controls.
Cybersecurity Concept	Specification of cybersecurity measures needed to achieve cybersecurity goals.
Damage Scenario	Description of potential damage resulting from compromise of an asset.
Threat Scenario	Description of how an attacker could cause a damage scenario.
Attack Path	Sequence of steps/interfaces an attacker may use to reach an asset or cause a threat scenario.
Asset	Something of value that requires protection, such as data, functionality, ECU capability or communication.
Item	System or combination of systems/functions being considered for cybersecurity analysis.
Item Definition	Definition of the item, including its boundaries, functions, interfaces and dependencies.
Attack Feasibility	Assessment of how difficult it would be for an attacker to execute a particular attack path.
Impact Rating	Assessment of the consequences associated with a successful cybersecurity attack.
Risk	Combination of the potential impact and feasibility of a cybersecurity attack.
Risk Treatment	Decision/action taken to address identified cybersecurity risk.
Residual Risk	Risk remaining after cybersecurity controls have been implemented.
Threat	Potential cause of a cybersecurity incident or compromise.
Vulnerability	Weakness that can potentially be exploited to compromise a system.
Trust Boundary	Logical boundary separating components/systems with different levels of trust.
Attack Surface	Collection of interfaces and pathways through which a system could potentially be attacked.

Automotive Architecture Abbreviations

Abbreviation	Full Form	Typical Application
ADAS ECU	Advanced Driver Assistance Systems Electronic Control Unit	Controls ADAS functions.
BMS ECU	Battery Management System Electronic Control Unit	EV battery management.
BCM	Body Control Module	Body electronics.
ECU	Electronic Control Unit	Embedded vehicle controller.
TCU	Telematics Control Unit	Connectivity/telematics.
HMI	Human-Machine Interface	Driver interaction with vehicle systems.
IVI	In-Vehicle Infotainment	Entertainment, navigation and connected services.
IVN	In-Vehicle Network	Communication network connecting vehicle ECUs.
V2V	Vehicle-to-Vehicle	Communication between vehicles.
V2I	Vehicle-to-Infrastructure	Communication between vehicles and infrastructure.
V2X	Vehicle-to-Everything	Umbrella term for vehicle communication with vehicles, infrastructure, networks, pedestrians etc.
V2C	Vehicle-to-Cloud	Communication between vehicle and cloud services.
V2G	Vehicle-to-Grid	Communication/energy interaction between EV and electrical grid.

Note: V2V, V2I, V2X, V2C and V2G were not central to the original module, but they are useful additions if you expand the connected-vehicle section.

Cybersecurity & Technology Abbreviations

Abbreviation	Full Form
API	Application Programming Interface
AES	Advanced Encryption Standard
CA	Certificate Authority
DDoS	Distributed Denial of Service
DoS	Denial of Service
IDS	Intrusion Detection System
IPS	Intrusion Prevention System
PKI	Public Key Infrastructure
RSA	Rivest–Shamir–Adleman
TLS	Transport Layer Security
VPN	Virtual Private Network
MFA	Multi-Factor Authentication
RBAC	Role-Based Access Control
ACL	Access Control List
HMAC	Hash-Based Message Authentication Code
SHA	Secure Hash Algorithm
TPM	Trusted Platform Module
MAC	Message Authentication Code
SAST	Static Application Security Testing
DAST	Dynamic Application Security Testing
FOTA	Firmware Over-the-Air
SOTA	Software Over-the-Air
SBOM	Software Bill of Materials

Software & Development Abbreviations

Abbreviation	Full Form
API	Application Programming Interface
CI/CD	Continuous Integration / Continuous Delivery or Deployment
DevSecOps	Development, Security and Operations
IDE	Integrated Development Environment
OSS	Open-Source Software
SWE	Software Engineering
VCS	Version Control System
QA	Quality Assurance
QC	Quality Control
UAT	User Acceptance Testing
FMEA	Failure Mode and Effects Analysis
FMECA	Failure Mode, Effects and Criticality Analysis
HIL	Hardware-in-the-Loop
SIL	Software-in-the-Loop
V&V	Verification and Validation

Manufacturing & Automotive Quality Abbreviations

These are useful when connecting ISO/SAE 21434 to the existing automotive manufacturing environment.

Abbreviation	Full Form
APQP	Advanced Product Quality Planning
PPAP	Production Part Approval Process
FMEA	Failure Mode and Effects Analysis
PFMEA	Process Failure Mode and Effects Analysis
DFMEA	Design Failure Mode and Effects Analysis
MSA	Measurement System Analysis
SPC	Statistical Process Control
OEE	Overall Equipment Effectiveness
PQC	Process Quality Control
CAPA	Corrective and Preventive Action
NCR	Non-Conformance Report
SOP	Start of Production
EOL	End of Line
JIT	Just-in-Time
JIS	Just-in-Sequence
MES	Manufacturing Execution System
SCADA	Supervisory Control and Data Acquisition
PLC	Programmable Logic Controller
HMI	Human-Machine Interface
OT	Operational Technology
IT	Information Technology

Functional Safety / Automotive Standards

These are important because participants may confuse functional safety with cybersecurity.

Abbreviation	Full Form
ISO	International Organization for Standardization
IEC	International Electrotechnical Commission
ASIL	Automotive Safety Integrity Level
ISO 26262	Road Vehicles – Functional Safety
SOTIF	Safety Of The Intended Functionality
ISO 21448	Road Vehicles – Safety of the Intended Functionality
HARA	Hazard Analysis and Risk Assessment
FuSa	Functional Safety

Useful distinction

ISO 26262 → Functional Safety

What happens when the system fails?

ISO/SAE 21434 → Cybersecurity

What happens when someone intentionally attacks or compromises the system?

SOTIF → Intended-functionality safety

What happens when the system works as designed but the intended functionality creates a safety risk in certain situations?

These areas interact but are not interchangeable.

Automotive Regulatory / Compliance Terms

Abbreviation	Full Form
CSMS	Cyber Security Management System
SUMS	Software Update Management System
R155	UN Regulation No. 155 – Cyber Security and Cyber Security Management System
R156	UN Regulation No. 156 – Software Update and Software Update Management System
UNECE	United Nations Economic Commission for Europe
WP.29	UNECE World Forum for Harmonization of Vehicle Regulations
OTA	Over-the-Air
SOTA	Software Over-the-Air
FOTA	Firmware Over-the-Air

Risk & Threat-Modelling Abbreviations

Abbreviation	Full Form
TARA	Threat Analysis and Risk Assessment
STRIDE	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
CVSS	Common Vulnerability Scoring System
CVE	Common Vulnerabilities and Exposures
CWE	Common Weakness Enumeration
CAPEC	Common Attack Pattern Enumeration and Classification
MITRE	MITRE Corporation; commonly associated with cybersecurity knowledge bases such as ATT&CK
ATT&CK	Adversarial Tactics, Techniques, and Common Knowledge
CIA	Confidentiality, Integrity, Availability

Supplier & Software Supply Chain

Abbreviation	Full Form
OEM	Original Equipment Manufacturer
Tier-1	First-tier supplier directly supplying the OEM
Tier-2	Supplier supplying a Tier-1 or another upstream supplier
SBOM	Software Bill of Materials
OSS	Open-Source Software
COTS	Commercial Off-The-Shelf
PSIRT	Product Security Incident Response Team
CSIRT	Computer Security Incident Response Team
C-SCRM	Cybersecurity Supply Chain Risk Management

Research / Academic Abbreviations Appearing in the Material

Abbreviation	Full Form / Meaning
SAE	SAE International
IEEE	Institute of Electrical and Electronics Engineers
TARA	Threat Analysis and Risk Assessment
STRIDE	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
MOSAIC-TARA	Name of a modular TARA approach discussed in the referenced 2026 SAE research
CVSS	Common Vulnerability Scoring System
ADAS	Advanced Driver Assistance Systems
OTA	Over-the-Air

ACRONYMS PARTICIPANTS SHOULD MEMORISE

For the actual training workbook, I would highlight these 15 as the "Must Know 15":

#	Acronym	Meaning
1	ISO/SAE 21434	Road Vehicle Cybersecurity Engineering
2	TARA	Threat Analysis and Risk Assessment
3	ECU	Electronic Control Unit
4	E/E	Electrical/Electronic
5	ADAS	Advanced Driver Assistance Systems
6	OTA	Over-the-Air
7	TCU	Telematics Control Unit
8	CAN	Controller Area Network
9	HSM	Hardware Security Module
10	SBOM	Software Bill of Materials
11	CSMS	Cyber Security Management System
12	SUMS	Software Update Management System
13	R155	UN Regulation No. 155
14	R156	UN Regulation No. 156
15	SOP	Start of Production

One-line memory aid

"21434 → TARA → Goal → Requirement → Control → Test → Evidence → Monitor"

That sequence is particularly useful for participants to keep beside their workstation during real project work.

Trainers Treasure - All that makes a perfect trainer

Tuesday, September 15, 2026

ISO/SAE 21434 — CYBERSECURITY FOR ROAD VEHICLES From Connected Vehicles to Cyber-Resilient Mobility

No comments:

Post a Comment