Hey, Vertical TARA Integration! Why We Need to Link Cyber Risk Analyses Across System Boundaries

Now comes the problem: fragmented TARAs in complex systems

Now, does this already provide sufficient opportunities to conduct clean cyber risk assessment work with a unified understanding of potential cyber risks and their consequences (especially in complex vehicle development projects)?

No.

The problem is the isolated analyses.

It looks something like this:

• Supplier A creates a TARA for its camera system,
• Supplier B creates a TARA for its radar system,
• the OEM creates its own TARA for its ADAS system or directly at the vehicle level.

In this scenario, risks at the subsystem level remain trapped “below”; for system TARAs, the subsystems are a black box. Assumptions must be made; multimodalities, redundancies (among other things) cannot be holistically assessed.

Put concretely: Both, the causes of a risk and the consequences of how it affects connected systems or components, are not transparently or comprehensibly documented.

This creates particular difficulty in identifying the exact origin and impacts of risks — a holistic, consistent risk assessment is ultimately structurally hindered.

In this context, we speak of opaque risk propagation — that is, the impeded traceability, which ultimately impairs the correct determination of risk values (in terms of impact and feasibility).

Introducing a new cyber risk working reality: Vertical TARA Integration

A solution approach that has been methodologically discussed in the industry for years but has not yet been realized in practice in a tool- and process-supported manner to date: the vertical linking of TARA. In other words, an approach to systematically embed subsystem analyses into higher-level system TARAs — without having to evaluate everything twice.

The idea behind it: Consciously reduce the level of detail (and the associated resource expenditures) without losing information relevant to decisions at the system level.

How does Vertical TARA Integration work?

Vertical TARA integration refers here to the integration of TARA analyses that establishes a continuous workflow across multiple levels of a system hierarchy.

For example: Component → Subsystem → Vehicle → Fleet/Backend.

The goal is for the TARA to be organized at each level with clear work products and information handoffs, so that damages, probabilities, and mitigations are coherently passed forward, consolidated, and fed back.

Brief interjection: To this day, neither UN R155 nor ISO/SAE 21434:2021 use the terminology as a technical term — yet they demand precisely the lifecycle-oriented and collaborative risk management that makes such integration or nesting actually necessary.

The prerequisite for vertical integration is initially a hierarchical level that forms the starting point for nesting. Simply conceived, something like:

• Subsystems (e.g., LiDAR, radar, camera)
• Systems (e.g., ADAS functions)
• Overall vehicle

Core idea of Vertical TARA: Damage Scenarios as the interface for data transfer

In vertical TARA integration, a disciplined passing forward of risk findings from the component level to the overall system is to be realized — with a clear data handoff point: the damage scenario outlined above.

This way, the technical depth of analysis work stays where it belongs (in the subsystem), while the system level works with consolidated, comparable building blocks.

Concretely, this means:

1. A subsystem conducts its own TARA: It identifies assets, attack surfaces, and models threat scenarios; from these, it derives damage scenarios with impact and feasibility assessments.
2. For each damage scenario, all associated attack paths are aggregated internally: Multiple paths that produce the same harmful state are consolidated; path-specific details remain internal, while essential context metadata (e.g., required privileges, assumptions) are carried forward.
3. Only the damage scenarios are passed upward: This protects IP while simultaneously providing the next higher level with exactly the information relevant for prioritization and treatment — including consistent IDs and versions.
4. The higher-level system uses these damage scenarios as attack steps without needing to know subsystem details: The system/vehicle level incorporates the delivered damage scenarios into its own risk paths, maps feasibility to the internal scale, and evaluates impact where it originates (vehicle, fleet, operations).

This approach reduces complexity while simultaneously increasing the required consistency — and incidentally creates the urgently needed better traceability across levels and organizational boundaries, as well as faster, less person-dependent decisions.

How does Vertical TARA work? Here is an example

Let’s imagine a real-world interaction: A LiDAR subsystem delivers distance information to an ADAS (Advanced Driver Assistance System). Damage scenarios are the ideal linking point here because they describe the result state of a compromised subsystem — independent of how the attacker got there.

Let’s be clear again: For the ADAS system (or the involved security risk analysis department), the task is to assess the risks present here (and any protective mechanisms potentially required) in its own system — but not necessarily to deal with attack paths in the supplied subsystems in detail.

So let’s look at the interaction with a precise view of the typical states of the LiDAR subsystem → ADAS.

In its own TARA, the LiDAR team consolidates its findings into three clear damage scenarios, each with impact and feasibility assessment:

• DS1: Failure (no distance values)
• DS2: False distance values (systematically falsified)
• DS3: Noisy data (heavily fluctuating quality)

For each such state, there may be multiple attack paths internally on the LiDAR team’s side (e.g., firmware manipulation, interface abuse, timing disruptions). These paths are consolidated per damage scenario for the analysis in the ADAS system, so the system level only sees what’s essential:

• What can happen? (described damage/state)
• How likely is this state? (an aggregated feasibility, i.e., a consolidated feasibility value that considers all known paths)

Important: The associated attack paths are logically already contained in the feasibility of the respective damage scenario. The subsystem thus preserves its detailed IP but provides context-relevant metadata (e.g., required privileges, affected software versions, assumptions) so the system level can correctly classify the assessment. (Here, it should be possible to define granularly which “meta-information” should be provided alongside the damage scenario if in doubt.)

