Threat Analysis and Risk Assessment of the Takeover Request Component in Advanced Driver Assistance Systems for SAE Level 2–3

Abstract

This paper presents a Threat Analysis and Risk Assessment (TARA) of the takeover request (TOR) component in Advanced Driver Assistance Systems (ADAS) for SAE Level 2–3 automation. A TOR prompts the human driver to retake control when the system approaches its Operational Design Domain limits or when risk increases; late, false, or muted requests directly impact safety. The study models the TOR pipeline (perception, driver monitoring, decision logic, in-vehicle networks, and Human–Machine Interface) as assets and data flows, applies STRIDE-based threat identification using Microsoft Threat Modeling Tool and Ansys Medini Analyze, and rates risks under ISO/SAE 21434 with traceability to ISO 26262, ISO 21448, and UNECE R155/R157. The assessment produces 165 threat rows, with an initial risk distribution of 1 Critical, 113 High, 34 Medium, and 17 Low. Results show that tampering, denial of service, and spoofing dominate the TOR threat landscape, with the central processing unit, sensor-to-CPU links, and HMI channels as primary trust anchors. After applying mitigation measures including secure boot, message authentication, intrusion detection, redundancy checks, and encrypted communication, the residual post-mitigation security levels were reduced to 0 Critical, 0 High, 13 Medium, 101 Low, and 51 Negligible. Unlike other ADAS TARA studies, this TOR-focused analysis shows that cybersecurity risk is shaped by the interaction between cyber compromise, driver-readiness estimation, HMI delivery, fallback execution, and the limited handover time budget. The results support a defence-in-depth mitigation strategy for secure TOR operation in SAE Level 2–3 vehicles.

1. Introduction

ADAS at SAE Level 2 to Level 3 depends on the TOR to return control to the human when the system approaches its ODD limits or when risk rises. A timely and clear TOR reduces reaction delay and improves post-handover stability, while late or unclear alerts increase incident risk and erode trust [1,2,3]. The regulatory and standards context frames the design and assurance of this function. SAE J3016 sets roles and responsibilities, R157 requires a transition demand with escalation and a fallback MRM if the human does not react, ISO 26262 and ISO 21448 SOTIF provide the functional safety and misuse basis, and R155 with ISO/SAE 21434 establish a cybersecurity risk process and a CSMS that must cover the TOR path from concept to operation [4,5,6,7,8,9]. In SAE Level 2 systems, the driver remains responsible for continuous supervision, and TOR-like mechanisms are typically implemented as escalation mechanisms. In SAE Level 3 systems, by contrast, the transition demand and subsequent MRM are formal elements of the automated-driving fallback concept, particularly under the ALKS-oriented requirements of UNECE R157. Therefore, this study treats both level paths as overlapping but not identical: both require sensing, decision, and HMI channels, while Level 3 additionally requires explicit attention to transition-demand timing and MRM execution.

1.1. Problem Statement

TOR-related research has historically separated human-factors evidence on handover timing and modality from cybersecurity analyses of in-vehicle networks and ECUs. This separation makes it difficult to evaluate, in a single coherent workflow, how cyber threats translate into handover-safety outcomes such as late, false, suppressed, or spoofed takeover requests. The challenge is amplified by the heterogeneity of the TOR pipeline, which spans external perception (cameras, RADAR, LiDAR, V2X), driver monitoring streams, fusion and decision logic in the CPU, multimodal HMI channels, and shared in-vehicle networks (CAN, Automotive Ethernet) that combine safety-critical and best-effort traffic. For TOR, the primary safety concern is not only whether a sensor, ECU, or network message can be compromised, but whether such compromise consumes or masks the handover time budget available for the driver to understand the situation and safely retake control. Without a structured assessment that links these layers to safety-relevant failure modes and to the regulatory evidence required by R155 and ISO/SAE 21434, OEMs and suppliers cannot easily demonstrate that the cyber risk of the TOR function is understood and treated.

1.2. Research Objective and Contribution

The objective of this work is to perform an ISO/SAE 21434-aligned TARA on the TOR function and to identify which assets, attack paths, and failure modes drive risk for SAE Level 2–3 handovers. The contribution is fourfold: (i) a structured TOR architecture model that integrates outer perception, driver monitoring, fusion/decision logic, HMI, and network paths under a single asset list; (ii) a STRIDE-based threat enumeration of this architecture using Microsoft Threat Modeling Tool 2016 and Ansys Medini Analyze 2025 R1; (iii) a risk assessment with severity, feasibility, and treatment policy that retains traceability to ISO 26262, ISO 21448, and UNECE R155/R157; and (iv) a defence-in-depth mitigation catalog that maps to hardware, software, network, and compliance controls, complemented by a discussion of emerging threat vectors (AI model poisoning, post-quantum cryptographic exposure) relevant to long-lifecycle vehicles. The TOR-specific contribution is the explicit mapping of cybersecurity threats to handover outcomes, including delayed, suppressed, or spoofed takeover requests rather than only generic ADAS malfunction or actuation failure. In contrast to AEB-oriented TARA studies, where the main effect is typically incorrect or unavailable braking intervention, the TOR depends on the combined integrity of driver monitoring, HMI escalation, driver-engagement verification, and MRM fallback. The framing is intentionally architecture-aware so that the resulting threats and controls can be reused across vehicle programs that share a comparable TOR functional decomposition.

1.3. Paper Organization

The remainder of this paper is organised as follows. Section 2 reviews the relevant standards and regulations, TARA methodologies and tool support, and related work on takeover requests. Section 3 presents the TOR architecture as a system context, including outer and inner sensors, the central processing unit, actuators, network interfaces, and the staged escalation flow. Section 4 describes the materials and methods, including the analysis scope, the structured literature review, the architecture-modelling workflow with Microsoft TMT and Medini Analyze, and the ISO/SAE 21434-aligned risk-assessment procedure. Section 5 reports the threat-analysis and risk-assessment results, distinguishing critical and high risk levels and consolidating findings under STRIDE. Section 6 discusses cross-cutting threat patterns, defence-in-depth mitigations across hardware, software, network, and compliance dimensions, and emerging threat vectors. Section 7 concludes with the main implications and outlook on future work.

2. Background: Standards, TARA, and Related Work

This section reviews the regulatory and standards context relevant to the TOR function, summarizes contemporary TARA methodologies and tool support, and surveys related work on takeover requests across human-factors, architectural, and cybersecurity dimensions.

2.1. Related Standards and Regulations

The cybersecurity and safety assurance of the TOR function is governed by several complementary frameworks. UNECE Regulation No. 155 establishes a Cybersecurity Management System (CSMS) that vehicle manufacturers must demonstrate at type approval, including organisational processes for threat and vulnerability analysis, risk treatment, and in-service monitoring [8]. UNECE Regulation No. 157 governs the type approval of Automated Lane Keeping Systems (ALKS) at SAE Level 3, with explicit requirements on transition demand design, escalation, and the Minimal Risk Maneuver (MRM) when the driver does not respond [5]. The two regulations operate at different levels: R155 governs the manufacturer process and evidence for risk management, while R157 governs the function-level behaviour of transition demand and MRM. Table 1 summarises the relevant differences for the TOR path.

Table 1. UNECE R155 (cybersecurity) vs. UNECE R157 (ALKS L3)—scope relevant to the TOR path.

Characteristic	UNECE R155 (Cybersecurity/CSMS)	UNECE R157 (ALKS L3)
Objective	Type approval for manufacturer CSMS and vehicle cybersecurity risk management	Type approval for ALKS including transition demand and MRM
Application	All vehicle types under UN type approval and organisation processes plus vehicle cybersecurity	L3 ALKS function within defined ODD; driver availability and handover behaviour
Process	Establish and maintain CSMS; threat and vulnerability analysis; risk treatment; in-service monitoring; linkage to R156 updates	Define ODD and performance requirements; transition demand design and escalation; MRM; compliance test procedures
Phases	Lifecycle via organisation CSMS plus vehicle type approval and monitoring	Type approval plus operational performance and conformity in use
Results	Approved CSMS and vehicles with demonstrable risk management and monitoring capability	Approved ALKS with compliant transition demand and MRM behaviour

Because this paper addresses SAE Level 2–3 systems, the regulatory relevance of TOR must be interpreted differently across automation levels. In Level 2, the driver continuously supervises the driving task, and TOR-like alerts are usually implemented as driver-support, escalation, or misuse-prevention mechanisms. In Level 3, the automated system performs the dynamic driving task within its ODD, so the transition demand and MRM become fallback functions. Therefore, R155 [8] and ISO/SAE 21434 are relevant for both Level 2 and Level 3 cybersecurity engineering, while R157 [5] is specifically relevant to Level 3 ALKS-type functions and their transition-demand/MRM behaviour. Across both levels, the Driver Monitoring System (DMS) supplies the readiness evidence used to gate TOR timing, escalation, and fallback decisions, and is therefore treated as a security-relevant element throughout this paper. Table 2 compares the characteristics of SAE Level 2 and Level 3 relevant to the TOR path.

Table 2. Comparison of SAE Level 2 and SAE Level 3 characteristics relevant to the TOR path.

