This regulation was developed by the Cybersecurity and Software Updates Taskforce (CS/OTA TF) under WP.29, the Working Party on Automated/Autonomous and Connected Vehicles of the United Nations Economic Commission for Europe (UNECE). It specifies cybersecurity requirements to protect vehicles against cyber threats. Under this regulation, vehicle manufacturers are required to establish a Cybersecurity Management System (CSMS) and obtain vehicle type approval (VTA) from an approval authority for each vehicle type. CSMS must include processes for assessing, categorizing, and treating cybersecurity risks throughout the vehicle lifecycle. The approval authority reviews whether risk assessment activities have been conducted adequately for the vehicle type by the CSMS during the VTA process.

ISO/SAE 21434 is an international standard for cybersecurity engineering in road vehicles. It outlines systematic procedures to ensure cybersecurity throughout the entire vehicle lifecycle. The standard specifies detailed requirements and work products that support compliance with the abstract-level requirements of UN Regulation No. 155, making it a practical guideline for both vehicle manufacturers and suppliers. In particular, clause 15 defines the TARA method, which can be applied at any stage of the development lifecycle.

TARA is a risk-based cybersecurity analysis method that identifies and evaluates potential threats to protected assets, quantifies associated risks, and derives appropriate mitigation strategies. Although various TARA methodologies, such as E-safety Vehicle Intrusion Protected Applications (EVITA) and HEAling Vulnerabilities to ENhance Software Security and Safety (HEAVENS), have been proposed in both academia and industry, the publication of ISO/SAE 21434 has shifted the focus toward approaches that comply with its specified TARA requirements. The standard defines a TARA method consisting of seven modules. Upon completion of the TARA, all identified cybersecurity threats and their corresponding risk values are produced, along with traceable risk treatment decisions. Table 1 presents the TARA methods as specified in ISO/SAE 21434.

Early research on vehicle TARA in the field of automotive cybersecurity was based on global initiatives, particularly EU-led projects such as EVITA [10] and HEAVENS [11], which laid the foundational methodologies for assessing cybersecurity risks in vehicles.

Henniger et al. [12] proposed a model to systematically analyze cybersecurity threats in vehicle networks (IVN) as part of the EVITA project. In this model, system assets are first identified based on representative use cases such as vehicle-to-everything (V2X), diagnostics, and eCall, and subsequently, as described in Section 2, the model executes only a subset of the TARA process to derive the final security risk value. This procedure has since been widely adopted in most subsequent studies on automotive risk assessment. In this paper, the authors aimed to align the impact rating with the international functional safety standard in the automotive industry [13]. However, the proposed model does not define weighted criteria for impact categories, assuming that safety, privacy, operational, and financial impacts are of equal importance.

Wolf and Scheibel [14] proposed a risk assessment model that assigns category-specific weights to impact categories, enabling the cost-effective implementation of security countermeasures based on a quantitative evaluation. In this model, potential security threats and high-level security objectives are derived from misuse cases that describe scenarios in which security assets can be exploited. A potential security threat refers to a method by which an attacker can intentionally trigger a misuse case. In contrast, a high-level security objective denotes the intended security goal that mitigates such threats. According to ISO/SAE 21434, these elements are defined as threat scenarios and security goals, respectively. The model utilizes the Common Evaluation Methodology (CEM) [15] to assess the attack potential of each identified potential security threat. Simultaneously, the damage potential is assessed in terms of safety, financial, and operational categories and the final risk value is derived accordingly. Although this model is considered well suited for automotive systems where safety is the primary concern, it exhibits a significant limitation in that it does not explicitly account for privacy-related impacts, which are explicitly required by the ISO/SAE 21434 standard.

