Auto-ISAC 2026: Why Connected Vehicle Security Must Extend Beyond the Vehicle

Connected vehicle security is an architectural problem. As vehicles become software-defined platforms, their attack surfaces extend beyond electronic control units, in-vehicle networks, and manufacturing infrastructure to include mobile applications, cloud services, third-party integrations, and the APIs connecting them.

That was one of the key takeaways from the 10th Annual Auto-ISAC Cybersecurity Summit, held October 6–9, 2026, in Novi, Michigan. The conference offered a useful view of where the automotive cybersecurity industry is investing today—and where important gaps remain.

I attended on behalf of Approov and presented “Beyond Authentication: Securing Connected Vehicle APIs in the Age of AI.” The focus was the security boundary between connected vehicle services and the applications accessing them, particularly as automation makes API reconnaissance and exploitation easier to scale.

Three themes stood out: the industry's strong focus on operational technology (OT), the growing security implications of Android Automotive and connected infotainment, and the need to establish trust in API requests beyond validating credentials alone.

The Current Focus: OT Security Dominates the Conversation

More than 60% of the vendors I encountered at the summit focused on OT security. A significant number of sessions also addressed the protection of manufacturing plants, industrial robotics, physical operations, and the integration of OT environments with enterprise IT.

This emphasis reflects a legitimate concern. Automotive manufacturing is increasingly automated, and the convergence of IT and OT introduces security risks that can affect physical processes as well as digital infrastructure.

While OT was certainly in the forefront of the conference, individual conversations focused on evolving standards and risks that put RASP, Attestation, and other mobile security topics into the conversation.

Consider the complete request path: a customer opens a mobile application, the application communicates with a cloud API, and the backend retrieves data or initiates an operation involving the vehicle. Each component introduces its own trust assumptions and potential failure modes.

Securing the manufacturing environment or hardening the vehicle's internal systems does not automatically secure this application-to-API interaction. Similarly, strong identity controls do not necessarily establish the integrity of the software making a request.

These are different security problems that require complementary controls.

The opportunity for the industry is to bring mobile application and API security into the same architectural discussion as IT, OT, and vehicle security—not as a replacement for those disciplines, but as a necessary extension of them.

Beyond Authentication: Establishing Trust at the API Boundary

My presentation, “Beyond Authentication: Securing Connected Vehicle APIs in the Age of AI,” examined a fundamental limitation in many API security architectures: authentication can establish that a user or client presents valid credentials, but it does not necessarily prove that the request originates from a genuine, untampered application.

That distinction becomes increasingly important when mobile applications expose connected vehicle data and functionality.

An attacker does not always need to compromise the backend directly. They may reverse-engineer an application, reproduce its API requests, automate interactions, or manipulate the runtime environment in which the application executes. If the backend relies primarily on credentials or bearer tokens, it may have limited visibility into whether a request comes from the intended application or an attacker-controlled implementation.

AI-assisted tooling adds another dimension. Automated systems can accelerate reconnaissance, probe API behavior, and help identify weaknesses across large numbers of endpoints. The underlying vulnerabilities are not necessarily new; the speed and scale at which they can be investigated and exploited are changing.

This creates several architectural considerations for automotive API security:

• Application authenticity: Can the backend establish that a request originates from the genuine application rather than a clone or reimplementation?
• Runtime integrity: Can the system identify applications executing in compromised or instrumented environments?
• Credential resilience: What happens when an attacker extracts, reuses, or automates access with otherwise valid credentials?
• Enforcement at the API boundary: Can the backend reject requests that fail application-trust requirements before sensitive operations are performed or data access granted?

The objective is not to replace authentication, authorization, rate limiting, or API gateway controls. It is to complement them with evidence about the application making the request.

Approov addresses this gap through mobile application attestation and runtime secret protection. It verifies application authenticity and integrity, providing backend services with cryptographic evidence that can be used to enforce access policies. This helps distinguish requests from trusted application instances from traffic generated by cloned, tampered, or otherwise untrusted environments.

For connected vehicle services, that distinction is particularly relevant wherever a mobile application acts as the gateway to sensitive vehicle data or remote functionality.

The broader principle is straightforward: API security should evaluate not only who is making a request, but also whether the software making it can be trusted.

The EU Cyber Resilience Act: Product Security Becomes an Operational Obligation

The EU Cyber Resilience Act (CRA) was another recurring topic at the summit. Its significance extends beyond regulatory compliance: it reinforces the need to treat cybersecurity as a lifecycle responsibility for products with digital elements.

The CRA's mandatory reporting obligations began applying on September 11, 2026. Under the applicable requirements, manufacturers must report actively exploited vulnerabilities and severe security incidents affecting products with digital elements through the designated EU reporting process involving ENISA's Single Reporting Platform.

The next major milestone is December 11, 2027, when the CRA's principal product cybersecurity requirements are scheduled to apply.

For automotive manufacturers, these obligations raise practical questions about the scope of product security, vulnerability discovery, incident response, and the ability to demonstrate that appropriate controls are in place.

The connected vehicle is not an isolated product from a security perspective. Its software ecosystem may include embedded operating systems, infotainment applications, smartphone apps, cloud infrastructure, and third-party services. Weaknesses in any of these components can create exposure elsewhere in the system, depending on the architecture and the privileges involved.

Several discussions at the summit suggested that the CRA will increase scrutiny of connected vehicle security, including mobile applications and infotainment head units.

From an engineering perspective, this is an argument for mapping trust boundaries and dependencies across the complete connected product—not simply checking individual components against a compliance checklist.