Characteristic	SAE Level 2	SAE Level 3
Driver role	Driver continuously supervises the driving task	Driver may be fallback-ready but not continuously supervising in the same way
TOR role	Warning, escalation, misuse-prevention, or driver re-engagement support	Formal transition demand from automated system to human driver
R157 applicability	Generally not directly applicable unless the system is ALKS-like or includes similar fallback behaviour	Directly relevant for ALKS-type transition demand and MRM
MRM relevance	May be implemented as a safety fallback or support function, depending on vehicle design	Formal fallback behaviour when the driver does not respond
Cybersecurity relevance	Secure alerts, DMS signals, HMI delivery, and misuse prevention	Secure transition demand, DMS, HMI escalation, MRM execution, and fallback timing
TARA implication	Focus on preventing false, delayed, or misleading driver-support warnings	Focus on preventing false, delayed, suppressed, or spoofed transition demand and failed MRM

ISO/SAE 21434 establishes the consensus framework for cybersecurity engineering in road vehicles, including TARA as the central methodology for identifying, evaluating, and treating cybersecurity risks across the lifecycle from concept and development to production, operation, and decommissioning [9]. ISO 26262 governs functional safety for fault-related hazards in safety-related E/E systems [6], while ISO 21448 (SOTIF) addresses unreasonable risk arising from functional insufficiencies of the intended functionality and from foreseeable misuse [7]. For the TOR function, all three standards interact: ISO/SAE 21434 manages the cybersecurity threats and treatments along the TOR path, ISO 21448 covers non-fault hazards related to sensing or HMI insufficiency, and ISO 26262 addresses fault-related hazards and their safety mechanisms. ISO 24089 complements UNECE R156 by specifying engineering requirements for software updates throughout the vehicle lifecycle, which is relevant to TOR ECUs whose firmware must remain trustworthy over time [10]. Earlier guidance such as SAE J3061 [11] introduced foundational concepts that have since evolved into ISO/SAE 21434. Table 3 summarises the complementary roles of the three core engineering standards.

Table 3. ISO/SAE 21434, ISO 21448 (SOTIF), and ISO 26262—complementary roles for TOR assurance.

Characteristic	ISO/SAE 21434 (Cybersecurity Engineering)	ISO 21448 (SOTIF)	ISO 26262 (Functional Safety)
Objective	Cybersecurity engineering for road vehicles	Reduce unreasonable risk from functional insufficiencies and foreseeable misuse (non-fault)	Functional safety for E/E systems and fault-related hazards
Application	E/E systems, interfaces, and data paths in networked vehicles	Functions limited by sensing, perception, algorithms, or HMI effectiveness	Safety-related HW/SW in series-production road vehicles
Process	Item definition; TARA; cyber goals and claims; concept and design controls; V&V; operations monitoring	Identify hazards from insufficiencies; define triggering conditions and scenarios; V&V of behaviour and HMI; monitoring	HARA; ASIL allocation; safety goals; architecture; HW/SW development with safety mechanisms; V&V and confirmation measures
Phases	Concept → development → production → operation/maintenance → decommissioning	Concept → development → V&V → release (iterative scenario expansion)	Concept; system; hardware; software; production; operation/service; decommissioning
Results	E/E systems with minimised cyber risk and documented evidence	Demonstrated adequacy of HMI and scenarios with reduced risk from non-fault causes	Acceptable residual risk from faults with ASIL compliance and a safety case

V2X-specific security standards are also relevant to the TOR threat model because V2X messages may influence ODD awareness, cooperative hazard detection, and the timing of takeover requests. IEEE 1609.2 [12] and ETSI ITS specifications [13] define security services such as message signing and certificate-based authentication for vehicular communications. These mechanisms are directly related to spoofing, repudiation, replay, and information-disclosure threats against the V2X interface and should be considered when defining mitigations for TOR-relevant cooperative messages.

2.2. TARA Methodologies and Tool Support

Contemporary TARA implementations vary in their degree of formalisation and automation. Manual approaches rely on expert workshops, attack-tree brainstorming, and review-driven enumeration; while these approaches make use of valuable domain expertise, they are subject to inconsistency and oversight when attack paths span multiple subsystems [14]. Structured approaches use STRIDE classification, attack trees, and attack graphs to systematise threat enumeration. STRIDE categorises threats by the violated security property (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), supporting consistent coverage across authenticity, integrity, non-repudiation, confidentiality, availability, and authorisation [14].

Tool support has evolved alongside the methodological refinements. Microsoft Threat Modeling Tool provides STRIDE-based enumeration on data-flow diagrams with trust boundaries [15], while Ansys Medini Analyze supports automotive-oriented TARA with asset traceability, security-property assignment per data flow, and integration with safety analyses aligned to ISO 26262 and ISO 21448 [16]. Recent research has proposed enhanced TARA frameworks for connected and automated vehicles, including refined feasibility and impact metrics that account for the absence of human oversight at higher automation levels [17]. For the TOR function specifically, structured methods are particularly relevant because the failure modes of interest (late, false, suppressed, or spoofed handover) emerge from interactions between perception, decision logic, network paths, and HMI channels rather than from any single component in isolation.

In addition, TOR analysis requires cyber-risk evaluation to be linked with human-factors evidence. The same technical attack may have different safety relevance depending on the driver’s readiness, workload, and available time budget. For example, an attack on an HMI channel during a low-demand highway situation may be less severe than the same attack during a work zone, dense traffic, adverse weather, or a driver-distraction scenario. This motivates a TOR-specific TARA in which cyber threats are mapped not only to compromised components but also to handover outcomes and driver-state conditions.

2.3. Related Work on Takeover Requests

Research on takeover requests focuses on three areas: human–machine interface design, driver re-engagement timing, and safety analysis methods. Reviews covering 2020–2025 report that context-adaptive time budgets and multimodal alerts help drivers regain stable control in Level 3 handovers [1,3]. Experimental studies also find that adequate lead time and clear presentation improve reaction time and trust, while complex scenes such as work zones require earlier and stronger prompts to rebuild situation awareness [2,18]. Driver-centric profiling shows that response styles differ across users and that simple HMI scaffolding can reduce unstable control during the transition [19].

Driver Monitoring Systems are central to this body of work because TOR timing depends on driver attention, availability, and capability of resuming control. DMS functions commonly use driver-facing cameras, gaze and head-pose tracking, eyelid-closure estimation, tactile hands-on detection, and seat or posture sensors to infer readiness. From a cybersecurity perspective, these signals are safety-relevant inputs: spoofed attention, blinded cameras, replayed hands-on signals, or manipulated posture data may cause the TOR controller to overestimate readiness, delay escalation, or incorrectly suppress fallback.

Comparative work on warning modality indicates that combined visual, auditory, and haptic cues outperform single-channel alerts in both planned and unplanned ODD-exit scenarios [20]. On-road experimentation platforms have been proposed to personalise takeover timing; these studies report experience-dependent variance in preferred lead times, which motivates context-aware timing and HMI strategies [21]. Safety analysis from the driver’s perspective has been applied using STPA to derive concrete requirements for the transition, showing how structured hazard identification informs HMI content and sequencing [22]. In parallel, supplier guidance highlights cybersecurity concerns on the perception path. For example, mmWave radar interfaces must ensure integrity and timeliness to avoid false or missed triggers that could distort the TOR decision [23]. A recent automotive TARA on Automatic Emergency Braking systems demonstrates that tampering with RADAR-to-control paths and DoS on the in-vehicle network rank among the highest-impact threats for safety-critical ADAS functions, a result that translates directly to TOR triggers that share the same perception and fusion infrastructure [24].

However, TOR differs from AEB in the way cyber compromise produces a safety impact. In AEB, the dominant concern is typically incorrect, delayed, or unavailable braking intervention. In TOR, the safety effect is mediated through the human driver: a cyber attack may distort the driver-readiness estimate, delay or suppress the HMI alert, falsify engagement confirmation, or compromise the fallback transition to MRM. Therefore, although TOR and AEB share perception, network, and ECU attack surfaces, TOR adds unique dependencies on DMS confidence, multimodal HMI escalation, human reaction time, and fallback execution. Table 4 contrasts the takeover request with related ADAS functions along these dimensions.

Table 4. Comparison of ADAS functions and takeover request (TOR) characteristics.

Function	Primary Safety Objective	Main Cyber-Relevant Paths	Human Role	Fallback Relevance	TOR-Specific Distinction
TOR	Transfer control safely from automation to driver	DMS, CPU decision logic, HMI alerts, CAN/Ethernet, MRM path	Central; driver must perceive, understand, and respond	High; MRM required if no engagement	Cyber risk directly affects handover timing and driver re-engagement
AEB	Prevent or mitigate collision by automatic braking	Perception sensors, ECU, brake actuator, CAN	Limited immediate role	Usually actuation-centered	Safety effect is mainly incorrect/missing braking, not driver handover
ACC/LKA	Maintain speed, headway, or lane position	Sensors, control ECU, steering/throttle/ brake interfaces	Supervisory in L2	Degradation or disengagement warnings	Usually continuous driver supervision rather than formal transition demand
ALKS	Automated lane keeping within ODD	Perception, DMS/availability, control logic, HMI, MRM	Fallback-ready user in L3	Formal MRM if transition demand is not answered	Strong regulatory linkage to R157 transition demand and MRM