Islam et al. [16] proposed HEAVENS 1.0, a risk assessment model developed as part of the HEAVENS Project, which incorporates Microsoft’s STRIDE [17] for threat modeling and considers multiple impact dimensions, including safety, financial, operational, privacy, and legislation, during impact assessment; however, since this methodology was developed before the standards and regulations discussed in Section 2, it does not align with these current standards. To address this, Lautenbach et al. [18] introduced HEAVENS 2.0 by updating 17 elements—including the removal of legislative impact parameters and the addition of damage scenario identification and attack path analysis—to ensure full compliance with UN Regulation No. 155 and ISO/SAE 21434. However, it still lacks integrated procedures that reflect stakeholder-specific characteristics (e.g., vehicle manufacturers and suppliers) and ensure consistency in the vehicle perspective during the execution of TARA.

Recent follow-up studies have extended early TARA frameworks by narrowing their scope to specific application areas, such as vehicle ad hoc networks (VANETs) or autonomous driving systems, or by focusing on the evaluation of particular impact dimensions, most notably privacy-related risks.

Ren et al. [19] proposed a risk assessment approach designed to protect location privacy within a defined system model for VANET. In this study, threats related to location privacy leakage were analyzed using a top-down attack tree approach, which enabled the derivation of specific attack scenarios. Then each scenario was evaluated based on three criteria proposed by the authors: attack cost, technical difficulty, and probability of detection. This paper provides a detailed analysis of attack paths and the feasibility of attacks related to location information leakage. However, it focuses solely on attack path analysis and attack feasibility rating modules among the various components of TARA. Thus, it does not fully satisfy all TARA requirements as defined in ISO/SAE 21434.

Chah et al. [20] proposed a privacy threat modeling approach for autonomous vehicle systems by applying the Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance (LINDDUN) framework [21]. In this study, a data flow diagram (DFD) was constructed based on the network architecture of a Connected and Autonomous Vehicle (CAV), followed by the identification of privacy-related threat scenarios and the mapping of corresponding Privacy Enhancing Technologies (PETs) to mitigate those threats. However, the analysis is narrowly focused on privacy within autonomous vehicles and does not include evaluations of damage scenarios resulting from threats or the feasibility of attack realization, thereby falling short of meeting the comprehensive requirements of threat and risk assessment as defined in standards such as ISO/SAE 21434.

Park and Park [22] proposed a cyber-resilient risk assessment model tailored for autonomous vehicles by extending traditional risk assessment factors—Probability and Impact—with two additional dimensions: Exposure and Recovery. Exposure was introduced to assess how accessible the vehicle is and how well-known its vulnerabilities are, while Recovery was added to evaluate how quickly a compromised system can return to normal operation. This includes factors such as real-time detection and response capabilities, patching ability, and response time across the supply chain. This methodology differentiates itself from other TARA approaches by incorporating post-attack resilience into risk assessment, potentially altering the prioritization of risk treatment decisions. However, it presents certain limitations: Although recovery-related factors such as patch-ability and supply chain responsiveness require close collaboration between vehicle manufacturers and suppliers, the model does not provide detailed procedures to support such coordination. In addition, it does not account for threats that can only be identified by suppliers, leaving potential gaps in the risk evaluation process.

Kiening and Angermeier [23] analyzed which TARA elements should be shared when TARA is performed across different organizations and proposed a method for defining responsibilities in distributed engineering contexts. This approach applies the concept of the Cybersecurity Interface Agreement in ISO/SAE 21434 to TARA, allowing each organization to perform a partial TARA within its own engineering scope while sharing only the information required for cross-organizational integration. It also considers intellectual property protection by limiting the scope of information exchanged between organizations. However, this approach does not provide detailed criteria for reconciling stakeholder-dependent differences in impact ratings, integrating newly identified assets with existing assets, or incorporating implementation-level design information into attack paths as development progresses.

The proposed orchestration model has been developed by considering two key perspectives: the stakeholder perspective and the system lifecycle perspective.

The first perspective considered in the proposed mechanism is that of the stakeholders, primarily vehicle manufacturers and suppliers. Vehicle manufacturers possess a comprehensive understanding of the vehicle’s E/E architecture and the interactions among multiple systems, while suppliers have deep expertise in the detailed design of hardware and software components within individual systems. The proposed orchestration model considers these characteristics and facilitates close collaboration between stakeholders at each stage of the TARA process.

