ISO 21434: Cybersecurity

Intermediate10 min read

Assumes: 9.1 ISO 26262

TL;DR

ISO 21434 is the automotive cybersecurity engineering standard. It answers: “If an attacker compromises this system, what happens?” You start with TARA (Threat Analysis and Risk Assessment), map attack surfaces (OTA, telematics, Bluetooth, USB, OBD-II, WiFi), and implement defense in depth: secure boot, encrypted storage, signed updates, firewalls. Cybersecurity and functional safety (ISO 26262) are linked. A remote exploit that rewrites brake controller firmware is both a security incident and a safety hazard. Critical gotcha: a security vulnerability can become a safety hazard.

ISO 26262 asks what happens when software fails. ISO 21434 asks what happens when software is attacked. On a connected cockpit platform, those questions collide constantly. Your QNX/AAOS/AMSS stack is the battlefield. Because a car with 100M lines of code and always-on connectivity is basically a mobile data center at 120 km/h.

TARA: The Cybersecurity Equivalent of HARA

TARA (Threat Analysis and Risk Assessment) is the ISO 21434 entry point. Structurally similar to HARA, but focused on malicious actors instead of random faults.

TARA Step	Question	Example
Asset identification	What must we protect?	VIN, encryption keys, OTA signing certs, brake ECU firmware
Threat scenario	Who attacks, how, why?	Remote attacker via telematics exploits TLS flaw, pushes malicious config
Attack path	What’s the kill chain?	Internet → modem (AMSS) → QNX gateway → CAN injection
Impact rating	Safety, financial, operational, privacy?	Safety: unintended braking; Privacy: location leak
Attack feasibility	How hard is it?	Expertise, time, equipment, knowledge of target
Risk treatment	Accept, reduce, transfer, avoid?	Reduce: network segmentation + signed CAN gateway rules
Cybersecurity goal	What must hold?	“Remote entities cannot inject unauthenticated vehicle control messages”

TARA outputs Cybersecurity Goals and Cybersecurity Requirements, the security parallel to ISO 26262’s safety goals and FSRs.

TARA and HARA share the same rhythm but different villains: HARA covers accidental hazards, TARA covers deliberate attackers.

Think About It

A researcher discovers they can send fake CAN messages through the OBD port. Who in your organization needs to know?

Reveal Answer

Notify CSMS cybersecurity lead, functional safety (joint TARA/HARA impact), QNX gateway/diagnostics engineering, legal/regulatory (UNECE R155 incident reporting), and your OEM security liaison immediately — this is a product cybersecurity finding, not a bench curiosity. The OBD-II attack path must be re-evaluated in your ISO 21434 cybersecurity case: gateway filtering rules, SecurityAccess (0x27) seed-key protection, and DoIP routing policy. Expect coordinated pen-test re-verification in CANoe and a formal risk treatment decision (reduce, accept, or recall).

Mental Model

If ISO 26262 is the fire code, ISO 21434 is the burglar alarm and lock policy. Fire codes assume accidents; security assumes someone is trying to get in. A connected car has more doors than a 1990 sedan — every wireless interface is a door that needs a lock, an alarm, and a log of who tried the handle.

TARA for security is like HARA for safety — but the attacker is intentional, not random.

Attack Surfaces on Your Platform

Every interface that accepts external input is an attack surface. On a QNX + AAOS + AMSS cockpit, you’re defending all of these simultaneously:

Surface	Entry Point	Typical Threat	Your Stack Touchpoint
OTA	Cloud → modem/AP → update agent	Malicious firmware flash	Signed images, A/B rollback, QNX + AAOS + modem partitions
Telematics	Cellular data session	Remote code execution, data exfiltration	AMSS/QMI path, QNX telematics daemon, firewall rules
Bluetooth	Phone pairing, A2DP, HFP	BlueBorne-class exploits, pairing MITM	AAOS Bluetooth stack, vendor hardening
USB	Media port, debug cable	BadUSB, malformed media parsers	AAOS USB host stack, mount policies
OBD-II	16-pin diagnostic port	Physical attacker with scan tool	DoIP/UDS gateway, security access seeds
WiFi	Hotspot, WiFi Direct	Rogue AP, KRACK-class attacks	AAOS wpa_supplicant, captive portal
CAN/Ethernet	In-vehicle buses (indirect)	Gateway bypass after AP compromise	QNX gateway filtering, MACsec on automotive Ethernet

