Volkswagen sperrt Custom-ROM-Nutzer aus: Was IT-Verantwortliche jetzt wissen müssen

Einleitung: Ein App-Sperrfall mit weitreichenden Folgen

Seit dem 20. Juli 2026 können Nutzer von alternativen Android-Betriebssystemen wie GrapheneOS oder LineageOS nicht mehr auf die offizielle VW-App zugreifen. Volkswagen hat den Zugang für Geräte gesperrt, die keine Zertifizierung durch die Google Play Integrity API bestehen. Was auf den ersten Blick wie eine interne Produktentscheidung eines Automobilherstellers wirkt, ist in Wirklichkeit ein Präzedenzfall mit erheblicher Relevanz für IT-Verantwortliche in deutschen Unternehmen.

Denn der Fall Volkswagen steht stellvertretend für eine wachsende Praxis: Unternehmen lagern Gerätevertrauensentscheidungen an kommerzielle Attestierungsdienste aus – mit potenziell drastischen Folgen für Datenschutz, Gerätekontrolle und regulatorische Compliance. Wer in seiner Organisation Dienstsmartphones mit gehärtetem Betriebssystem einsetzt oder BYOD-Richtlinien verwaltet, sollte diesen Fall genau analysieren.

Technischer Hintergrund: Was ist die Google Play Integrity API?

Das Attestierungsprinzip einfach erklärt

Die Google Play Integrity API ist ein Mechanismus, mit dem Android-Apps prüfen können, ob ein Gerät als „vertrauenswürdig" gilt – aus der Perspektive von Google. Konkret prüft die API drei Kernpunkte:

Custom ROMs wie GrapheneOS oder LineageOS scheitern regelmäßig am zweiten Kriterium: Sie sind nicht von Google zertifiziert, auch wenn sie technisch sicherer konfiguriert sein können als Standardsysteme. GrapheneOS beispielsweise wurde von Sicherheitsforschern und dem Chaos Computer Club (CCC) als eines der härtesten frei verfügbaren Android-Systeme eingestuft.

Warum ist das problematisch?

Das Paradoxon liegt auf der Hand: Ein System, das aus Sicherheitsgründen modifiziert wurde – etwa um Telemetrie zu deaktivieren, Angriffsflächen zu reduzieren und DSGVO-konform betrieben zu werden – wird von der Play Integrity API als weniger vertrauenswürdig eingestuft als ein Standardgerät mit maximaler Google-Anbindung. Die Entscheidungshoheit über Gerätesicherheit liegt damit faktisch bei einem US-amerikanischen Konzern, nicht beim betreibenden Unternehmen.

Für Unternehmens-IT bedeutet das: Eine externe, kommerzielle API bestimmt, welche Geräte zugelassen werden – unabhängig von eigenen Sicherheitsrichtlinien oder MDM-Konfigurationen.

NIS2-Relevanz: Was bedeutet das für die Compliance deutscher Unternehmen?

Betroffene Unternehmen unter NIS2

Seit Inkrafttreten der deutschen Umsetzung der NIS2-Richtlinie (Richtlinie EU 2022/2555) durch das überarbeitete BSI-Gesetz (BSIG) sind Tausende deutsche Unternehmen aus kritischen und wichtigen Sektoren zu konkreten Cybersicherheitsmaßnahmen verpflichtet. Dazu gehören u. a.:

• Energie- und Wasserversorgung
• Gesundheitswesen und Pharma
• Transport und Verkehr
• Digitale Infrastruktur und IT-Dienstleister
• Finanz- und Versicherungswesen

Für all diese Unternehmen schreibt NIS2 explizit vor, dass Sicherheit der Lieferkette (Art. 21 Abs. 2 lit. d), Zugriffskontrolle und Risikomanagement bei Drittanbietern gewährleistet sein müssen.

Konkrete Compliance-Risiken durch Play-Integrity-Abhängigkeiten

Der VW-Fall berührt gleich mehrere NIS2-Anforderungen:

1. Risikobasierter Ansatz (Art. 21 NIS2):
Wenn unternehmenskritische Workflows über Apps abgewickelt werden, die einseitig durch Drittanbieter-APIs gesperrt werden können, liegt ein unkontrolliertes Abhängigkeitsrisiko vor. Das BSI betont in seinen IT-Grundschutz-Kompendien (insbesondere Baustein SYS.3.2.1 – MDM) die Notwendigkeit vollständiger Kontrollierbarkeit mobiler Endgeräte.

2. Lieferkettensicherheit:
Die unkritische Integration von Attestierungsdiensten ohne eigene Risikoprüfung widerspricht dem Prinzip der sicheren Softwareentwicklung und Beschaffung nach NIS2.

3. Dokumentations- und Nachweispflichten:
Können Sie als IT-Verantwortlicher belegen, welche externen Dienste Zugangsentscheidungen für Ihre Systeme treffen? Wenn nicht, besteht Handlungsbedarf – denn im Ernstfall sind solche Abhängigkeiten melderelevant beim BSI.

Datenschutz nach DSGVO

Ergänzend greift die DSGVO: Die Play Integrity API übermittelt Gerätedaten an Google-Server – potenziell in die USA. Ohne entsprechende Drittlandtransfer-Grundlage (Art. 44 ff. DSGVO) oder Verarbeitungsverträge (AVV) kann der Einsatz solcher APIs in unternehmenskritischen Anwendungen datenschutzrechtlich problematisch sein.

5 konkrete Schutzmaßnahmen für IT-Verantwortliche

1. 🔍 Inventarisierung aller App-Abhängigkeiten von Drittanbieter-APIs

