The Holes That Emerge Only in the Whole and Not the Parts:
A Systems View of Cybersecurity Assessments
Some vulnerabilities remain invisible in individual components but emerge when assessed as part of a fully integrated system. Focusing solely on isolated parts can create a false sense of security, while critical risks—stemming from system interactions, dependencies, and overlooked pathways—often remain undetected. A truly effective cybersecurity assessment demands a systems approach, for it is only by evaluating the whole that we can expose the holes that lie beneath the surface.
Many cybersecurity assessments today rely heavily on using client applications, user interfaces, and tools designed for intended workflows. However, this focus introduces blind spots, as assessments often verify compliance with expected behaviours rather than identifying adversarial misuse cases. As a result, critical vulnerabilities may remain undetected, posing significant risks to connected automotive systems.
In the past few days, insights from our own assessments and recently disclosed cybersecurity incidents have highlighted recurring challenges in lesser-discussed areas such as client applications, user interfaces, and toolchains within the automotive domain. While these examples represent only a small fraction of the broader cybersecurity landscape, a clear pattern has emerged—underscoring the urgent need for OEMs to prioritise not only component-level security but also system-level assessments to address the growing risks from offboard components of connected vehicles, particularly those arising from security assumptions made at the client side such as mobile apps enforcing access controls without backend verification, web applications relying solely on UI-based authentication, or diagnostic tools being fully trusted to enforce software update sequences without independent validation at the ECU level.
Real-World Lessons in Automotive Cybersecurity: The Illusion of Security
Client-Side and Toolchain Trust: A Dangerous Assumption
The Problem
In today’s security-conscious world, organisations invest significant effort into frameworks such as Threat Analysis and Risk Assessment (TARA) and varying levels of validation activities. They meticulously implement fundamental security measures. However, despite these efforts, a common theme persists: a misplaced trust in clientside enforcement.This trust often manifests in ways that leave systems vulnerable to attackers who can easily bypass intended security mechanisms using custom clients or manipulated workflows. The following real-world scenarios illustrate how misplaced trust in client
side enforcement leads to critical security gaps.
Mobile and Web Applications:
.png)
Secure Onboarding, Insecure Service Request Handling: Recent assessments of Mobile App APIs for EV charger management revealed that while the onboarding process had a well-implemented security logic, subsequent service requests were not consistently validated for authorisation. The backend relied entirely on the assumed trust established during onboarding, without revalidating permissions for each request. On the client side, configuration and management UIs were only accessible post-successful onboarding, creating a false sense of security—assuming that unauthorised users could not send service requests unless they had passed onboarding checks. However, attackers can bypass the mobile app entirely and interact directly with backend APIs, potentially executing unauthorized actions that the system fails to adequately protect.
Client-Side RBAC: An Illusion of Security Through Obscurity: A web application at an OEM implementing Role-Based Access Control (RBAC) enforced access controls only on the client side, selectively displaying or hiding menu options based on user roles. From a front-end developer’s perspective, this appeared to satisfy RBAC requirements by structuring UI screens according to roles and corresponding privileges. However, at the system level, this was misinterpreted as RBAC being fully implemented. This approach failed to account for misuse cases involving custom tooling beyond the intended client application. As a result, the backend did not validate access rights independently for each role, enabling unauthorised users to bypass restrictions using API proxy tools.
UI-Based 2FA: Security That Can Be Silenced: Some web applications rely on UI overlays to enforce 2FA, presenting users with a challenge to enter a secret only known to authorised users. However, a recent public attack[1] demonstrated how attackers can modify the web client’s code to suppress the 2FA challenge altogether, bypassing the intended security measure if the backend does not explicitly enforce 2FA validation.
.png)
Hidden in the App, Exposed in the Backend: The Risk of Unsecured API Endpoints A security researcher discovered an unreleased feature in an automotive mobile app, allowing them to manipulate a robotaxi’s top display because backend servers did not validate requests from unauthorised users [2].
Diagnostic Tools and ECUs:
Software Updates and the Risk of Blind Trust in OEM Tools: Software update mechanisms typically enforce payload integrity checks and a defined sequence of operations to ensure secure deployment to ECUs. However, ECU software development teams may sometimes rely solely on the OEM diagnostic tool to implement and validate the update process, fully trusting the tool to enforce the update sequence and assuming deviations are impossible. This reliance can lead to a lack of independent validation within the ECU, leaving it unable to detect misuse cases. In one instance, an ECU processed and executed certain commands from the tester that, with proper stateful awareness, should have been rejected. Attackers, leveraging custom-built update clients, can exploit these weak assumptions, leading to system compromise.
Why Do These Issues Keep Happening?
For many, these vulnerabilities seem fundamental—often regarded as foundational cybersecurity principles—yet they continue to resurface across the industry.
While security by design aims to prevent such risks at the development stage, the bigger concern is why these well-known security flaws continue to slip through verification and validation activities during product development.
1. Accelerated Development, Unverified Security: The Overlooked Need for System-Wide Security
The need for timely product deployment often places constraints on system-wide cybersecurity penetration testing, resulting in a focus on immediate functionality over comprehensive security validation. Additionally, some risk management practices, without fully considering real-world threats, may incorrectly assume that component-level assessments are sufficient based on the perceived cyber relevance of individual parts in isolation. This can result in an inaccurate assumption that comprehensive system-level validation is unnecessary.
2. Static Risk Assessments in a Dynamic Ecosystem
Threat Analysis and Risk Assessment (TARA) frameworks may overlook the full scope of onboard and offboard interactions, leading to security gaps that only become evident when assessing the entire vehicle ecosystem holistically. This often happens because offboard use cases, applications, and interfaces are not fully developed or visible during a vehicle-level TARA, which typically prioritizes onboard system components for type approval. Without a dynamic TARA approach that revisits security at key checkpoints, emerging threats tied to system design flaws may go undetected during verification activities that often follow the path paved by TARA.
3. Commoditisation of Cybersecurity Assessments
To cut costs and meet compliance, cybersecurity assessments are often reduced to checklist-based exercises, missing real-world attack vectors and overlooking security flaws stemming from fundamental system design issues.
4. Testing Focuses on the "Happy Path
Security functional testing often relies on toolchains designed solely for intended workflows, without addressing potential misuse or abuse cases. This overreliance results in gaps where attacker toolchains and unconventional attack vectors remain untested, leaving vulnerabilities undetected.
5. Siloed Development Processes
Automotive systems are developed across multiple departments and even different organizations, each focusing on their respective components. While individual teams may assume that security requirements are met within their scope, there is often a lack of sufficient understanding of system-wide security implications at the integrator’s end. This fragmented approach can result in unaddressed vulnerabilities, as security gaps that emerge from interdependencies between components may not be thoroughly validated at the system level.
A Call to Action: Closing the Gaps
Addressing these challenges requires moving beyond conventional security testing approaches and adopting a more system-oriented cybersecurity strategy. The following key measures can help close the identified security gaps:
1. Prioritise System-Level Assessments
Expand security assessments beyond component-level testing to systematically evaluate vulnerabilities arising from interactions between system elements. While component-level assessments remain critical, new and evolving threats often do not manifest at the component level but emerge only when assessing the system as awhole. While holistic security validation is widely recognized as best practice, it is often deprioritized due to timing constraints or operational pressures. Ensuring that system wide assessments remain a core part of cybersecurity validation is essential to prevent critical security gaps from going unnoticed
2. Challenge the "Happy Path" Mindset
Security functional testing must proactively address adversarial scenarios early in the verification phase, ensuring that real-world misuse cases are identified before they become systemic vulnerabilities. Client toolchains should not act as a thick layer of abstraction, limiting visibility into potential security gaps. Instead, assessments must extend beyond intended workflows to detect misuse cases that may be overlooked when relying solely on predefined toolsets. A balanced approach is required to ensure attacker toolchains and unconventional attack vectors are tested effectively, minimizing overlooked vulnerabilities.
3. Adopt a Dynamic, System-Wide Risk-Based Approach
TARA processes must thoroughly assess offboard interactions and prioritise high impact threats from a holistic perspective. Given the natural segregation in the industry between onboard and offboard security teams and operations, a system-wide perspective must complement component-level assessments. These assessments should be treated as dynamic and continuously revisited throughout the product development lifecycle. As offboard connected services, functions, features, and applications take shape, the evolving security landscape must be accounted for in a living TARA process. This ensures that emerging threats—especially those associated with offboard components and services—are proactively identified and mitigated before they pose a security risk at the system level.
Final Thought
At the heart of these vulnerabilities is a lack of proper authorisation enforcement at the backend or ECU level. Many verification activities focus too heavily on UI-driven interactions and expected toolchain behaviour, inadvertently missing adversarial misuse cases.While component-level security remains a cornerstone of cybersecurity, without a complementary system-wide approach, critical security gaps may persist undetected.
Just as certain vulnerabilities emerge only in the whole and not the parts, cybersecurity must embrace a holistic, system-wide approach— evaluates component interactions rather than treating them in isolation. Relying solely on fragmented validation creates security blind spots, which often remain unnoticed until attackers exploit them by deviating from the intended design flow.
True resilience lies in continuous validation, adversarial testing, and an adaptive risk assessment strategy that evolves alongside the system itself. The key to securing modern automotive systems is balancing both component and system-level assessments, adopting proactive assessment, dynamic threat modeling, and an unwavering commitment to securing the whole system—both onboard and offboard.
Trust nothing, verify everything—challenge client-side assumptions and adopt a systems approach to security enforcement, aligning with key Zero Trust principles.