Manufacturers need to understand where sensitive operations are exposed, which components can invoke them, how access is verified, and how vulnerabilities can be identified and addressed throughout the product life cycle.

Regulatory compliance and effective security are not synonymous. However, the CRA provides an additional incentive to make security controls, ownership, and incident-handling processes more explicit and demonstrable.

Android Automotive: The Expanding Software Attack Surface

Another important development is the rise of the Android Automotive platform. Android Automotive, which runs natively in the vehicle, is distinct from Android Auto, which projects compatible smartphone applications onto a vehicle's display. As automakers seek advanced platforms to build more connected smart cars, they have increasingly turned to the Android Automotive platform. Using this as the basis for a modern infotainment system allows for a better connected car experience as well as data access. I recently downloaded an Android app to my car’s system which collects data regarding charging, speed, efficiency and trip tracking data directly from the vehicle. The data is then transferred directly to the apps backend, where it powers a companion app to present this data on the go. This highlights the broad scope of the added risks from implementing Android Automotive. How do automakers protect their APIs and apps running on the vehicle? Application-security challenges involved include application integrity, permission boundaries, software updates, data protection, and the isolation of components with different levels of privilege.

During the summit, I asked the CISO of one of the largest automakers in the world about his level of concern regarding Android Automotive security. His response was that he was “very concerned,” and that his teams were doing “a lot of work” to secure Android Automotive and other connected vehicle environments.

That response was a useful indication of the engineering attention these platforms require.

For manufacturers, the challenge is not simply to secure an operating system. It is to ensure that applications, services, and APIs operate within explicitly defined trust boundaries—and that a compromise in one component does not automatically grant access to another.

For Approov, the most relevant opportunity is at the mobile application and API layers, where applications connect to backend services and, depending on the architecture, to vehicle-related functionality. Application attestation and runtime API protection can help enforce trust requirements at these boundaries.

The key is to apply the appropriate controls at each layer rather than assume that security at the operating-system or vehicle-network level is sufficient to protect the entire connected service.

Third-Party Vehicle Platforms: Who Controls Access to the Data?

I also expected more discussion about platforms such as Smartcar and Enode, which enable third-party services to integrate with connected vehicle data and functionality. I called these platforms “parasitic” because they leverage data from auto manufacturers without their permission, using the credentials and authorization of individual users.

Surprisingly, these platforms generated relatively little feedback in my conversations with automakers or during my presentation.

There are several possible explanations. The teams responsible for these integrations may not have been well represented at the summit, or the security implications of third-party vehicle-data access may not yet be a major focus for some of the attendees. The limited discussion does not establish which explanation is correct.

Architecturally, however, the question deserves attention.

Every additional integration introduces another relationship in which access, authorization, data handling, and revocation must be managed. The relevant questions include what data a third party can access, which operations it can perform, how permissions are granted and withdrawn, and how the manufacturer can detect suspicious use.

A third-party platform may have legitimate authorization to access vehicle data, but that does not eliminate the need for appropriate controls over individual applications, users, API requests, and downstream use.

The security challenge is therefore broader than determining whether an integration is authorized. It is also about enforcing the intended scope of access and maintaining visibility as the connected ecosystem evolves.

This is an area where further engagement between automotive security teams, platform providers, and mobile/API security specialists could be valuable.

Three Architectural Priorities for Connected Vehicle Security

The summit reinforced three priorities that automotive security teams should consider as connected services evolve.

1. Extend security analysis beyond the vehicle boundary.

Threat modelling should include the full path from the customer-facing application through cloud APIs and third-party integrations to the vehicle-related service. The objective is to identify trust assumptions and failure modes across the entire interaction, rather than assessing each component in isolation.

2. Treat client integrity as a distinct security signal.

Authentication and authorization remain essential, but they answer different questions from application attestation. Where mobile applications provide access to sensitive APIs, backend services should consider whether the application is genuine and whether its runtime environment meets the required security conditions. The resulting trust signal should complement, not replace, identity and access controls.

3. Design for continuous change and automated threats.

Connected vehicle software, third-party integrations, and attacker tooling will continue to evolve. Security architectures need clear enforcement points, actionable telemetry, and effective vulnerability-management processes. As AI-assisted automation increases the speed of reconnaissance and exploitation, relying solely on static assumptions about clients and credentials becomes increasingly difficult to justify.

Looking Ahead

Auto-ISAC 2026 demonstrated that automotive cybersecurity remains heavily focused on OT and the protection of physical operations. That focus is necessary, but it is not sufficient to address the full security requirements of connected vehicles.

The software ecosystem surrounding the vehicle introduces its own attack surfaces and trust boundaries. Mobile applications, infotainment platforms, cloud APIs, and third-party services all contribute to the overall security posture.

The EU Cyber Resilience Act is increasing the importance of product security and vulnerability management. Android Automotive is expanding the software environment inside the vehicle. Meanwhile, AI-assisted automation reinforces the need to examine assumptions about application integrity and API access.

For Approov, the opportunity is to help automotive manufacturers address one specific but important part of this challenge: establishing trust in the applications connecting to their APIs.

The central engineering principle is that a valid credential does not, by itself, make a request trustworthy. Connected vehicle security needs layered controls that evaluate identity, authorization, application integrity, and the context in which access is requested.

As the automotive industry continues its transition toward software-defined vehicles, securing the interfaces between vehicles, applications, and cloud services must become an integral part of the security architecture—not an afterthought.