Beyond TOR-specific work, the broader automotive-cybersecurity literature provides foundational evidence for the threats that matter to handover safety. Early experimental analyses showed that an attacker with access to the in-vehicle network can compromise safety-critical ECUs and circumvent functional protections, motivating message-authentication and gateway-hardening controls [25]. CAN bus intrusion detection based on ECU fingerprinting has been demonstrated as a practical defence against masquerade and injection attacks on shared buses [26]. Surveys of the connected and automated vehicle threat landscape consolidate sensor-spoofing, V2X manipulation, GPS spoofing, and remote-attack vectors as recurring concerns [27,28]. Specifically for perception-driven functions such as TOR, security studies of LiDAR-based perception have shown that adversarial sensor attacks can spoof obstacles or hide real ones, which directly affects ODD-exit detection and hazard recognition that feed the TOR decision [29].

The structured literature review in this paper focuses on 2020–2025 studies to capture recent developments in takeover requests, automated-driving HMI, and contemporary automotive cybersecurity engineering. Foundational pre-2020 works are nevertheless retained in the background because they established core evidence on in-vehicle compromise, CAN injection, ECU masquerading, sensor spoofing, and connected-vehicle attack surfaces. These works are not treated as part of the recent structured-review corpus but as baseline references necessary to interpret the TOR threat model.

Although the literature provides solid evidence on timing, modality, and individual cybersecurity controls, a structured TARA that integrates these threads into a single TOR-focused asset and threat catalog with traceability to R155, R157, and ISO/SAE 21434 has been less prominently reported. The remainder of this paper addresses this gap.

3. System Context: TOR Architecture and Operational Flow

This section describes the TOR architecture used as the system-of-interest for the TARA. The architecture is presented as a functional decomposition into perception, driver monitoring, decision logic, HMI, and network paths, complemented by the staged escalation logic from initial alert to MRM fallback. Because the TOR function depends on both external road-scene and internal driver-readiness estimation, the Driver Monitoring System (DMS) and the Minimal Risk Maneuver (MRM) path are treated as explicit security-relevant elements of the architecture rather than auxiliary functions.

3.1. Architecture Components

The TOR architecture is organised into four functional blocks: outer sensors that acquire environmental perception data, inner sensors that monitor driver state and in-cabin conditions, a central processing unit that performs sensor fusion and decision-making, and actuators that deliver multimodal alerts to the driver. A fifth security-relevant functional path is the fallback execution chain, which connects the TOR decision logic to vehicle safety systems used for MRM execution when driver engagement is not confirmed.

3.1.1. Outer Sensors

External sensors gather environmental data necessary for TOR initiation. Cameras capture visual imagery for lane detection, traffic sign recognition, and object classification. RADAR provides range and velocity measurements of surrounding objects, enabling detection in low-visibility conditions. Traction sensors monitor wheel slip and road grip to detect hazardous surface conditions. The V2X module enables vehicle-to-vehicle and vehicle-to-infrastructure communication for cooperative safety alerts. LiDAR generates high-resolution 3D maps of surroundings for obstacle detection and path analysis. These sensors define the external-risk estimate used to detect ODD exits, hazardous traffic evolution, and degraded automation conditions that may require a takeover request.

3.1.2. Inner Sensors

Driver-facing sensors provide continuous monitoring of driver state and cabin status. Cameras track head position, gaze direction, and eyelid closure to evaluate driver attention. In the DMS context, these camera-derived features support gaze tracking, head-pose estimation, eyelid-closure analysis, distraction detection, and drowsiness estimation. Tactile sensors detect grip and interaction on the steering wheel or controls. These signals support hands-on detection, steering-contact verification, and takeover-intent recognition. Seat sensors monitor driver posture and presence to detect drowsiness or disengagement. Seat and posture signals also provide complementary evidence of driver availability, abnormal posture, or absence from the expected driving position. Together, the driver camera, tactile sensors, and seat sensors produce a driver-readiness estimate that directly affects TOR timing, escalation, and whether the system proceeds towards MRM fallback. Because incorrect DMS data can cause the controller to overestimate or underestimate driver readiness, DMS inputs are security-critical: spoofed attention, blinded cameras, replaced hands-on signals, or manipulated seat/posture signals can delay a necessary TOR, trigger an unnecessary TOR, or prevent timely feedback.

3.1.3. Central Processing Unit

A dedicated processing unit fuses outer and inner sensor data to maintain situational awareness, evaluates ODD boundaries, traffic situations, and driver readiness to determine TOR necessity, and generates and dispatches TOR commands to the actuators using the appropriate in-vehicle network. The CPU is therefore the central trust anchor for the TOR pipeline: it combines external risk, driver readiness, time-budget estimation, alert selection, escalation logic, engagement verification, and fallback triggering.

3.1.4. Actuators

Output devices deliver the TOR to the driver via multimodal alerts. The sound actuator emits warning tones or speech prompts through the vehicle audio system. The haptic actuator delivers tactile alerts via the steering wheel, seat, or pedals. The visual actuator presents TOR messages on displays, HUD, or indicator panels. Because a takeover request must be noticed, understood, and acted upon within a limited time budget, the visual, auditory, and haptic channels are security-relevant delivery paths. Suppression, delay, or manipulation of any HMI channel can reduce the driver’s remaining response time or create a misleading perception of urgency.

3.1.5. Network Interfaces

Two in-vehicle networks support the TOR pipeline. Automotive Ethernet provides the high-bandwidth, low-latency network connecting high-data-rate sensors (outer cameras, LiDAR, inner cameras) to the CPU, enabling real-time fusion of environmental and driver-monitoring data. The CAN bus provides robust, real-time communication for lower-bandwidth, safety-critical devices such as traction sensors, tactile sensors, seat sensors, and all actuators that exchange commands and status with the ECU. For the TARA, these networks are treated as distinct trust boundaries: Automotive Ethernet primarily carries high-volume perception and DMS streams, while CAN carries lower-bandwidth, safety-critical commands, actuator messages, and engagement signals. Authentication, freshness protection, rate limiting, and monitoring at all these boundaries are necessary to reduce spoofing, tampering, replay, and denial-of-service effects on TOR timing.

3.2. Architecture Overview

The block diagram in Figure 1 visualises how the outer and inner sensing domains converge at the CPU and how alerts are dispatched to actuators over the selected in-vehicle networks. It clarifies the interface classes, typical bandwidth choices, and the separation of perception and driver-monitoring paths that feed the TOR decision.

Figure 1. Block-level TOR architecture with outer/inner sensors, central CPU, network interfaces, and actuators. High data-rate links use Automotive Ethernet; safety-critical alerts are dispatched over CAN.

The split between outer and inner sensors decouples environmental perception from driver-readiness estimation. The CPU hosts the fusion and decision logic, computes a time budget, and selects the alert modality. Automotive Ethernet carries bulk sensor data to meet latency and throughput needs, while CAN provides a dependable control plane for alert commands. Redundancy across actuators increases the likelihood that the TOR remains perceivable when one channel is masked by noise, glare, driver workload, or partial channel degradation; however, this redundancy must still be protected against coordinated network- or CPU-level compromise.

3.3. Decision and Escalation Sequence

The TOR controller follows a staged alert sequence with engagement verification at each stage. Each stage adds an additional sensory channel to overcome masking by noise, glare, or cognitive load. The sequence is security relevant because cyber interference at any stage can consume the remaining handover time budget or force the system into an unsafe fallback state.

Step 1: 

System initialisation (START). The controller initialises sensing, synchronises timestamps, and performs health checks for sensors and actuators. Health checks should include DMS availability, HMI channel status, communication freshness, and fallback readiness.

Step 2: 

Continuous sensor data acquisition. Outer and inner sensors stream data to the controller. Inputs are checked for plausibility, freshness, and integrity, then time-aligned. Two running estimates are maintained: external risk and time budget $R_e\left(t\right)$ (including time-to-intervention), and driver readiness $R_d\left(t\right)$. The driver-readiness estimate should combine camera-based attention, gaze/head pose, eyelid closure, tactile hands-on evidence, and seat/posture signals. Inconsistent DMS signals should be treated as degraded confidence rather than as confirmed readiness.

Step 3: 

Decision: Is TOR triggered? A TOR is asserted when any of the following holds and the available time budget $T_{\mathrm{budget}}$ falls below a calibrated threshold: ODD boundary approach or exceedance (e.g., work zone, adverse weather, unstructured road); hazard onset (stationary obstacle, unsafe cut-in, critical closing speed); system degradation or failure impacting automated control; driver state incompatible with continued automation. If no, return to data acquisition. If yes, proceed to the initial alert. A security-relevant TOR decision therefore depends on both external hazard confidence and DMS confidence; attacks that falsify either side can shift the trigger point too early, too late, or prevent it entirely.

Step 4: 

Stage 1 alert: Visual actuator. A visual-only warning (cluster, HUD, or message centre) is issued. A short verification window $T_1$ starts. The visual command should be authenticated and freshness-protected to prevent delayed, replayed, suppressed, or misleading visual alerts.

Step 5: 

Engagement check #1. Engagement is confirmed if any objective takeover indicator occurs within $T_1$, such as steering torque or hands-on above a calibrated threshold for a minimum duration, driver brake or accelerator application, explicit HMI acknowledgement, or attention recovery in combination with a control input. If engaged, proceed to END; otherwise escalate. Engagement confirmation should not rely on a single signal alone when DMS confidence is degraded, because spoofed hands-on or replayed acknowledgement signals could falsely terminate the escalation.

