IVI (In-Vehicle Infotainment)
IVI is the vehicle head unit that runs apps, media and connectivity, often on Android or Linux. Why it is a large attack surface and what hardening checks look for.
Updated This page as Markdown
In short
IVI (In-Vehicle Infotainment) is the head unit that handles media, navigation, phone projection and connectivity. Modern units run a full operating system, often Android Automotive or embedded Linux, with apps, services, permissions and network interfaces like any computer. That makes the IVI one of the largest and most connected attack surfaces in the vehicle, and its hardening, exposed debug access, app permissions, readable files, is a standard security test target.
What is IVI?
IVI is the vehicle head unit: the screen and the computer behind it that run media, navigation, phone projection, voice, app stores and the connectivity that feeds them. Early head units were fixed-function devices. Modern ones are general-purpose computers on an automotive system-on-chip, running a full operating system with installable apps, background services, a permission model and multiple radios.
Because the IVI talks to the outside world and to the in-vehicle networks at the same time, it is both exposed and well connected, which is exactly what makes it interesting to an attacker.
Where is it defined?
There is no single IVI standard. Android-based units follow the Android Open Source Project automotive documentation and the Android security model (app sandboxing, permissions, SELinux). Linux-based units follow general Linux hardening practice. The relevant security expectations come from the project security concept and from threat catalogues such as UN R155 Annex 5, which lists threats to back-end connectivity, external interfaces and vehicle data that apply directly to the head unit.
What it means in practice
An IVI hardening review looks at the same things a mobile or Linux review would, in an automotive context: debug access that should be closed in production, apps that are debuggable or over-permissioned, components exported to other apps without protection, files that can be pulled off the device, secrets baked into apps, and the SELinux or sandbox posture.
In infotainment platform tests we regularly see production units with ADB enabled, apps that ship debuggable, world-readable system properties and files that expose configuration or credentials. None of these is exotic; they are the result of development settings that survived into the shipped image.
How AutoST tests it
AutoST connects to an Android IVI over ADB and runs a hardening assessment: it enumerates packages, dangerous permissions, exposed components, pullable files and the SELinux posture, and performs static analysis of installed APKs for manifest flags such as debuggable builds and for hard-coded secrets. Findings are grouped by severity with remediation and flow into the same Fix Plan as the UDS and DoIP results.
Common misunderstandings
The IVI is not harmless just because it does not steer or brake. It is a connected computer with paths toward the rest of the vehicle. And a locked-down infotainment OS is not the same as a secured vehicle: the gateways and ECUs behind it need their own testing.
FAQ
Frequently asked questions
What operating systems do IVI units run?
Commonly Android Automotive OS or embedded Linux, sometimes QNX, often several together on one SoC with a hypervisor. Phone projection such as Android Auto and Apple CarPlay runs on top as a session from the connected phone, not as the head unit OS itself.
Why is the IVI a security concern if it is not safety-critical?
It is one of the most connected components in the car, with cellular, Wi-Fi, Bluetooth, USB and app stores, and it often sits on the same networks as other ECUs. A weakness there can be a foothold, and from the head unit an attacker may reach gateways and diagnostic paths that lead deeper into the vehicle.
Is testing an IVI the same as testing an ECU over UDS?
No. A UDS test talks to a diagnostic stack over CAN or DoIP. An IVI hardening test works at the operating system level, over a debug interface such as ADB, and looks at apps, permissions, services and files rather than diagnostic services.
Sources
Related pages
- GlossaryAndroid Automotive OS (AAOS)Android Automotive OS runs natively on the head unit and talks to the vehicle through the Vehicle HAL. How it differs from Android Auto and what we find on the bench.
- GlossaryADB (Android Debug Bridge)ADB is the Android debug interface over USB or TCP port 5555. Why it is the first thing to check on an Android head unit, and what an open ADB gives an attacker.
- GlossarySOME/IP (Scalable service-Oriented MiddlewarE over IP)SOME/IP is the AUTOSAR middleware for services on automotive Ethernet: header, methods, events and service discovery. What it is and why exposed services are a finding.
- InsightsAndroid IVI security checks every head unit should passHardening checks for an Android head unit: build type, debug flags, ADB exposure, SELinux, exported components, app flags and secrets, and what each means.
- PlatformThe screen is an attack surface too.AutoST checks Android infotainment over ADB: dangerous permissions, exposed components, pullable files, SELinux posture and APK static analysis, with per-finding fixes.
