# IVI (In-Vehicle Infotainment)

> 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.

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.

Source: https://auto-st.com/glossary/ivi · Updated: 2026-10-07

## 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

**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

- [Android Open Source Project, Automotive documentation](https://source.android.com/docs/automotive)
- [UN Regulation No. 155, Cyber security and cyber security management system, Annex 5](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)

## Related

- [Android Automotive OS (AAOS)](https://auto-st.com/glossary/android-automotive)
- [ADB (Android Debug Bridge)](https://auto-st.com/glossary/adb)
- [SOME/IP (Scalable service-Oriented MiddlewarE over IP)](https://auto-st.com/glossary/some-ip)
- [Android IVI security checks every head unit should pass](https://auto-st.com/insights/android-ivi-security-checks)
- [The screen is an attack surface too.](https://auto-st.com/ivi-security-testing)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/ivi