Step 6: 

Stage 2 alert: Visual + sound actuators. An auditory signal (tones or voice prompt) is added while the visual alert persists. Verification window $T_2$ starts (typically shorter than $T_1$). Adding the auditory channel improves perceptibility but also adds another command path that must be protected against spoofing, muting, or bus contention.

Step 7: 

Engagement check #2. Apply the same acceptance criteria. If engaged, proceed to END; otherwise escalate.

Step 8: 

Stage 3 alert: Visual + sound + haptic actuators. Haptic cues (steering-wheel or seat vibration, pedal pulse) are added to overcome masking by noise, glare, or cognitive load. Final verification window $T_3$ starts. The haptic channel is particularly important when visual or auditory attention is degraded; therefore, attacks that block haptic actuation can remove the final escalation layer before fallback.

Step 9: 

Engagement check #3. Apply the same acceptance criteria. If engaged, proceed to END. If not engaged by the end of $T_3$, initiate fallback. At this point, the security objective shifts from driver re-engagement to preserving safe fallback execution.

Step 10: 

Fallback: Execute MRM using safety systems. The controller commands a Minimal Risk Maneuver: controlled deceleration and lane keeping (or a safe shoulder stop), hazard lights, increased headway, and where applicable an automatic emergency call or OEM assistance trigger. Alerts may remain as status indications until the vehicle reaches a safe state. The MRM chain is a final safety layer and must be treated as an explicit attack surface. Relevant security events include blocking the fallback branch, delaying or altering deceleration commands, suppressing hazard-light activation, preventing lane-keeping support, falsifying MRM status, or sustaining a denial-of-service condition after all three TOR escalation stages. MRM-related commands therefore require integrity, authenticity, freshness, availability monitoring, and safe-default behaviour when command confirmation is missing.

Step 11: 

END: Successful handover. Upon confirmed engagement, the controller executes the authority-transfer handshake (taper assistance, hand control to the driver, clear alerts) and logs event metrics including detection-to-alert, alert-to-engagement, and total handover time. The event log should also record DMS confidence, alert-channel status, escalation stage, fallback activation status, and any detected integrity or freshness violations to support auditability and post-event analysis.

3.4. Flow Chart Overview

The flow chart in Figure 2 summarises the end-to-end message paths for sensing, fusion and decision-making, alert generation, engagement verification, and fallback control. It also highlights trust boundaries and the locations where authentication, freshness, and rate-limiting are enforced.

Figure 2. End-to-end TOR data flow: sensing, fusion and decision, alert generation, engagement checks, and fallback to MRM. Trust boundaries align with CPU and network interfaces; control messages use authenticated channels.

The numbered flows correspond to the sequence above. Sensor streams enter the fusion layer; the decision block issues a TOR message with a time budget; the HMI planner selects channels and escalates; the engagement monitor observes objective indicators; and the fallback controller triggers MRM when confirmation is not received before the deadline. Placement of integrity and freshness checks on ingress and egress paths reduces the chance of false, muted, or delayed requests. This architecture and its data flows are used as the system-of-interest for the materials and methods described in Section 4.

4. Materials and Methods

This section defines the analysis scope, the literature-review workflow, the architecture-modelling and threat-identification procedure, and the risk-assessment scheme used to evaluate the TOR function. The objective is to produce a TARA whose threat catalog and risk ratings are traceable to the assets, attack feasibility factors, and treatment policy specified by ISO/SAE 21434, with linkage to ISO 26262, ISO 21448, and UNECE R155/R157.

4.1. Analysis Scope

The TARA covers the end-to-end TOR pipeline of an SAE Level 2–3 passenger vehicle, spanning external perception (cameras, RADAR, LiDAR, V2X), driver monitoring (cameras, tactile and seat sensors), fusion and decision logic in the central processing unit, multimodal HMI channels (visual, auditory, haptic), and the in-vehicle networks (CAN and Automotive Ethernet) that interconnect them. The scope also includes development-time and in-field activities relevant to the TOR ECUs, such as artifact signing, secure update reception, and operations monitoring. Mechanical subsystems that do not interface with the TOR pipeline, aftermarket devices, and cloud services not directly involved in the TOR function are out of scope. Aligning the scope this way ensures that the TARA outcomes inform both safety-case arguments and operational security playbooks.

The assets considered in the TARA, together with their type, the security properties evaluated, and the trust boundary at which they are positioned, are summarised in Table 5. The selection follows the architecture decomposition introduced in Section 3.

Table 5. Assets considered in the TARA, asset type, security properties evaluated, and trust boundary.

Asset	Type	Security Properties	Trust Boundary
Outer perception sensors (camera, RADAR, LiDAR, V2X, traction)	Sensor	Authenticity, integrity, availability	Sensor-to-CPU
Inner perception sensors (driver camera, tactile, seat)	Sensor	Authenticity, integrity, availability, confidentiality	Sensor-to-CPU
Central processing unit (fusion + decision logic)	Compute	Integrity, authenticity, availability, authorisation	CPU internal/firmware
HMI actuators (visual, auditory, haptic)	Actuator	Integrity, availability, authenticity	CPU-to-HMI
CAN bus (alert and control plane)	Network	Integrity, availability, authenticity	In-vehicle network
Automotive Ethernet backbone (sensor data plane)	Network	Confidentiality, integrity, availability	In-vehicle network
V2X interface (cooperative messages)	External I/F	Authenticity, integrity, availability	Vehicle-to-external
Diagnostic and OTA ingress (e.g., OBD, gateway)	External I/F	Authenticity, integrity, authorisation, non-repudiation	Vehicle-to-external
Event and audit logs	Data store	Integrity, non- repudiation, confidentiality	CPU internal

4.2. Research Goals and Questions

The research goals are to build an asset and data-flow model of the TOR within ADAS, to identify cyber and misuse threats that affect handover safety, to rate risks and propose mitigations that satisfy R155 and ISO/SAE 21434, and to maintain traceability to ISO 26262 and ISO 21448. The work addresses four questions: (i) which TOR assets and interfaces are most exposed to attack or misuse; (ii) which attack paths plausibly lead to late, muted, false, or blocked requests; (iii) which treatments reduce risk to acceptable levels while preserving timing budgets and MRM behaviour; and (iv) how the treatments map to R155 and ISO/SAE 21434 work products.

4.3. Methodology Workflow

The analysis combines two complementary workflows. The first establishes scope and selects the architecture used in the analysis. The second executes the threat and risk assessment on that architecture and produces prioritised mitigations.

The Scope and Architecture Selection workflow grounds the analysis on a clearly defined item and a concrete TOR architecture. It establishes objectives and research questions, collects functional and security requirements, compares candidate TOR architectures, selects the most suitable option, and documents data flows for later analysis. Figure 3 shows the workflow from item choice and question definition to architecture analysis and data-flow documentation.

Figure 3. Scope and Architecture Selection workflow from item choice and question definition to architecture analysis and data-flow documentation.

The expected outputs are an item definition, refined questions aligned to TOR specifications, a requirement set, and an analysed architecture with data-flow diagrams prepared in Microsoft TMT and Ansys Medini Analyze; these become the inputs to the risk assessment. The candidate architecture used in this study was developed and selected within the Automotive Cyber Security Academy (ACSA) programme. Rather than reproducing a single proprietary design, the selection prioritised representativeness of the production-relevant Level 2–3 functional decomposition—outer perception, driver monitoring, fusion and decision logic, multimodal HMI, in-vehicle networks, and the MRM fallback path—and consistency with the asset model in Table 5 and the standards reviewed in Section 2. Because the resulting model is a generic functional reference rather than a specific OEM implementation, the absolute risk ratings should be re-calibrated for program-specific topologies and supplier constraints; this reference-oriented origin is therefore a limitation on the direct generalisability of the findings.

The Threat and Risk Assessment workflow evaluates the selected architecture using a structured process aligned with ISO/SAE 21434 and UNECE R155. It identifies assets, applies STRIDE to components and data flows, rates attack feasibility and impact, aggregates risk, and selects risk treatments. Figure 4 shows the corresponding stages.

Figure 4. Threat and Risk Assessment workflow covering asset definition, STRIDE analysis, feasibility and impact rating, risk categorisation, and mitigation proposal.

This workflow connects architectural elements to concrete threats and derives prioritised controls with clear mapping to R155 evidence and ISO/SAE 21434 work products. The outputs are a threat catalog with ratings and a mitigation plan for severe and high risks.

4.4. Structured Literature Review

A structured literature review covering the period 2020–2025 was conducted across Google Scholar, IEEE Xplore, the ACM Digital Library, and ScienceDirect, using queries combining “takeover request”, “ADAS architecture Level 2/3”, “handover”, “driver monitoring”, “CAN security”, and “cybersecurity”. Retrieved records were de-duplicated and screened by title and abstract; the remaining candidates were assessed in full text against the inclusion criteria below and appraised for method clarity, measurement validity, and relevance to handover safety or security. Rather than a formal systematic review with a registered protocol and flow diagram, this was a structured, criterion-based search followed by a narrative synthesis, designed for a transparent and reproducible search strategy.