Erstellen Sie ein vollständiges Inventar der in Ihrer Organisation eingesetzten mobilen Apps – insbesondere solcher mit Zugriff auf Unternehmensdaten. Dokumentieren Sie, welche davon Play Integrity, SafetyNet oder vergleichbare Attestierungsdienste nutzen. Tools wie Mobile Device Management (MDM)-Lösungen (z. B. Microsoft Intune, VMware Workspace ONE) helfen dabei.

Ziel: Sichtbarkeit über externe Abhängigkeiten schaffen, die Zugangsentscheidungen beeinflussen.

2. 📋 BYOD-Richtlinien auf Attestierungsrisiken prüfen

Wenn Mitarbeiter eigene Geräte nutzen, besteht erhöhtes Risiko: Viele sicherheitsbewusste Nutzer betreiben Custom ROMs. Prüfen Sie, ob Ihre BYOD-Policy klare Anforderungen an Betriebssystem-Integrität stellt – und ob diese mit Datenschutzanforderungen vereinbar sind.

Empfehlung: Unterscheiden Sie zwischen Geräteintegrität (technisch) und Gerätekonformität (regulatorisch). Nicht jedes Custom ROM ist ein Sicherheitsrisiko; einige sind nachweislich sicherer als OEM-Systeme.

3. 🏗️ Eigene Attestierungslösungen oder Open-Source-Alternativen evaluieren

Für unternehmenseigene Apps sollten Entwicklungsteams herstellerunabhängige Attestierungsmechanismen prüfen. Android bietet mit dem Android Keystore System und Hardware-Attestierung (über Trusted Execution Environments) Möglichkeiten, Gerätesicherheit ohne Google-Abhängigkeit zu prüfen.

Konkrete Alternativen:
- Android Protected Confirmation für kritische Transaktionen
- Remote Attestation via FIDO2/WebAuthn
- Eigene MDM-basierte Compliance-Checks statt externer APIs

4. 📝 Vertragliche Absicherung bei App-Anbietern

Wenn Sie als Unternehmen auf externe Apps angewiesen sind (z. B. Flottenmanagement, Telematiksoftware), sollten Verträge mit Anbietern SLA-Klauseln zur Verfügbarkeit und zur Benachrichtigung bei API-Änderungen enthalten. Der VW-Fall zeigt: Zugangssperren können ohne Vorwarnung eintreten.

Checkliste für Vertragsverhandlungen:
- [ ] Informationspflicht bei Änderung der Zugangsmechanismen
- [ ] Kompatibilitätszusagen für zertifizierte MDM-Konfigurationen
- [ ] Datenschutz-Folgenabschätzung (DSFA) für eingesetzte Attestierungs-APIs
- [ ] Eskalationspfad bei unangekündigten Sperren

5. 🚨 Incident-Response-Prozesse für App-Ausfälle definieren

Was passiert, wenn eine betriebskritische App morgen den Zugriff sperrt? Definieren Sie Notfallprozesse für den Fall unerwarteter App-Ausfälle durch externe Plattformentscheidungen. Unter NIS2 müssen erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden dem BSI gemeldet werden (Frühwarnung) – auch wenn die Ursache bei einem Drittanbieter liegt.

Maßnahmen:
- Alternativen für kritische App-Funktionen dokumentieren (Webzugang, alternative Apps)
- Verantwortlichkeiten im Incident-Response-Plan klar benennen
- Regelmäßige Tests der Notfallprozesse (Tabletop Exercises)

Fazit: Der VW-Fall als Weckruf für Unternehmens-IT

Die Entscheidung von Volkswagen, Custom-ROM-Nutzer über die Google Play Integrity API auszusperren, ist kein Einzelfall – sie ist ein Symptom einer wachsenden Plattformabhängigkeit, die viele Unternehmen bislang unterschätzen. Wer mobile Workflows auf Drittanbieter-Apps aufbaut, ohne die darunterliegenden Attestierungsmechanismen zu verstehen und zu kontrollieren, überlässt einem fremden Konzern die Entscheidung darüber, wer Zugang zu seinen Systemen erhält.

Für Unternehmen unter NIS2-Pflicht ist das keine theoretische Gefahr: Fehlende Kontrolle über mobile Endpunkte und Drittanbieter-Abhängigkeiten können in Audits und bei BSI-Meldungen zum echten Compliance-Problem werden. Die gute Nachricht: Mit klarer Inventarisierung, angepassten BYOD-Richtlinien und vertraglicher Absicherung lässt sich das Risiko deutlich reduzieren.

Call-to-Action: NIS2-Compliance strukturiert angehen

Die oben beschriebenen Maßnahmen sind nur ein Ausschnitt der Anforderungen, die NIS2 an deutsche Unternehmen stellt. Um den Überblick über Lieferkettensicherheit, Meldepflichten und technische Schutzmaßnahmen zu behalten, setzen viele IT-Teams inzwischen auf spezialisierte NIS2-Compliance-Software. Diese Lösungen helfen dabei, Risikoanalysen zu dokumentieren, Drittanbieter-Abhängigkeiten zu kartieren und Meldeprozesse gegenüber dem BSI revisionssicher abzubilden – ohne dass jede Änderung manuell in Tabellen gepflegt werden muss.

Wenn Sie aktuell prüfen, wie Ihre Organisation die NIS2-Anforderungen strukturiert erfüllen kann, lohnt sich ein Blick auf verfügbare GRC-Plattformen (Governance, Risk, Compliance) mit NIS2-Fokus. Viele Anbieter bieten kostenlose Erstbewertungen oder Demo-Zugänge an.