How does the system (ADAS) use the damage scenarios?

Following the vertical TARA integration approach presented here, the ADAS now imports only the damage scenarios, not the attack paths modeled internally in the subsystem. Thus, the original damage scenario within the TARA of the higher-level system becomes an attack step (not to be confused with an attack path), i.e., a possible attack. This approach ultimately follows the simple logic that at the higher level, one is typically interested in the impact and not in how one gets there.

This means: System attacks or risk chains are built from the received damage scenarios — without needing to know the subsystem details in detail. In the example, these would be:

• Missing collision warning (uses DS1 “Failure”) – if no LiDAR values arrive, the warning logic can fail or react too late.
• Misclassified objects (uses DS2 “False distance values”) – if distances systematically appear too small/large, object fusion breaks down; consequences can be false braking or missed braking.

Important beyond this: The subsystem can cheerfully define feasibilities at its own level. The already aggregated feasibility values delivered by the LiDAR are transferred to the in-house system scale and interpreted in the context of the system architecture and existing controls; they are not adopted wholesale or added across subsystems, but specifically utilized for the respective own risk chains.

Impact assessment deliberately occurs only at the system/fleet level, because only there does the actual effect emerge (driving state, speed, traffic density, or field deployment frequency ultimately determine to what extent the same impact represents what actual impairment.)

This approach keeps the risk calculation consistent, avoids the mentioned opaque risk propagation (same DS-ID below as above), and enables deriving precise requirements and controls from the system perspective that can be specifically fed back to the LiDAR and adjacent functions.

Benefits for the higher-Level TARA through Vertical TARA Integration

The methodology of vertical TARA integration presented here is not rocket science at all, not even a reinvention or further development of TARA.

Rather, vertical TARA integration represents a simple but well-thought-out way to efficiently connect existing analyses. Through the demonstrated handoff of damage scenarios, which are reused as attack steps in the higher-level system, details remain where they belong (with the supplier/subsystem), while developed risks traceably “migrate” across boundaries because the same state (DS-ID) remains identical below and above.

Very concretely, the consistent application of the principle of vertical TARA integration yields specific, measurable value:

• Scalability & variant capability: Existing damage scenarios can be reused; variants only add specific damage scenarios. Base results remain stable, effort and review cycles shrink, releases become more plannable.
• Better OEM–supplier collaboration with IP protection: The system level receives risk-relevant information (impact, feasibility, scope of validity) without internal attack graphs being disclosed. This reduces friction, accelerates coordination, and strengthens trust.
• Decision-making capability & prioritization: Damage scenarios are communicative: A “DS: unwarranted emergency braking” is equally tangible for management and engineering. Prioritization across domains becomes possible, budget decisions become more robust — and faster.
• Traceability across levels and lifecycle: From system risk to subsystem requirement and back to effectiveness evidence in the field: The chain remains closed. Audits thus address not just documents but demonstrable relationships.
• Speed & efficiency in implementation: Changes focus on deltas. New supplier releases or patches are mapped to affected damage scenarios; re-assessments remain targeted rather than broad — a fundamental added value also for newly discovered vulnerabilities with regard to cybersecurity collaboration throughout the entire product lifecycle.
• Independence from manual doings and “manual arbitrariness”: The damage scenario interface enforces a minimum of metadata (preconditions, privileges, assumptions) and allows well-defined mappings to the system scale. Decisions thus become less team- or person-dependent.
• Audit/compliance fitness: Damage scenarios can be directly linked to operational security controls (e.g., OTA gates, monitoring). This creates verifiable evidence for CSMS obligations — not just meaningless prose in analysis work.
• Methodological compatibility with system models: Identical states can be anchored at different points in the architecture and function model — without dissolving model ownership. This strengthens consistency within MBSE/architecture work.

Additionally, TARA at the system level gains operational sharpness through vertical integration:

• Prioritization where it counts: For example, an ADAS can more intelligently weigh system attacks against each other — such as higher severity for “missing collision warning” versus higher feasibility for “misclassified objects.”
• More clarity for deriving measures: From system analysis, targeted requirements may fall back to the subsystem more easily and with better argumentation, e.g.: plausibility checks (cross-checks with camera/radar), self-diagnostics (detection of failure/noise in the field), or robust update controls (to complicate paths that favor false distance values).
• Increase capability to act for ongoing cybersecurity in the lifecycle: In case of incidents, rescoring of damage scenarios is enabled in ongoing lifecycle phases, or even in operations; new damage scenario versions propagate back into the model and trigger, if necessary, additional controls. TARA finally remains truly “living” instead of static.

Vertical TARA Integration: outlook and tool support

The bottom line is that the structured nesting of TARA analyses creates an abstracted but technically valid toolkit: Subsystems deliver damage scenarios as a unified language of risks, the system level assigns impact and priority where they originate (vehicle, fleet, operations).

Complexity decreases, consistency increases, decisions can be made faster and more sustainably — without losing the required technical depth.

It is precisely this compatibility that makes collaborative, variant-rich systems and complex architectures manageable from a cyber risk analysis perspective and enables the higher-level TARA to fulfill its actual purpose: making risks comparable system-wide, treating them in a targeted manner, and demonstrably controlling them throughout the lifecycle.

And at the same time, it fundamentally increases clarity in complex systems and structures collaboration between suppliers and OEMs — without creating additional complexity, as it remains within the familiar framework of the methodology.