Inclusion required peer-reviewed work that addressed at least one of the following topics: TOR or handover mechanisms and timing; ADAS or ECU architectures that constrain or support handover; in-vehicle security or CAN threats with safety impact; or human factors in takeover performance. Exclusions covered patents, non-scholarly reports, and papers focused only on Level 4 or above. Key data fields were extracted and coded around themes including time budgets and alert modalities, driver state and readiness estimation, escalation and MRM policies, architectural patterns, and security controls along the TOR path. Where available, quantitative measures (reaction-time distributions, lane-position variance, alert delivery timing) were recorded to enable cross-study comparison. The synthesis informed the asset list, the threat hypotheses, and the treatment catalog used in the TARA.

4.5. Architecture Modelling and Threat Identification

A functional and data-flow model of the Level 2–3 TOR pipeline was built covering perception, driver monitoring, decision logic, HMI, actuation, and message paths across sensors, ECUs, and networks. Microsoft TMT was used to apply STRIDE on each data flow and trust boundary to enumerate spoofing, tampering, repudiation, information disclosure, denial of service, and elevation-of-privilege threats [15]. Ansys Medini Analyze was used in parallel to perform an automotive-oriented TARA with asset and hazard traceability and alignment with ISO 26262 and ISO 21448 work products [6,7,16]. Threats from both tools were merged, normalised, and prepared for risk rating; redundant threats with equivalent assets and effects were collapsed to keep the catalog tractable while preserving the dominant attack paths.

4.6. Risk Assessment per ISO/SAE 21434 and UNECE R155

Risk was rated using the ISO/SAE 21434 scheme that combines attack feasibility and impact [9], operationalised in Ansys Medini Analyze through the HEAVENS security model [30]. Attack feasibility considered four factors: equipment, expertise, knowledge of the target, and window of opportunity. Impact was rated across the four HEAVENS parameters—Financial, Operational, Privacy, and Safety (FOPS)—with safety weighted highest for the TOR function. Results were aggregated into ordinal risk levels (Critical, High, Medium, Low) that support R155 CSMS reporting [8]. Ratings retain linkage to ISO 26262 severity, exposure, and controllability where applicable for handover hazards [6].

The aggregation from impact and feasibility to ordinal risk level follows the matrix in Table 6. The matrix is applied per threat scenario and is consistent with ISO/SAE 21434 Annex F and with the rating conventions reported in comparable automotive TARA studies [9,24].

Table 6. Risk aggregation matrix from impact and attack feasibility to ordinal risk level (Critical, High, Medium, Low).

Impact ↓\Feasibility →	High	Medium	Low	Very Low
Severe	Critical	High	High	Medium
Major	High	High	Medium	Low
Moderate	Medium	Medium	Medium	Low
Negligible	Medium	Low	Low	Low

Each impact dimension was scored on an ordinal scale (Low = 1, Medium = 4, High = 7) and combined into a weighted impact score $I=(5S+1O+0.5F+0.25P)/4$, which prioritises safety (S) over operational (O), financial (F), and privacy/legislative (P) harm; this score yields a severity class (Severe ≥ 8.30, Major ≥ 5.10, Moderate ≥ 2.50, Negligible ≥ 1.00). Each feasibility factor was scored (High = 10, Medium = 7, Low = 4, Very Low = 1) and averaged across the four factors into a likelihood class (High ≥ 8.30, Medium ≥ 5.10, Low ≥ 2.50, Very Low otherwise). Severity and likelihood are then combined through Table 6 into the ordinal security level, and treatment follows an ISO/SAE 21434 policy (Critical and High: risk reduction; Medium: risk transfer; Low: risk retention).

The class boundaries are not arbitrary but follow directly from the safety-prioritised weighting and the HEAVENS rating scheme [30]. On the impact side, the boundaries are placed so that the severity class is effectively gated by the safety dimension: the Severe class (the only class that can reach Critical under high feasibility) is attainable only when Safety is High, since a High-safety scenario yields $I=(5·7+1+0.5+0.25)/4\approx 9.19\ge 8.30$ even when all other dimensions are Low, whereas a Medium-safety scenario with every other dimension at High reaches only $I\approx 8.06<8.30$. Analogously, the Major boundary at $5.10$ requires Safety to be at least Medium: a Medium-safety scenario with all other dimensions Low gives $I\approx 5.44\ge 5.10$, while a Low-safety scenario with all other dimensions High reaches only $I\approx 4.31<5.10$. This makes the safety weighting auditable rather than nominal. On the feasibility side, the four feasibility factors are averaged and mapped to the four likelihood classes using the same boundaries ($2.50$, $5.10$, $8.30$), applied uniformly across all 165 threat scenarios. The lowest boundary, $2.50$, is the midpoint between the Very Low and Low anchors, while the Medium and High boundaries lie slightly below the corresponding anchor midpoints ($5.5$ and $8.5$) so that a profile whose factors are predominantly at a given ordinal level is assigned to that level rather than rounded down. Because the Critical tier additionally requires a Severe impact (Safety = High, as derived above), it is jointly gated by impact and feasibility, which keeps the classification reproducible. The complete scheme—the impact and feasibility value mappings, the weighted impact formula, and the severity and likelihood class boundaries—is listed in the Rating Criteria sheet of the Supplementary Material (Table S1).

For the TOR function, the safety dimension of impact is weighted highest because late, false, or suppressed handover requests can directly translate into collision risk. Operational, financial, and privacy impacts are recorded but do not dominate the rating unless they coincide with safety-relevant consequences.

4.7. Mitigation Strategy and Compliance Mapping

Low risks may be accepted with justification, Medium risks are transferred via supplier obligations or insurance, and for Critical and High risks concrete treatments are proposed and mapped to ISO/SAE 21434 clauses and R155 evidence items. Typical controls include authenticated and freshness-protected TOR signalling, plausibility checks across perception sources, HMI health monitoring and redundancy, rate limiting and intrusion detection on in-vehicle networks, secure boot and update for ECUs, and safe defaults that trigger MRM on missing acknowledgements. Each treatment records implementation assumptions and verification activities to support the ISO 26262 safety case and the SOTIF misuse analysis [6,7,8,9].

4.8. Validation and Stakeholder Calibration

The threat inventory and risk ratings reported here are derived from structured Microsoft TMT and Medini Analyze outputs and are used to support the comparative discussion of the TOR threat landscape. Risk scoring, treatment selection, and final acceptance criteria depend on stakeholder context (vehicle program, safety goals, supplier constraints, regulatory interpretation) and should be calibrated by the OEM and supplier CSMS and SUMS processes. Every asset, threat, rating, and treatment retains traceability to a literature source or model element and to the corresponding requirement or work product in ISO/SAE 21434 and UNECE R155, ensuring that the cybersecurity and functional-safety arguments remain consistent across the TOR lifecycle. The procedure described in this section was applied to the architecture introduced in Section 3 and produced the threat catalog reported in Section 5.

5. Results

This section reports the TARA findings for the TOR function. Following ISO/SAE 21434, the analysis identifies cyber threats that could compromise safe TOR operation in ADAS Level 2–3 [9]. The scope covers assets and data paths that influence timely and correct handover: perception inputs (e.g., GNSS/GPS, RADAR, camera, LiDAR, V2X), fusion and decision logic in the central processing unit, in-vehicle networks (CAN, Automotive Ethernet), HMI channels (cluster, HUD, audio, haptics), and driver-monitoring streams. The TARA produced 165 individual threat rows before consolidation into STRIDE categories. Representative threats include GPS spoofing that distorts ODD awareness, CAN injection that falsifies or suppresses TOR messages, and flooding on V2X or internal buses that delays alert delivery; these are consistent with recent TARA results on safety-critical ADAS where sensor spoofing, message tampering, and denial of service emerged as the most consequential categories [24].

5.1. STRIDE Classification and Failure Modes

Using STRIDE, threats are classified by the violated security property and mapped to concrete TOR failure modes. Spoofing targets authenticity (e.g., falsified RADAR or camera features, fabricated GNSS data), which can mask ODD exit or fabricate hazards and thereby trigger a TOR too early or too late. Tampering targets integrity along sensor-to-ECU and ECU-to-cluster paths; in the AEB case study, tampering on RADAR-to-braking control over CAN is highlighted as a serious risk because an attacker with in-vehicle access can alter object states, a result that translates directly to TOR triggers dependent on the same perception and fusion pipeline [24]. Denial of service targets availability on in-vehicle networks; flooding or bus contention can postpone visual, audio, or haptic alerts and engagement checks, consistent with the taxonomy where high safety impact was associated with availability attacks against critical components such as stability or steering sensors feeding the decision loop [24]. HMI tampering on the fusion-to-cluster path can mislead the driver about the need or urgency of a handover, degrading controllability even if the underlying perception is correct.

The threat assessment yielded four overarching findings for the TOR function:

• Susceptibility to spoofing and tampering due to multiple unidirectional data streams and external interfaces.
• High sensitivity to denial of service since the timely delivery of TOR alerts is essential for maintaining safety in SAE Level 2–3 automation.
• Weaknesses in accountability resulting from the potential manipulation of logging and audit mechanisms.
• Exposure of sensitive data across communication channels, leading to privacy and regulatory-compliance risks.

These findings highlight the necessity of a multi-layered defence strategy in which integrity, authenticity, confidentiality, and availability are addressed concurrently.

5.2. Risk Evaluation and Treatment Policy