The second perspective focuses on the vehicle development lifecycle. Vehicle manufacturers typically perform TARA during the concept phase, where the analysis is performed based on system functions, preliminary architectures, and various assumptions. As a result, a gap arises between the concept phase assessment and the series of production vehicles or systems. To bridge this gap, suppliers should share information about cybersecurity vulnerabilities related to selected hardware and software components with vehicle manufacturers during the product development phase. This enables the identification of new assets, the clustering of assets with similar characteristics and damage scenarios, and the bottom-up derivation of attack paths.

To obtain VTA, vehicle manufacturers must ensure not only consistent evaluations across all systems from the vehicle perspective but also detailed analyses of each system. The proposed orchestration model addresses this need by considering both the distribution of expertise throughout the automotive supply chain and the structure of the vehicle development lifecycle, supporting a more comprehensive and detailed approach to regulatory readiness.

In the concept phase, TARA is carried out in close collaboration between the vehicle’s perspective and the system’s perspective, based on limited design information such as system functions, a preliminary architecture, and a reference system model. From the vehicle perspective, the analysis focuses on impact rating by striving to ensure consistency and traceability from system to system, identifying attack paths based on vehicle E/E architecture, and considering regulatory and market-specific constraints. In contrast, the system perspective focuses on identifying system-specific functions, associated assets, and damage scenarios, with a particular emphasis on impact rating and analyzing technical attack paths. Fig. 1 presents the interactions between the vehicle and system perspectives for each TARA activity in layer 1.

L1-1 Asset identification: From the perspective of the system, all assets required to perform the functions of a given system are identified, and potential damages resulting from the compromise of the cybersecurity properties of each asset are evaluated. Each asset is described in detail—covering its functional role, associated components, creation timing, originator, and any stored or transmitted data—to facilitate a shared understanding among stakeholders.

From the vehicle perspective, the vehicle manufacturer receives asset identification results from all vehicle systems and compiles a list of transmitted and received assets, along with potential damage scenarios for each asset. This holistic review enables the assessment of consistency at the vehicle level and helps identify assets that are missing or no longer in use. It also enables the identification of missing assets in individual systems by comparing commonly implemented functions, such as diagnostics, between systems.

L1-2 Threat scenario identification: From the perspective of the system, threat scenarios are determined that could compromise the cybersecurity properties of the identified assets. Where applicable, each threat scenario can also include descriptions of the attack surface utilized, the potential attacker, and the tools used. Subsequently, from the vehicle perspective, threat scenarios collected from all constituent systems are reviewed to ensure consistency across the vehicle. Detailed threat scenario information is then shared with other systems to support the development of consistent technical attack paths during attack path analysis.

L1-3 Impact rating: From the system perspective, the impact of the identified damage scenarios is rated across four categories: Safety, Financial, Operational, and Privacy. However, because suppliers conduct system-perspective impact ratings based on the functionality and assumptions of individual systems, the results may not fully reflect vehicle-level contextual factors, such as legal and regulatory requirements applicable in the target market, the vehicle E/E architecture, and the degree of functional redundancy within the vehicle. Moreover, the same system may be deployed in different vehicle types and sold in different countries or regions, which makes vehicle-perspective evaluation necessary. For this reason, the system-perspective results are re-rated from the vehicle perspective by incorporating these factors. This re-rating step enables the vehicle manufacturer to review supplier-derived impact ratings consistently, rather than merely aggregating system-level results produced under different assumptions. It helps ensure that the assessments of all in-vehicle systems are reflected as consistent impact ratings at the level of the target vehicle.