flowchart LR
    subgraph External["External Attack Surfaces"]
        OTA["OTA Cloud"]
        CELL["Cellular / Telematics"]
        BT["Bluetooth"]
        USB["USB"]
        OBD["OBD-II"]
        WIFI["WiFi"]
    end

    subgraph AP["Application Processor"]
        AMSS["AMSS / MPSS"]
        QNX["QNX — Gateway · OTA agent · Safety VM"]
        AAOS["AAOS — IVI · Apps · BT/USB/WiFi"]
    end

    subgraph Vehicle["In-Vehicle"]
        CAN["CAN / Automotive Ethernet"]
        ECU["Safety ECUs · Actuators"]
    end

    OTA --> AMSS
    OTA --> QNX
    CELL --> AMSS
    AMSS --> QNX
    BT --> AAOS
    USB --> AAOS
    WIFI --> AAOS
    OBD --> QNX
    QNX --> CAN
    CAN --> ECU

Six major cockpit surfaces to defend: OTA, telematics, Bluetooth, USB, OBD, WiFi. If you can’t name the surface, you can’t defend it.

Defense in Depth: No Single Wall

ISO 21434 expects layered controls. If one layer fails, the next still holds. Same philosophy as ASIL decomposition, different adversary.

Layer	Control	What It Stops
Secure boot chain	Verified XBL → UEFI → hypervisor → VM images	Persistent implant at boot
Encrypted storage	LUKS/dm-crypt on userdata, hardware keystore	Offline data theft from stolen head unit
Signed updates	OEM code-signing on OTA packages	Malicious firmware from compromised CDN
Firewall / network segmentation	Modem VLAN, iptables/nftables on QNX, SELinux on AAOS	Lateral movement from IVI to gateway
Least privilege	Process capabilities, no root in production IVI	Post-exploit privilege escalation
Security Access (UDS 0x27)	Seed-key challenge on diagnostic writes	Unauthorized OBD reprogramming
Intrusion detection / logging	Secure log pipeline, anomaly alerts	Silent persistent compromise

Secure boot on Qualcomm platforms (Module 5) is your first line. If the attacker can’t persist at the firmware level, remote exploits become session-only (still bad, but recoverable on reboot).

CSMS vs. Product Cybersecurity

ISO 21434 distinguishes CSMS (Cybersecurity Management System), the organizational process for ongoing security, from product-level TARA and requirements for each item. Your Tier-1 supplier maintains a CSMS; each ECU/domain controller ships with a Cybersecurity Case documenting TARA, controls, and verification. Auditors check both: “Do you have a process?” and “Did you apply it to this product?”

How Cybersecurity Interacts With Safety

This is where Module 9.1 and 9.2 meet. ISO 26262 and ISO 21434 explicitly require coordination:

Scenario	Security Classification	Safety Classification	Joint Response
IVI app crash from bad media file	Security: low (availability)	Safety: none (QM domain)	Standard bug fix
Remote exploit of AAOS Bluetooth stack	Security: critical (RCE)	Safety: potential if gateway reachable	Patch + verify FFI still holds
Attacker reprograms brake ECU via OBD	Security: critical (integrity)	Safety: ASIL D hazard	Recall + gateway hardening + key rotation
Telematics data leak (location history)	Security/privacy: high	Safety: none directly	Privacy notification, encryption fix

The interface between QM (AAOS) and safety (QNX/gateway) is the highest-risk junction. Security analysis must ask: “If AAOS is fully compromised, can the attacker reach the CAN gateway or safety VM?” The answer should be no, enforced by hypervisor memory maps, network rules, and authenticated IPC, with test evidence (penetration test reports, fuzz results).

Common Gotcha

Beginner thinks a security CVE in AAOS is “just” a security issue, like on a phone. Reality: if that RCE reaches the QNX gateway or injects CAN frames, it’s a safety hazard requiring HARA re-evaluation, potential ASIL impact analysis, and coordinated recall planning. Never file security bugs as “low priority cosmetic” without tracing the attack path to vehicle actuators.

Connect the Dots

Module 5’s verified boot chain is a cybersecurity control that also supports safety-of-intended-function. Module 6’s hypervisor FFI is the safety boundary that cybersecurity must not breach. Module 7’s telematics and OTA are primary TARA attack paths. Module 8’s flash procedures must preserve signing and rollback protections. Module 9.4’s UDS SecurityAccess is the diagnostic-layer lock on OBD-II.