Risk was evaluated by combining attack feasibility and multi-dimensional impact per ISO/SAE 21434. Feasibility considered required time, expertise, knowledge of the item, window of opportunity, and equipment; impact considered safety, operational, financial, and privacy harm [9]. Each scenario is assigned a qualitative security level (Critical, High, Medium, Low) based on the feasibility-impact combination. A canonical cyber-induced delayed handover (alert suppressed or late due to tampering or an availability attack) is rated Critical when it plausibly yields a life-threatening safety impact with at least moderate feasibility, otherwise High. The treatment policy is to mitigate Critical and High risks, transfer Medium risks via supplier obligations or insurance, and accept Low risks with justification and monitoring [9,24]. Consistent with the human-factors framing of this study, the safety dimension of impact is rated in a driver-state- and scenario-aware manner: the same cyber effect—for example, a delayed or suppressed takeover request—is assigned a higher safety impact when it coincides with low driver readiness or demanding operating conditions (dense traffic, work zones, adverse weather) and a lower impact during low-demand, high-readiness highway driving. This ties the cyber-risk rating to the handover time budget and driver-readiness evidence rather than treating impact as context-independent.

The TARA distribution contains 1 Critical, 113 High, 34 Medium, and 17 Low initial risks. After applying the proposed mitigation measures, the residual distribution is reduced to 0 Critical, 0 High, 13 Medium, 101 Low, and 51 Negligible risks. Table 7 summarises the risk-level distribution before and after mitigation.

Table 7. Security risk level distribution before and after mitigation.

Security Level	Initial Assessment	Post-Mitigation Assessment
Critical	1	0
High	113	0
Medium	34	13
Low	17	101
Negligible	0	51
Total	165	165

5.3. Critical Risk Level Threats

Critical threats pose direct and immediate risks to safety by undermining the fundamental objective of the TOR: ensuring reliable and timely handover from the automated system to the driver. One scenario—denial of service on the actuator block—reached the Critical security level, while the remaining highest-severity scenarios were rated High owing to their lower attack likelihood. These safety-critical threats group into three clusters, for each of which representative scenarios are discussed below.

1. 

Tampering with processor data and control flows. Adversaries capable of manipulating the data entering the processing unit or the instructions leaving it can profoundly compromise system reliability. Corrupted sensor-fusion data may prevent the initiation of a TOR when required, while manipulated actuator commands may suppress or distort warnings delivered to the driver. In both scenarios, the result is a failure of timely intervention with a high probability of collision or hazardous exposure. Treatment: adopt secure boot mechanisms, cryptographic integrity protection, and runtime attestation so that only authenticated firmware executes and communications between processors and actuators are verified for integrity and origin.

2. 

Denial of service on processing and communication channels. Disruption of processor input/output or actuator communication represents a second critical risk. By exhausting system resources or blocking essential channels, attackers can silence TOR notifications, effectively disabling the driver’s last line of defence. The danger is amplified by the real-time constraints of TOR: even short outages can have catastrophic consequences. Treatment: deploy intrusion detection and prevention systems, redundant communication paths, and multimodal alerting strategies to reduce the likelihood that one compromised channel suppresses all TOR modalities.

3. 

Tampering with sensor feeds. External sensors such as RADAR, cameras, or LiDAR provide the environmental perception required to determine takeover conditions. An attacker who alters or injects false readings can cause two classes of hazardous behaviour: suppression of necessary TORs (false negatives) or generation of spurious TORs (false positives), both of which degrade safety and driver trust. Treatment: perform cross-modal plausibility checks within the fusion process, apply cryptographic protection of sensor-to-processor links, and use anomaly-detection algorithms to identify physically implausible values.

Taken together, these three threat categories embody the most severe risks because they target the core decision-making and communication pathways of the TOR function. In particular, the denial-of-service and tampering clusters explicitly include MRM-targeted scenarios—blocking the fallback branch, delaying or altering deceleration commands, suppressing hazard-light activation, or sustaining a denial-of-service condition past all three escalation stages—because the MRM is the final safety layer once driver re-engagement has failed (Step 10, Section 3). After mitigation, no Critical rows remain; the residual risk for these clusters is reduced mainly to Medium because the safety relevance remains, but the feasibility and likelihood are reduced by the proposed controls.

5.4. Factor-Level Rating of Representative Threats

To keep the ratings transparent and reproducible, Table 8 reports the per-factor impact and attack-feasibility values for the single Critical-level scenario (TS218) and two representative High-level scenarios on the central data processor (TS178, TS179). The complete factor-level ratings for all 165 threat scenarios are provided as Supplementary Material (Table S1).

Table 8. Factor-level impact and attack-feasibility rating for representative threats, as recorded in Medini Analyze using the HEAVENS parameters.

Factor	TS218	TS178	TS179
	DoS, Actuators	Tamper, Data Proc.	DoS, Data Proc.
Impact (FOPS)
Safety	High	High	High
Financial	Medium	Medium	Medium
Operational	High	High	High
Privacy/Legislative	Low	Low	Low
Severity class	Severe	Severe	Severe
Attack feasibility
Equipment	Standard	Standard	Standard
Expertise	Layman	Expert	Proficient
Knowledge of target	Restricted	Sensitive	Restricted
Window of opportunity	Medium	Medium	Medium
Likelihood class	High	Medium	Medium
Security level	Critical	High	High
Post-mitigation level	Low	Medium	Medium

The Layman expertise rating for TS218 follows the conservative TARA convention that attack feasibility is rated for the easiest viable attack path that produces the harmful outcome, not for the most elaborate one. Denial of service against the actuator block is fundamentally an availability attack: it is achieved by disrupting or flooding a shared in-vehicle communication resource (for example, high-rate bus traffic or physical-layer interference on an accessible network segment) rather than by individually circumventing each escalation layer. Such disruption requires only standard equipment and commodity capability, which is why Equipment is rated Standard and Expertise Layman, yielding a High likelihood. The description of TS218 as defeating all three escalation stages and the actuator redundancy refers to its impact (why the safety severity is rated Severe): because the affected channel is shared, a single denial-of-service condition simultaneously suppresses every TOR modality and the MRM fallback, so the redundancy is overwhelmed by resource exhaustion rather than out-manoeuvred. The Critical rating is therefore the deliberate, worst-case pairing of a Severe safety impact with a low-barrier, high-likelihood attack vector; rating the expertise higher would understate the feasibility of the simplest effective attack.

5.5. High Risk Level Threats

High-risk threats, while less immediately catastrophic, nevertheless undermine the system’s trustworthiness, operational robustness, and regulatory compliance. They primarily concern spoofing, accountability, and confidentiality. High is the dominant risk class in the assessment, with 113 threats rated High at the initial stage; alongside the safety-critical tampering and denial-of-service scenarios above, this class is populated by spoofing, repudiation, information disclosure, and elevation-of-privilege threats.

1. 

Spoofing of sensors and communication interfaces. Impersonation of valid components (e.g., V2X units or RADAR modules) allows adversaries to inject falsified inputs that distort TOR decision-making. A forged emergency broadcast may force unnecessary takeovers, while suppressed hazard signals may delay legitimate interventions. Treatment: enforce mutual authentication using certificate-based trust chains with secure key management, so that only authorised entities participate in TOR-relevant communication.

2. 

Repudiation and accountability loss. The ability to deny or falsify actions by manipulating logs compromises both forensic investigations and legal liability. Without verifiable audit trails, it becomes impossible to establish whether a TOR was generated or delivered at the correct time. Treatment: use tamper-evident logging with cryptographically signed entries and secure timestamping; store logs in trusted hardware to reduce repudiation risks.

3. 

Information disclosure across communication channels. Although less safety-critical, unauthorised interception of camera, LiDAR, RADAR, or V2X streams exposes sensitive information about occupants and surroundings, raising privacy and compliance concerns under UNECE R155 and applicable data-protection regulations. Treatment: apply end-to-end encryption (e.g., TLS 1.3 [31], AES-256 [32]) on internal and external links and enforce strong access-control and key-rotation policies to prevent passive interception or replay.

4. 

Elevation of privilege through diagnostic or OTA ingress. Unauthorized diagnostic access, malicious service actions, or compromised software-update paths may allow reprogramming or runtime override of TOR logic. Treatment: authenticated diagnostics, signed updates, secure update verification, and least-privilege access control.

While not immediately life-threatening, these threats significantly weaken the resilience, compliance, and trustworthiness of the TOR function and must therefore be systematically addressed. After mitigation, no High rows remain; most threat scenarios are reduced to Low or Negligible because the proposed controls directly reduce attack feasibility and improve traceability.

5.6. Driver Monitoring System Threats