Eqs. (1) and (2) present a formulation that takes the system-perspective impact rating (denoted as IRICsys) as input and applies a vehicle-perspective coefficient to re-rate it into the vehicle-perspective impact rating (denoted as IRICveh). (1)IRICveh=logb(IRICsys+ε)γadjveh (2)γadjveh={Cveh_type+Cbackup,if IC=Safety,Cveh_type+Creg,if IC=Financial,Cveh_type+Cbackup,if IC=Operational,Creg,if IC=Privacy.

In (1), IRICveh represents the result of the impact rating from the vehicle’s perspective for a given impact category IC (IC∈{Safety,Financial,Operational,Privacy}). IRICsys represents the corresponding result of the impact rating from the system perspective. The base b in logb⁡(IRICsys+ε) determines how sensitively IRICsys is reflected in the computation of IRICveh; a smaller b causes changes in IRICsys to have a larger influence on the resulting IRICveh. The constant ε is a small positive value added to ensure positive arguments for the logarithmic transformation. Finally, γadjveh is the vehicle-perspective coefficient that accounts for vehicle-perspective factors such as vehicle type, target-market regulatory requirements, and functional redundancy. The logarithmic transformation is used to moderate excessive linear amplification when vehicle-level contextual factors are applied to system-perspective impact ratings. Because TARA impact ratings are ordinal in nature, the numerical result of Eq. (1) should not be interpreted as an interval-scale measurement. Instead, it is used as an intermediate value to support consistent vehicle-perspective re-rating and should be mapped back to the predefined impact rating mapping table.

In (2), γadjveh is defined such that different coefficients are applied depending on the impact category. Cveh_type reflects the relative risk associated with the vehicle category (e.g., passenger car, bus, truck); Cbackup reflects the impact associated with the number of backup systems in the vehicles, including the target system itself and its backup systems; and Creg reflects the impact associated with the country-specific regulatory requirements.

In the Safety category, it is determined by Cveh_type and Cbackup because safety severity depends on the vehicle’s size and purpose, as well as the redundant systems that can mitigate failures. In the Financial category, it is calculated using Cveh_type and Creg as financial impacts are influenced by the vehicle’s market segment and the stringency of country-specific regulatory requirements. In the Operational category, it is determined by Cveh_type and Cbackup because operational continuity depends on the vehicle’s usage context and the availability of backup functions. In the Privacy category, it is determined by Creg because privacy impacts can be evaluated differently depending on target-market regulatory requirements.

Table 2 summarizes the ranges and descriptions of the coefficients used to compute γadjveh. To ensure consistent scaling across impact categories, each coefficient is mapped to a bounded range of [1.0,3.0]. This range should be interpreted as a relative weighting scale for vehicle-level contextual factors, rather than as an absolute or statistically calibrated measurement. A value of 1.0 represents a neutral or lower contextual influence, while larger values represent stronger vehicle-level influence. For example, a passenger car may be assigned a higher coefficient than a quadricycle because it typically operates at higher speeds and in broader traffic conditions, whereas a truck or bus may receive a higher coefficient because a cybersecurity incident may affect more passengers or surrounding road users. Cveh_type categorizes vehicles into three types and assigns a corresponding coefficient value. Creg differentiates the coefficient value based on the presence and stringency of regulatory requirements in the target market; for instance, privacy regulations vary across regions such as the EU, Asia, and South America, which can lead to distinct assessments. Finally, Cbackup reflects functional redundancy by assigning the coefficient value as a function of the number of in-vehicle systems capable of providing the target function, including the assessed system itself and its backup systems. The specific values of the b, ε, and the coefficients should therefore be regarded as configurable parameters that may be calibrated according to project-specific assessment criteria, expert judgment, and organizational risk tolerance.

L1-4 Attack path analysis: From the system perspective, the analysis focuses solely on technical aspects. Using a top-down approach, the system examines various technical methods and procedures that an attacker might use to realize a given threat scenario. For instance, if an attacker aims to tamper with configuration data stored within the system, they might exploit available wired or wireless interfaces or physically dismantle the device to gain access. The analysis may also involve distinguishing between wireless communication protocols, such as Bluetooth and Wi-Fi, identifying known vulnerabilities for each, and specifying the corresponding exploitation techniques. The comprehensive enumeration of such methods constitutes the technical attack path from the system perspective.

From the vehicle perspective, potential attack paths that an attacker should traverse to access a target system are analyzed based on the vehicle’s E/E architecture. For instance, if an attacker intends to influence the driving behavior of a vehicle remotely, the attack path would sequentially involve external communication systems, gateway system, and ultimately reach the driving-related system. This ordered sequence of systems that an attacker should pass through to perform a malicious action is referred to as the E/E architecture-based attack path.

The vehicle perspective ultimately consolidates the E/E architecture-based attack paths and the technical attack paths of each system to construct a unified attack path that represents how a specific asset can be compromised in the context of the entire vehicle.

L1-5 Attack feasibility rating: From the system perspective, the attack feasibility of each identified technical attack path is evaluated. However, since this evaluation is limited to individual systems, an integrated analysis is subsequently conducted from the vehicle perspective. The vehicle perspective collects the attack feasibility ratings for all technical attack paths from the constituent systems and integrates them with the E/E architecture-based attack paths. Based on this integration, vehicle-level attack feasibility ratings are adjusted and shared with each corresponding system. These results are then used in the subsequent step to determine the risk values of the threat scenarios from the system’s perspective. For example, if an attacker seeks to remotely influence the vehicle’s driving system, the identified attack path may involve sequentially compromising external interfaces, a gateway controller, and ultimately the driving system. In such a case, the final attack feasibility rating for the threat scenario is determined by a dependency-aware aggregation method that evaluates feasibility along the identified attack path, propagating the highest feasibility value among child nodes to their parent nodes. From the attacker’s perspective, achieving the root node of the attack path requires traversing both the technical attack path and the E/E architecture-based attack path. In an E/E architecture-based attack path, the parent node typically represents another system, whereas in a technical attack path, it corresponds to a specific technical method or procedure. The attack feasibility rating therefore identifies the most exploitable route among the possible attack paths. The most critical aspect of this evaluation lies in the logical AND/OR relationships between the parent and child nodes. In an AND relationship, the aggregated feasibility of all child nodes defines the parent node’s feasibility rating; hence, as the number of AND nodes increases, the overall difficulty of the attack also increases. In contrast, in an OR relationship, only the child node with the highest attack feasibility rating, representing the easiest route, is propagated upward as the feasible attack path. This approach inherently accounts for path interdependencies and ensures that shared components across multiple paths have consistent feasibility ratings.

L1-6 Risk value determination: From the system perspective, the risk values of all identified threat scenarios are calculated using predefined risk matrices or risk formulas. From the vehicle perspective, the consistency of the calculated risk values across all systems is reviewed to ensure that they have been derived using the correct, predefined matrices or formulas.

L1-7 Risk treatment decision: From a system perspective, risk treatment decisions are made based on predefined criteria. Each risk is treated through one of the following strategies: reducing the risk, avoiding the risk, sharing the risk, or retaining the risk. From the vehicle perspective, the outcomes of these risk treatment decisions across all systems are reviewed to ensure consistency and traceability throughout the vehicle. For example, if the mitigation decision for a threat identified in system A involves sharing responsibility with system B, vehicle-level analysis verifies whether the corresponding threat has been appropriately addressed in system B. Furthermore, when threats are treated through reduction, avoidance, or retention strategies, the vehicle perspective checks whether consistent criteria have been applied across all vehicle systems to ensure a uniform level of cybersecurity throughout the vehicle.

In the product development phase, the focus shifts to incorporating additional or modified elements into existing TARA results based on changes identified after the concept phase, as well as detailed information that can only be obtained during the development process. From the system perspective, emphasis is placed on refining asset identification by detailing previously identified assets down to the signal level and performing asset clustering, as well as on analyzing attack paths by identifying vulnerabilities introduced by the selected hardware and software stacks. Similarly to Layer 1, the perspective of the vehicle involves checking the consistency and alignment of TARA results across multiple systems from the perspective of the vehicle’s E/E architecture.

Fig. 2 presents the interactions between the vehicle and system perspectives for each TARA activity in Layer 2.

L2-1 Asset identification: In Layer 2, asset identification is performed under the assumption that the security goals, as determined through the Layer 1 TARA, have already been incorporated into the system. From the system perspective, if new security mechanisms have been implemented to meet these goals, additional assets—such as cryptographic keys or freshness counters—may be identified. Alternatively, abstract assets defined in Layer 1 may be further refined and decomposed to the signal level, significantly enhancing the precision of the TARA. As a result, dozens or even hundreds of assets may be newly identified. However, this increase in asset count can lead to substantial resource consumption in subsequent TARA activities.

To address this issue, asset clustering is performed to group assets that are expected to produce the same risk level into a single representative asset. A risk outcome is considered equivalent when the anticipated impact rating and attack feasibility rating for the assets are identical, indicating that the assets are expected to share the same damage and threat scenarios.

As such, asset clustering can be applied when all of the following conditions are satisfied: 1.

Operational context: The assets exist in the same operational context. Stored data shall reside in the same type of memory (e.g., volatile or non-volatile) and be placed at an equivalent physical location on the printed circuit board (PCB). Communication data must be transmitted using the same method (e.g., wired or wireless) and protocol (e.g., CAN, Automotive Ethernet).

Eq. (3) presents the preliminary clustering condition under which two assets are regarded as equivalent. Two assets a and b are regarded as equivalent if and only if they are deployed in the same operational context, serve the same operational purpose, and lead to the same damage-scenario type when compromised:(3)a∼b ⟺ (O(a),F(a),D(a))=(O(b),F(b),D(b))

Once assets are clustered according to these criteria, a mapping table should be maintained to ensure traceability between individual assets and their corresponding representative asset throughout the TARA process. The table should include fields such as asset ID, representative asset ID, asset type, memory or protocol attributes, functional role, and rationale for clustering, thereby enabling consistent traceability and transparency in asset management.

L2-2 Threat scenario identification: Similar to Layer 1, the system perspective in Layer 2 focuses on identifying threat scenarios associated with newly identified or refined assets. Subsequently, from the vehicle perspective, threat scenarios from all constituent systems are collected and examined for consistency across the vehicle architecture. The results of this consistency check are then communicated to each system to ensure alignment and coherence within the overall TARA process.

L2-3 Impact rating: The detailed activities and procedures from both the system and vehicle perspectives in Layer 2 are identical to those in Layer 1. The only distinction lies in the additional evaluation of newly identified damage scenarios, for which new impact ratings are assigned accordingly.

L2-4 Attack path analysis: From the perspective of the vehicle, the activities of Layer 2 remain consistent with those of Layer 1. However, the system perspective introduces a bottom-up approach to derive additional technical attack paths. During the product development phase, the specific hardware and software stacks required to implement the functionalities of the system are determined through detailed design processes.

In this context, the bottom-up approach extends the attack paths identified in Layer 1 by incorporating new technical attack paths resulting from the selection of microcontroller units (MCUs), application processor (AP) chipsets, printed circuit board (PCB) structures, and software stacks. To support this analysis, various information sources can be leveraged, including system-level penetration testing results, known vulnerabilities from the Common Vulnerabilities and Exposures (CVE) and National Vulnerability Database (NVD) databases, as well as academic papers and conference materials.

To enhance the efficiency of repeated attack path analyses, common elements can be categorized based on chipsets, software components, or communication protocols and managed as a structured database. This database can also be reused in the post-production stages to support incident response and vulnerability management.

L2-5 Attack feasibility rating: The activities and procedures conducted from both the vehicle and system perspectives in this phase are identical to those in Layer 1. However, the only distinction is that, if new technical attack paths are identified from the system perspective using a bottom-up approach, additional evaluations are performed for those paths. Furthermore, the feasibility ratings of the corresponding higher-level nodes should also be updated accordingly. It enables the determination of whether the path represents the most exploitable attack path.

L2-6 Risk value determination: Based on newly identified assets in Layer 2, new threat scenarios can be derived and new risk values may also be calculated due to vulnerabilities arising from selected hardware and software.

L2-7 Risk treatment decision: A new risk treatment decision is made based on this series of processes. The method for selecting treatment options is the same as in Layer 1. When a new security goal is identified as a result of risk mitigation in Layer 2, a comprehensive review of all Layer 2 is required to verify whether additional assets or threats must be considered.

The virtual vehicle used in this analysis is a high performance electric vehicle (EV) equipped with Level 3 autonomous driving capabilities. It is designed as an SDV, enabling dynamic updates and modifications of vehicle functions via OTA updates. The E/E architecture of the vehicle is based on a two-layer control structure that integrates both zonal and function-based architectures. The Base Layer is responsible for defining the overall control strategy and monitoring vehicle operations. It includes the Vehicle Computer (VC), which manages functional safety and cybersecurity across the vehicle, and multiple Zonal Controllers (ZCs), each assigned to a specific physical zone of the vehicle. Based on the base layer, the adaptive layer supports vehicle-specific features such as autonomous driving and external communications. The target system for analysis, the Driving Control Unit (DCU): Rear, is located under the ZC: Rear in the vehicle’s E/E architecture. It controls the rear section of the vehicle by acceleration, deceleration, and steering. In addition, it supports driver-personalized functions such as rear wheel steering angle adjustment, suspension height and stiffness control, and software update capabilities.

Fig. 3 presents the E/E architecture of the target vehicle along with the functional overview of the system selected for analysis.

Through a progressively detailed analysis across development phases, we structurally identified the differences between the system and vehicle perspectives and examined how these differences are harmonized and integrated from the vehicle perspectives.

Prior TARA studies have typically demonstrated the applicability of their proposed methodologies by focusing on a specific system or function and presenting results within that limited context. This evaluation approach reflects the inherent limitation of methodology proposals, where case-based demonstrations are often used. In this study, we conducted a comparative analysis between the proposed model and previous TARA studies. The analysis was organized around four key criteria: (1) Coverage of ISO/SAE 21434 TARA Activities, (2) lifecycle-specific TARA procedures, (3) system-vehicle orchestration, and (4) applicability and scalability. The results of the analysis are presented in Table 4.

Coverage of ISO/SAE 21434 TARA activities refers to the extent to which each study explicitly addresses the seven TARA activities defined in ISO/SAE 21434. Several prior studies were developed before the publication of ISO/SAE 21434, while others were intentionally designed to address selected aspects of TARA, such as privacy protection, resilience-oriented evaluation, or specific attack analysis procedures. Therefore, studies with narrower coverage should be interpreted as focused contributions within their intended scope. In this comparison, Lautenbach et al. [18] and the proposed model cover all seven TARA activities, whereas the other studies explicitly address selected parts of the TARA process according to their research objectives.

In the automotive industry, lifecycle-based TARA procedures are often regarded as self-evident. However, most existing methodologies are limited to the concept phase or do not clearly articulate how TARA should differ between lifecycle stages. The proposed model overcomes these limitations by covering both the concept and product development phases, thereby incorporating new emerging threats and detailed design assets. In particular, during the development phase, the proposed model captures a large number of signal-level assets and consolidates them through asset clustering, which significantly enhances the precision of asset identification.

Orchestration between system- and vehicle-level analyses is indispensable to ensure consistency and coherence between distributed TARA activities, particularly to meet regulatory compliance requirements. From the perspective of vehicle manufacturers, consistency must be guaranteed in all in-vehicle systems. However, except for the proposed model, most existing approaches remain predominantly system-centric or fail to address how system-level results should be integrated at the vehicle level. the proposed model closed this gap by introducing an interaction mechanism that incorporated analysis information verified by relevant stakeholders at each stage of TARA, thus achieving seamless integration between system- and vehicle-level analyses.

From the perspective of applicability and scalability, most prior TARA methodologies could only be extended or applied to specific domains or system-level analyses. The approaches proposed by Ren et al. [19], Chah et al. [20] and Park and Park [22] demonstrated certain advances within limited contexts such as VANETs, privacy-related systems, or automated attack path generation, yet their applicability remained confined to specific environments without extending to other systems or lifecycle phases. In contrast, the proposed orchestration model demonstrates scalability not only across different systems but also at the vehicle level, confirming that it can be effectively extended to the vehicle level.

TARA activities inherently rely on expert-driven qualitative assessment, particularly in impact rating, attack feasibility rating, and risk treatment decision-making, where analysts should interpret damage scenarios, attack conditions, and acceptable risk levels based on domain knowledge and organizational policies. Therefore, an expert evaluation was conducted to assess whether the proposed orchestration model provides practical support for TARA activities from the perspective of automotive cybersecurity practitioners and researchers. This evaluation was not intended to provide comprehensive validation using industrial project data. Instead, it evaluated whether the proposed model provides structural support for more precise, consistent, traceable, and efficient TARA activities. The experts reviewed the proposed workflow, with particular attention to how vehicle-level and system-level TARA results are coordinated across the concept and product development phases.

The expert panel consisted of 12 participants from suppliers, TARA consulting companies, and research institutes, all of whom had experience in conducting or evaluating TARA activities. To reflect different perspectives in the automotive cybersecurity ecosystem, the panel included seven supplier experts, three TARA consulting experts, and two research institute experts. Each expert was provided with a summary of the proposed orchestration model, the virtual SDV case, and the evaluation questionnaire, and was asked to assess the model from the perspectives of precision, consistency, traceability, efficiency, and practical applicability.

The evaluation was conducted using an 11-item questionnaire based on a five-point Likert scale, where 1 indicated “strongly disagree” and 5 indicated “strongly agree.” The questionnaire was organized into five evaluation categories: precision, consistency, traceability, efficiency, and practical applicability. These categories were selected to reflect the main claims of the proposed model and to assess whether the model can support more systematic TARA activities in a vehicle manufacturer–supplier collaboration context. The detailed questionnaire items are summarized in Table 5. Precision was evaluated in terms of omitted asset identification, development-stage information, and attack path refinement. Consistency focused on the alignment of supplier-derived system-level TARA results with the vehicle-level assessment and the use of consistent criteria across in-vehicle systems. Traceability examined whether assets and TARA artifacts could be linked from the concept phase to the product development phase. Efficiency was assessed in terms of the potential reduction of duplicated analysis through asset clustering, while practical applicability considered the feasibility of applying the model to vehicle manufacturer–supplier collaboration and VTA-oriented evidence preparation.

Fig. 8 presents the expert-based qualitative evaluation results. The results by expert group show that the proposed orchestration model was evaluated positively across all groups, although the emphasis varied depending on the experts’ organizational backgrounds. Supplier experts provided the most conservative ratings, with an overall mean score of 3.87. Their lowest score was observed for efficiency, with a mean score of 3.43. However, this value remains above the neutral point of the five-point Likert scale, suggesting that the proposed model was still perceived as more effective than applying no structured orchestration approach. The relatively lower efficiency score may reflect the initial burden of adopting a new methodology, including learning the procedure, preparing structured TARA artifacts, and coordinating information across organizations. In contrast, TARA consulting experts gave the highest overall rating, with a mean score of 4.69. They rated consistency, traceability, and practical applicability particularly highly, with mean scores of 4.78, 4.83, and 4.83, respectively. This suggests that experts who frequently support cross-organizational TARA activities may recognize the value of harmonizing supplier-derived TARA results at the vehicle level. Research institute experts also evaluated the model positively, with an overall mean score of 4.40, and gave especially high ratings for precision and traceability, with mean scores of 4.67 and 4.75, respectively. This indicates that the lifecycle-aware linkage between concept-phase artifacts and product-development-phase details was considered methodologically useful. Overall, the results suggest that the proposed model was perceived as more useful than a conventional system-focused TARA approach across all evaluation categories, particularly in traceability and vehicle-level consistency.