Skip to main content
← Back to Blog
CybersecurityMarch 5, 2026 • 6 min read

STRIDE Threat Modeling for Automotive ECUs

By Agnile Engineering Team

Key Takeaways

TL;DR — STRIDE — Microsoft's six-category threat framework (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) — maps directly onto automotive assets, buses, and external interfaces. In ISO/SAE 21434 TARA, STRIDE is the structured method for Step 2 (threat identification), with each category corresponding to a cybersecurity property: authenticity, integrity, non-repudiation, confidentiality, availability, and authorization.

  1. 1.STRIDE's six categories map cleanly onto ISO/SAE 21434 cybersecurity properties — Spoofing↔authenticity, Tampering↔integrity, Repudiation↔non-repudiation, Information Disclosure↔confidentiality, Denial of Service↔availability, Elevation of Privilege↔authorization — making it a natural fit for TARA Step 2 (threat identification).
  2. 2.CAN was designed in the 1980s without security in mind, so every STRIDE category applies: no source authentication (spoofing), no integrity protection beyond the error-detection CRC (tampering), no protocol-level logging (repudiation), broadcast-to-all messages (information disclosure), priority-based arbitration that enables bus starvation (DoS), and no access control (elevation of privilege).
  3. 3.Recommended CAN mitigations include AUTOSAR SecOC with message authentication codes for spoofing and tampering, IDS and security-event logging at gateways for repudiation, domain segmentation for information disclosure and elevation of privilege, and bus monitoring with anomaly detection for DoS.
  4. 4.V2X introduces wireless attack surfaces requiring PKI-based certificate validation under IEEE 1609.2 / ETSI TS 103 097, digital signatures on every message, pseudonym certificate rotation for privacy, and congestion-control plus plausibility checking to resist jamming.
  5. 5.The 2015 Jeep Cherokee attack is the canonical real-world case study: spoofed CAN messages from a compromised infotainment unit controlled steering, braking, and transmission on ECUs elsewhere on the same network — illustrating how multiple STRIDE threats chain together.

At a Glance

One-Sentence Answer
STRIDE can support automotive threat modelling when mapped carefully to vehicle assets, cybersecurity properties, interfaces, and damage scenarios.
Who This Is For
TARA teams, system architects, cybersecurity engineers, threat modellers, and suppliers building structured threat scenarios.
Last Reviewed
May 2026
Primary References
STRIDE, ISO/SAE 21434 TARA, cybersecurity properties, automotive threat modelling.
Practical Use
Use this guide to avoid generic STRIDE checklists and connect threat categories to real automotive architecture.

STRIDE is a Threat Modeling framework originally developed by Microsoft that categorizes threats into six types: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. In Automotive Cybersecurity, STRIDE is adapted for vehicle architectures — applied to ECUs, communication buses (CAN, Ethernet), external interfaces (OBD, V2X), and data flows. When used systematically, STRIDE provides a structured approach to threat identification that aligns directly with the ISO/SAE 21434 Threat Analysis and Risk Assessment methodology.

While STRIDE was originally designed for IT systems, its category-based approach translates remarkably well to automotive architectures. The key adaptation is mapping STRIDE categories to vehicle-specific assets, communication protocols, and operational contexts that are fundamentally different from enterprise IT environments.

The Six STRIDE Categories in Automotive Context

SSpoofing

Impersonating a legitimate identity to gain access or inject data.

Automotive exampleDiagnostic session brute force impersonating an OEM tester
TTampering

Unauthorized modification of data, firmware, or messages in transit.

Automotive exampleCAN-FD message injection on the powertrain bus
RRepudiation

Inability to prove that a specific actor performed a specific action.

Automotive exampleMissing audit trail on UDS routine activation
IInformation Disclosure

Unauthorized exposure of confidential data or sensitive payloads.

Automotive exampleTLS downgrade leaking telematics payloads
DDenial of Service

Preventing legitimate functions or messages from operating on time.

Automotive exampleECU bus-flood attack denying steering messages
EElevation of Privilege

Gaining capabilities beyond the authorized level for the actor or domain.

Automotive exampleJTAG access escalating to firmware write
The six STRIDE categories with their automotive-specific manifestations — the threat surface practitioners walk through during ISO/SAE 21434 TARA Step 2 (threat identification).