Because the TOR trigger and escalation logic depend directly on the driver-readiness estimate, the Driver Monitoring System (DMS) warrants a dedicated threat analysis rather than treatment as an auxiliary sensor. The DMS aggregates driver-facing camera features (gaze, head pose, eyelid closure), tactile hands-on detection, and seat or posture signals into a readiness estimate that gates TOR timing, escalation, and the decision to proceed to MRM. From a STRIDE perspective, the dominant DMS threats are: spoofing of attention or hands-on signals (replayed or fabricated readiness evidence that causes the controller to overestimate driver availability); tampering with or blinding of driver-facing cameras and posture sensors that degrades or falsifies the readiness estimate; denial of service on the DMS-to-CPU stream that removes readiness information during a handover; and information disclosure of in-cabin monitoring data, a privacy and compliance concern under UNECE R155. The characteristic TOR failure modes are an unnecessary TOR triggered on falsely-low readiness, a suppressed or delayed TOR caused by falsely-high readiness, and premature termination of escalation through spoofed engagement confirmation. Recommended treatments are authenticated and freshness-protected DMS signalling, cross-checking readiness across independent modalities (camera, tactile, seat) so that no single spoofed signal is decisive, plausibility and liveness checks on camera input, encryption and access control for in-cabin streams, and treating inconsistent DMS evidence as degraded confidence rather than confirmed readiness. These DMS-specific threats are part of the 165-scenario catalog rather than a separate analysis: in the Supplementary Material (Table S1) they are realised through the driver-facing (inner) camera, tactile hands-on sensor, seat/posture sensor, and the inner sensor block together with its links to the data processor, and they are consolidated into the spoofing and information-disclosure rows of Table 9 and the engagement-verification steps of Section 3. Their initial risk levels follow the same scheme as the rest of the catalog: tampering with or blinding of the driver-facing camera, tactile, and seat sensors, and denial of service on their links to the inner sensor block and the data processor are rated High because each can corrupt or remove the readiness estimate that gates handover timing during an active TOR. Spoofing and information disclosure of the DMS signals range from Low to Medium, reflecting both the cross-modal redundancy of the readiness estimate—no single spoofed modality is decisive—and the privacy- rather than safety-dominated nature of in-cabin data disclosure. No DMS scenario reached the Critical level, which remains confined to the actuator-block denial of service (TS218); after the recommended treatments are applied, the High-rated DMS scenarios reduce to Low, except the inner-sensor-block-to-processor link which reduces to Medium, and the disclosure scenarios to Negligible.

Table 9. STRIDE-based threat analysis and treatment matrix for TOR assets.

STRIDE	Asset	Property	TOR Failure Mode	Specificity	Treatment	Initial Risk	Final Level
Spoofing	Outer sensors, V2X interface	Authenticity	Falsified hazard or ODD-exit signal; spurious or suppressed TOR	Shared ADAS/TOR-relevant	Mutual authentication, signed sensor messages, plausibility checks across modalities	High	Low
Tampering	CPU, sensor-to-CPU links, HMI commands	Integrity	Suppressed, distorted, or late TOR alert; tampered MRM fallback commands	Mixed; TOR-specific when HMI timing is affected	Secure boot, runtime attestation, message authentication, AEAD on critical channels	High	Medium
Repudiation	Event and audit logs	Non-repudiation	Inability to verify whether TOR was issued or delivered correctly	TOR-specific when timing evidence is affected	Tamper-evident logging with cryptographic signing, HSM-backed timestamping	High	Low
Information Disclosure	Driver-monitoring streams, sensor data plane	Confidentiality	Exposure of occupant or scene data; privacy and compliance impact	Shared ADAS/DMS-related	TLS 1.3/AES on sensitive links, access control, key rotation	High	Low/ Negligible
Denial of Service	CAN bus, Ethernet backbone, CPU	Availability	Blocked, delayed, or muted TOR delivery within the time budget; blocked MRM fallback execution	Mixed; TOR-specific when handover deadline is affected	IDS, rate limiting, QoS for TOR signalling, redundant alert channels	Critical	Medium
Elevation of Privilege	Diagnostic/OTA ingress, CPU	Authorisation	Unauthorised reprogramming or runtime override of TOR logic	Shared ADAS/TOR-relevant	Authenticated diagnostics, signed updates per ISO 24089, least privilege	High	Low

Specificity classifies how each threat relates to the TOR function: Shared ADAS/TOR-relevant denotes a threat on the broader ADAS attack surface (shared with other automated functions) whose consequence is nonetheless material for the takeover request; TOR-specific denotes a threat whose hazardous effect materialises only through the handover itself, typically by affecting the timing or delivery of the alert; and Mixed denotes an asset shared with general ADAS that becomes TOR-specific under handover-timing conditions (e.g., when the handover deadline or HMI alert timing is affected). Shared ADAS/DMS-related is a special case of the first category for driver-monitoring assets, whose exposure additionally affects the readiness estimate consumed by the TOR.

5.7. STRIDE-Based Consolidation of Critical and High Risks

To integrate the findings into a coherent framework, the most safety-relevant threats were mapped to STRIDE categories, linking adversary objectives to typical attack vectors and recommended countermeasures. Across all critical and high-risk scenarios, tampering and denial of service dominate the safety-relevant impact dimension, while spoofing and information disclosure dominate the trust and privacy dimensions. This consolidation clarifies prioritisation (Critical, High, Medium, Low), supports traceable risk treatment, and aligns directly with ISO/SAE 21434 requirements for threat identification, risk analysis, and treatment planning [9].

Table 9 summarises the consolidated mapping. Each row shows the STRIDE category, the asset most exposed for the TOR function, the violated security property, the dominant TOR failure mode, the recommended treatment, and the resulting risk level after the treatment policy is applied. The mapping uses the assets listed in Table 5 and the matrix from Table 6.

6. Discussion

This section interprets the TARA results across cross-cutting threat patterns, presents the defence-in-depth mitigation strategy organised by control domain, addresses emerging threat vectors that are not yet fully covered by current standards, and maps the proposed treatments back to the regulatory and engineering frameworks introduced in Section 2.

6.1. Cross-Cutting Threat Patterns

Across the critical and high-risk scenarios reported in Section 5, three observations recur. First, the dominance of tampering, denial of service, and spoofing reflects the central role of integrity, availability, and authenticity in any TOR pipeline that depends on sensor fusion and timely message delivery. Confidentiality remains relevant for privacy and compliance but is secondary to the safety-driven properties. This ranking is consistent with comparable automotive TARA studies on safety-critical functions such as Automatic Emergency Braking, where availability and integrity attacks on the perception-to-actuation chain dominate the high-impact threat space [24]. However, the TOR-specific contribution differs from AEB because the safety effect is mediated through the human handover process. In AEB, the main concern is typically whether braking is triggered incorrectly, delayed, or unavailable. In TOR, the cyber effect may appear as a late, false, suppressed, or misleading takeover request, which then affects driver perception, reaction time, engagement confirmation, and fallback execution. Therefore, TOR risks depend not only on perception and control integrity, but also on driver readiness, HMI delivery, and the remaining handover time budget. Table 10 summarises the conceptual differences between AEB-oriented and TOR-oriented TARA.

Table 10. Conceptual differences between AEB-oriented and TOR-oriented TARA.

Aspect	AEB-Oriented TARA	TOR-Oriented TARA
Main safety effect	Incorrect, delayed, or unavailable braking	Late, false, suppressed, or spoofed handover request
Human role	Limited immediate intervention	Central; driver must perceive, understand, and respond
Critical timing issue	Time-to-collision and brake actuation timing	Handover time budget and driver re-engagement timing
Key trust anchors	Perception sensors, ECU, brake actuator	CPU, sensor-to-CPU links, DMS, HMI channels, MRM path
Distinct TOR contribution	Not primary focus	Links cyber compromise to driver readiness, alert delivery, and fallback execution

Second, risk concentrates at a small number of trust anchors: the central processing unit that performs fusion and decision logic, the sensor-to-CPU links that feed the TOR trigger, and the HMI channels that transport the alert to the driver. Compromise at any of these anchors can defeat downstream protections; for example, even hardened HMI actuators cannot rescue a TOR campaign if the CPU has been induced to suppress the request. This concentration motivates the placement of strong controls at trust boundaries rather than uniformly across all assets.

Third, the threats most likely to cause severe safety outcomes are those that interact with the time budget of the handover. A delayed alert is not merely an availability concern; in combination with reduced driver readiness it can transform a recoverable scenario into an unrecoverable one. The safety impact of a cyber event therefore depends on context. A short delay in TOR delivery may be tolerable during low-demand driving with an attentive driver, but the same delay may be significantly more severe during dense traffic, a construction zone, adverse weather, or a low-readiness driver-monitoring state. The TOR therefore differs from many other in-vehicle functions in that the temporal envelope is itself a safety-critical property and must be protected by the overall security design.

6.2. Defence-in-Depth Mitigations

The vulnerabilities identified in Section 5 cannot be addressed by any single control. The proposed mitigation strategy is organised into four complementary domains: physical and hardware security, software measures, network measures, and compliance with industry standards.

6.2.1. Physical and Hardware Security

Physical security of TOR components is the first line of defence against adversarial manipulation. Unauthorized access to ECUs, sensors, or actuators can lead to direct tampering with the takeover decision chain. Debug and diagnostic ports such as OBD should be disabled in production or protected with strong authentication, and access to in-vehicle gateways must be limited to authorized maintenance personnel. Tamper-evident seals and housings, combined with tamper-detection circuits that raise system alerts or trigger fallback policies on intrusion, deter physical attacks against TOR-related ECUs. Hardware Security Modules (HSMs) integrated in the TOR controller harden cryptographic operations and key storage, supporting robust authentication so that only trusted sensors and actuators communicate with the TOR processor, authenticated encryption (e.g., AEAD) for commands and sensitive sensor feeds, and integrity verification through secure boot and runtime attestation. Redundancy across alerting channels (e.g., haptic plus visual) and backup actuator paths increases the likelihood that TOR notifications remain perceivable when one channel is unavailable or degraded. However, this claim is qualitative; the present work does not quantify redundancy through structural reliability or topological robustness metrics.