The short version

1. TARA maps threats to cybersecurity goals (the HARA of malicious actors).
2. Six major cockpit surfaces: OTA, telematics, Bluetooth, USB, OBD-II, WiFi.
3. Defense in depth: secure boot, encryption, signing, firewalls, least privilege.
4. Security ↔ safety coordination. Exploits that reach actuators are both CVEs and hazards.
5. QM compromise must not imply safety compromise. FFI is a security requirement too.

Where You'll See This

When a security researcher or pen-test report lands on your desk:

1. Trace the attack path: entry surface → AP component → does it cross into QNX/gateway/CAN?
2. Classify dual impact: CVE severity and potential safety hazard if gateway is reachable.
3. Check containment: hypervisor memory map, firewall rules, VHAL input validation still hold?
4. Coordinate fix ownership: AAOS patch (Google/vendor), QNX gateway rule (your team), modem (AMSS update)?

For OTA updates, verify signature check is never bypassed in your release pipeline. A “test key” left in production builds is a career-ending TARA failure. Grep your build configs for SIGN, AVB, and SECURE_BOOT flags before every release candidate.

Check Your Understanding

1. What is TARA in the context of ISO 21434?

Recall

A. A Qualcomm modem firmware update mechanism for AMSS OTA via PIL remoteprocB. Threat Analysis and Risk Assessment — assets, threats, attack paths, treatmentC. The ASIL lookup table that maps severity and exposure to safety integrity levelD. A diagnostic protocol for reading trouble codes over Ethernet via DoIP stack

2. Which cockpit interface is a physical attack surface where an attacker with a scan tool could attempt unauthorized ECU reprogramming?

Recall

A. Cluster pixel clockB. Hypervisor stage-2 page tablesC. OBD-II diagnostic portD. Internal QNX slog2 buffer

3. An attacker achieves remote code execution in AAOS via a Bluetooth stack vulnerability. Why must this be evaluated for safety impact, not just security severity?

Applied

A. AAOS is ASIL D certified so Bluetooth vulnerabilities are already mitigatedB. Bluetooth is always ASIL DC. Compromised QM domain may reach QNX gateway or bus — exploit becomes safety riskD. ISO 21434 requires all Bluetooth bugs to trigger an immediate vehicle recall

4. Which defense-in-depth control directly prevents flashing unsigned firmware during OTA?

Applied

A. Code signing and verified boot — rejecting images without valid OEM signatureB. CAN bus termination resistorsC. Disabling Bluetooth pairingD. Running cluster in AAOS for faster updates

5. ISO 21434 distinguishes CSMS from product-level cybersecurity. What does CSMS cover?

Applied

A. Cellular modem RF calibration data stored in the modem NV partition on UFSB. The org CSMS — ongoing process to identify, treat, and monitor lifecycle threatsC. Only the bootloader signature check on one ECUD. The CAL lookup table for ASIL derivation

6. A TARA identifies telematics modem compromise as a high-risk attack path to the in-vehicle gateway. Which layered control combination best addresses this?

Synthesis

Connects to: Module 7 — Connectivity & Telematics

A. Move all gateway code into AAOS for faster patching through Play Store OTAB. Segmentation modem↔gateway, signed CAN filters, verified boot against implantsC. Disable all cellular connectivity in production vehicles as a blanket measureD. Rely on Bluetooth pairing PINs alone as the sole defense-in-depth mechanism

Further Reading

• ISO/SAE 21434:2021 — Road Vehicles Cybersecurity Engineering — Official ISO catalog entry for the automotive cybersecurity standard covering TARA, risk treatment, and lifecycle requirements.
• UNECE WP.29 — UN Regulation No. 155 (Cyber Security) — UNECE regulation mandating cybersecurity management systems that ISO 21434 helps satisfy for type approval.
• UNECE WP.29 — UN Regulation No. 156 (Software Updates) — Companion regulation for OTA update processes, directly relevant to cockpit update architecture and campaign controls.
• AUTOSAR — Cyber Security — AUTOSAR foundation documents for secure communication, intrusion detection, and platform security mechanisms in vehicle networks.
• Android Verified Boot — Concrete defense-in-depth control for signed firmware and integrity verification on the AAOS side of a cockpit platform.
• NIST Cybersecurity Framework — General risk-management framework often referenced alongside TARA for structuring identify-protect-detect-respond-recover controls.