S — Spoofing (Identity).In automotive systems, spoofing involves an attacker impersonating a legitimate entity to gain unauthorized access or inject false data. On a CAN bus — which lacks native authentication — any node can transmit messages with any arbitration ID, making spoofing trivial. An attacker who gains access to the CAN bus (e.g., through a compromised infotainment unit or the OBD-II port) can send spoofed messages that appear to originate from legitimate ECUs such as the engine controller, brake controller, or steering system.

Real-world example: In the 2015 Jeep Cherokee attack, researchers sent spoofed CAN messages from a compromised infotainment system to control steering, braking, and transmission — functions controlled by other ECUs on the same CAN network.

T — Tampering (Integrity). Tampering involves unauthorized modification of data, firmware, or configuration. In automotive systems, this includes modifying ECU firmware through compromised update mechanisms, altering calibration data to change engine performance or emissions behavior, modifying diagnostic configurations, or intercepting and altering messages on the vehicle bus. Tampering threats are particularly critical for safety-relevant ECUs where modified software could cause physical harm.

Real-world example: The Volkswagen emissions scandal demonstrated how software modifications in ECUs can have massive regulatory and safety implications, highlighting the importance of firmware integrity protection.

R — Repudiation. Repudiation threats involve the inability to prove that a specific action occurred or was performed by a specific entity. In automotive systems, this applies to diagnostic sessions (who accessed the ECU and what changes were made), OTA update logs (proving which firmware version was installed and when), security event logging (demonstrating that an intrusion was detected and responded to), and service records (verifying that maintenance was performed by authorized personnel).

Automotive cybersecurity regulations increasingly require audit trails and logging capabilities. UNECE R155 Annex 5 specifically lists the inability to log security events as a vulnerability.

I — Information Disclosure (Confidentiality). Information disclosure involves unauthorized access to sensitive data. In vehicles, this includes extraction of cryptographic keys stored in ECUs (used for secure boot, secure communication, or DRM), interception of personal data transmitted between the vehicle and cloud services, reading diagnostic data that reveals proprietary algorithms or calibration parameters, and eavesdropping on in-vehicle network traffic to reverse-engineer communication protocols.

With the increasing deployment of V2X (Vehicle-to-Everything) communication, information disclosure threats extend to vehicle location tracking, driver behavior profiling, and fleet intelligence gathering.

D — Denial of Service (Availability). Denial of service in automotive systems means preventing legitimate functions from operating. On a CAN bus, this can be achieved by flooding the bus with high-priority messages (bus-off attack), preventing legitimate ECUs from transmitting. For Ethernet-based systems, traditional network DoS techniques apply. DoS attacks against safety-critical systems (braking, steering, powertrain) could directly cause hazardous situations.

Real-world example: Researchers have demonstrated CAN bus flooding attacks that can disable specific ECU functions by overwhelming the bus arbitration mechanism, forcing target ECUs into bus-off error states.

E — Elevation of Privilege. Elevation of privilege involves an attacker gaining capabilities beyond their authorized level. In automotive systems, this includes escalating from infotainment system access to safety-domain access (crossing gateway boundaries), gaining root/debug access on an ECU through exploited vulnerabilities, bypassing secure boot to execute unauthorized firmware, and using diagnostic access to unlock manufacturer-level functions.

The separation between safety-critical and non-safety-critical domains is a key architectural defense. Elevation of privilege threats that cross this boundary are among the highest-risk scenarios in automotive cybersecurity.

Mapping STRIDE to ISO/SAE 21434 Threat Analysis and Risk Assessment

STRIDE serves as a powerful threat identification technique within the ISO/SAE 21434 TARA process. Specifically, STRIDE maps to Step 2 (Threat Identification) of the TARA methodology. For each asset identified in Step 1, the analyst systematically considers each STRIDE category to identify applicable threats.

The mapping between STRIDE categories and ISO/SAE 21434 cybersecurity properties is direct: Spoofing threatens authenticity. Tampering threatens integrity. Repudiation threatens non-repudiation (a sub-property of integrity). Information Disclosure threatens confidentiality. Denial of Service threatens availability. Elevation of Privilege threatens authorization (a composite property affecting confidentiality, integrity, and availability).