6.2.2. Software Measures

Software is a prime attack vector for TOR systems, particularly through manipulation of data flows and control logic. ECUs shall execute only manufacturer-signed images, with runtime attestation detecting unauthorised modification. Anomaly-based intrusion detection tailored to TOR communication (e.g., repeated alert suppression, false TOR triggers) should be coupled to rapid containment or safe-fallback policies. OTA and service updates must be signed, verified, and traceable end-to-end, in line with ISO 24089 software-update engineering [10]. Sensor-fusion plausibility checks across modalities and over time (e.g., RADAR, LiDAR, and camera consistency) reduce the risk from spoofed or corrupted feeds. Tamper-evident logging with digitally signed entries, HSM-backed storage, and secure timestamping preserves accountability and supports forensic investigation. The proposed cryptographic and logging controls may introduce processing and communication overhead. Secure boot, runtime attestation, TLS 1.3 session establishment, certificate validation, AEAD processing, and secure logging must therefore be engineered so that they do not consume the TOR handover time budget. In this paper, these controls are proposed at the architectural and TARA level; their exact latency cost was not measured experimentally. Future implementation should benchmark under normal and attempted DoS conditions.

6.2.3. Network Measures

Because the TOR relies on multiple links spanning CAN, Automotive Ethernet, and external V2X, securing these interfaces is essential. Mutual authentication using certificate-based mechanisms ensures that only verified entities participate in TOR-relevant exchanges. Sensitive TOR traffic (driver-monitoring streams, fusion outputs, actuator triggers) is protected with modern cryptography such as TLS 1.3 and AES-256. Continuous monitoring of CAN and Ethernet for floods, spoofing, or unauthorised injection allows early containment before TOR performance degrades. Quality-of-service mechanisms prioritise TOR signalling under load or attempted disruption. Sending TOR alerts via at least two independent channels (e.g., CAN and Ethernet, visual and haptic) reduces dependence on a single communication or HMI path, although it does not eliminate common-cause failures such as CPU compromise, gateway compromise, or coordinated bus flooding.

For V2X-based TOR inputs, the mitigation strategy should also consider V2X-specific standards. IEEE 1609.2 and ETSI ITS security define certificate-based authentication, signed cooperative messages, pseudonym certificates, and trust-management mechanisms for vehicular communication. These standards are relevant for spoofing, repudiation, replay, and privacy risks on the V2X interface, especially when cooperative hazard messages influence ODD awareness or TOR timing.

6.2.4. Compliance with Industry Standards

Technical improvements must be coupled with rigorous adherence to industry standards to support type approval and lifecycle assurance. ISO/SAE 21434 embeds security requirements across concept, development, production, operation, and decommissioning, and requires risk assessment and post-production monitoring. ISO 26262 harmonises cybersecurity controls with safety goals so that countermeasures do not compromise TOR timing or safety mechanisms. ISO 21448 addresses hazards from functional insufficiency or foreseeable misuse using sensor plausibility, escalation policies, and fallback strategies. UNECE R155 governs the integration of these activities into the vehicle CSMS, while UNECE R157 sets the function-level requirements for transition demand and MRM. ISO 24089 ensures cryptographically protected, auditable updates for all TOR-relevant ECUs [10].

6.3. Emerging Threat Vectors

Two emerging threat classes deserve early attention even though they are not yet fully covered by current automotive standards.

6.3.1. AI/ML Model Poisoning

Modern TOR pipelines increasingly rely on machine-learning components for perception and driver-state estimation. The training and packaging pipelines for these components introduce a class of integrity threats where the artefact may be cryptographically valid but behaviourally malicious, evading traditional signature-based validation. Practical defences extend artefact integrity beyond cryptographic authenticity to include provenance and reproducibility metadata, signed training-data lineage, and continuous monitoring of post-update behaviour with stakeholder-defined acceptance criteria for safety-relevant performance regressions. For TOR specifically, this matters because subtle distribution shifts in driver-state classification or hazard recognition can shift the time budget of the handover without triggering a hard failure. In STRIDE terms, model poisoning maps most closely to Tampering: it violates the integrity of the ML artefact and its training-data lineage. A secondary Spoofing aspect arises because a poisoned-but-cryptographically-valid model masquerades as a legitimate one, defeating signature-based validation.

6.3.2. Quantum Computing Threats and Crypto-Agility

The vehicle lifecycle is long: a TOR ECU deployed today may remain in service for ten to twenty years, during which the threat model on the underlying cryptographic primitives may change substantially. Future cryptanalytic advances, including those enabled by quantum computing, could reduce the security margin of widely deployed public-key schemes used for OTA signing, secure-channel establishment, and certificate-based authentication. The architectural requirement is crypto-agility: the TOR cryptographic stack should be designed to rotate algorithms and keys, support hybrid transitions, and avoid hard-coding primitives that cannot be replaced in the field. This is particularly relevant for trust-anchor functions such as ECU secure boot, OTA package verification, and HMI command authentication, where compromise of a single primitive could undermine multiple layers of defence. In STRIDE terms, the eventual failure of public-key primitives maps to Spoofing and Tampering—forged certificates and signatures would let an adversary impersonate trusted entities and pass off tampered OTA packages or sensor messages as authentic—together with Information Disclosure, since traffic captured today under a “harvest-now, decrypt-later” strategy could be decrypted once the underlying scheme is broken.

6.4. Limitations and Future Work

The present study provides a standards-aligned, model-based TARA of the TOR function and establishes a traceable basis for identifying, rating, and treating cybersecurity risks across the handover path. As a purely analytical study, the attack-feasibility and impact values were assigned by expert judgement following the HEAVENS rating scheme rather than derived from empirical penetration testing or measured attack-cost data; the resulting risk magnitudes should therefore be read as a relative prioritisation of the TOR attack surface rather than as absolute, empirically validated measurements. The analysis is intended as a reusable reference for SAE Level 2–3 TOR architectures and can be further calibrated for specific OEM platforms, supplier implementations, and network topologies.

Future work could extend this foundation through implementation-level validation. Bench testing and vehicle-level penetration testing can be used to confirm the feasibility assumptions in the threat catalog. In parallel, latency benchmarking should quantify the timing impact of TLS 1.3, mutual authentication, AEAD, certificate validation, runtime attestation, and secure logging to ensure that security controls remain compatible with the TOR handover time budget.

7. Conclusions

This paper presented an ISO/SAE 21434-aligned Threat Analysis and Risk Assessment of the takeover request component in Advanced Driver Assistance Systems for SAE Level 2–3 automation. By modelling the TOR pipeline as an integrated set of perception, driver-monitoring, decision, network, and HMI assets, the work produced a STRIDE-based threat catalog using Microsoft Threat Modeling Tool and Ansys Medini Analyze, with risk ratings and treatment policies traceable to ISO 26262, ISO 21448, and UNECE R155 and R157.

The TARA revealed that tampering with processor data and control flows, denial of service on processing and communication channels, and tampering with sensor feeds dominate the safety-critical risk space, while spoofing, repudiation, elevation of privilege, and information disclosure dominate the high-risk space. In the initial assessment, 1 threat was rated Critical and 113 were rated High, reflecting the most safety-relevant scenarios affecting TOR timing, alert delivery, sensor integrity, processor control, and auditability. After applying the proposed mitigation measures, no Critical or High residual risks remained; the final distribution was reduced to 13 Medium, 101 Low, and 51 Negligible risks. These findings concentrate on a small number of trust anchors: the central processing unit, the sensor-to-CPU links, and the HMI channels through which the alert reaches the driver. The results also confirm that the TOR function is not only a generic ADAS cybersecurity problem: its risk is shaped by the interaction between cyber compromise, driver readiness, alert delivery, engagement verification, and the available handover time budget. The temporal envelope of the handover is itself a safety-critical property, which differentiates TOR from many other in-vehicle functions.

The proposed defence-in-depth strategy spans hardware (HSMs, tamper detection, redundancy), software (secure boot, anomaly detection, plausibility checks, signed updates), networks (mutual authentication, encryption in transit, monitoring, redundant alert channels), and compliance with ISO/SAE 21434, ISO 26262, ISO 21448, ISO 24089, and UNECE R155 and R157. The strongest treatment effects were achieved by combining secure boot, runtime attestation, message authentication, sensor-fusion plausibility checks, intrusion detection, rate limiting, secure logging, and protected update mechanisms. These controls directly address the critical and high-risk clusters identified in the TARA and explain the reduction of all Critical and High rows to Medium, Low, or Negligible residual levels. Two emerging threat vectors, AI and machine-learning model poisoning and post-quantum cryptographic exposure, motivate early adoption of provenance metadata, behaviour monitoring, and crypto-agility for long-lifecycle vehicles.

Future work should focus on validating and refining the proposed TARA with implementation-level evidence. This includes benchmarking and testing CAN/Ethernet flooding, sensor-feed manipulation, DMS spoofing, HMI suppression, and MRM fallback-command interference. Further work should also measure the latency introduced by security controls such as TLS 1.3, mutual authentication, AEAD, certificate validation, runtime attestation, and secure logging to ensure that they remain compatible with the TOR handover time budget. Finally, graph-based analysis, including centrality analysis, cut-set identification, and attack graphs, could complement STRIDE by identifying high-impact trust boundaries and data flows in the TOR architecture.