By systematically applying STRIDE to every asset, interface, and data flow in the system, teams ensure comprehensive threat coverage — reducing the risk of missing critical threats that a less structured brainstorming approach might overlook.

Applying STRIDE to the CAN Bus

The CAN (Controller Area Network) bus is a particularly interesting target for STRIDE analysis because its original design lacks many security properties. CAN was designed in the 1980s for reliable, real-time communication in electrically noisy environments — security was not a design consideration.

  • Spoofing: CAN has no source authentication. Any node can transmit any message ID. Mitigation: CAN message authentication (e.g., AUTOSAR SecOC with MACs).
  • Tampering: CAN messages have no integrity protection beyond the CRC (which is for error detection, not security). Mitigation: Message authentication codes (MACs) appended to CAN payloads.
  • Repudiation: CAN has no logging at the protocol level. Mitigation: Intrusion detection systems (IDS) and security event logging at gateway ECUs.
  • Information Disclosure: All CAN messages are broadcast to all nodes on the bus. Mitigation: Encryption of sensitive payloads (rare in practice due to latency constraints) or network segmentation.
  • Denial of Service: Priority-based arbitration allows high-priority messages to starve lower-priority traffic. Mitigation: Bus monitoring, anomaly detection, and domain separation via gateways.
  • Elevation of Privilege:No access control exists on CAN — any connected node has full bus access. Mitigation: Gateway-based domain isolation, firewall rules at gateway ECUs.

Applying STRIDE to V2X Communication

V2X (Vehicle-to-Everything) communication introduces external wireless interfaces that dramatically expand the attack surface. STRIDE analysis for V2X must consider:

  • Spoofing: Fake V2X messages (e.g., fabricated emergency vehicle warnings or phantom traffic jam notifications) could cause dangerous driver reactions. Mitigation: PKI-based certificate validation per IEEE 1609.2 / ETSI TS 103 097.
  • Tampering: Modification of V2X messages in transit could alter safety-critical information like intersection collision warnings. Mitigation: Digital signatures on all V2X messages.
  • Information Disclosure:V2X messages broadcast vehicle position, speed, and heading — enabling tracking. Mitigation: Pseudonym certificate rotation per ETSI standards.
  • Denial of Service: Jamming or flooding V2X channels could prevent reception of legitimate safety messages. Mitigation: Congestion control, plausibility checking, graceful degradation.

Tools for Automotive STRIDE Analysis

Performing STRIDE analysis at the scale required for modern vehicle architectures benefits from tooling support. Traditional approaches use data flow diagrams (DFDs) annotated with trust boundaries, combined with manual STRIDE-per-element analysis in spreadsheets. While thorough, this approach is time-intensive and difficult to maintain as architectures evolve.

Modern automotive cybersecurity tools integrate STRIDE into automated threat identification workflows. These tools maintain libraries of automotive-specific STRIDE threats mapped to common vehicle components and interfaces, enabling rapid and consistent threat identification.

KAVACH's Approach to STRIDE-Based Threat Modeling

KAVACH incorporates STRIDE as one of its core threat identification methodologies. When a system architecture is input into KAVACH, the platform automatically identifies assets and applies STRIDE-based threat mapping using its curated catalog of thousands of automotive threat scenarios. Each threat in the catalog is tagged with its STRIDE category, applicable component types, communication protocols, and ISO/SAE 21434 work product references.

This approach ensures that STRIDE analysis is applied consistently across all systems in a vehicle program, regardless of which engineer performs the analysis. The AI engine surfaces the most relevant threats for each specific system context, while the structured catalog ensures completeness against known automotive attack vectors.

For teams looking to adopt STRIDE for automotive threat modeling, the combination of a structured methodology, a comprehensive threat catalog, and automated tooling delivers both the rigor required by ISO/SAE 21434 and the efficiency needed to scale across a full vehicle program.

Explore our ISO/SAE 21434 guide for more on how STRIDE fits into the broader TARA methodology.

Want to Review This on a Real Vehicle Architecture?

KAVACH and Agnile's cybersecurity engineering team help teams connect architecture, assets, threats, attack paths, controls, and traceable cybersecurity evidence.