Mobile Device Management, kurz MDM, hilft einer Organisation, Smartphones und Tablets zentral einzurichten, ihren Sicherheitszustand zu prüfen und dienstliche Zugriffe zu beenden. Die DSGVO verlangt dabei ein dem Risiko angemessenes Schutzniveau. Sie schreibt nicht jedem Unternehmen unabhängig vom Einsatzszenario ein bestimmtes MDM-Produkt vor. Wer auf zentrale Verwaltung verzichtet, muss allerdings erklären können, wie die erforderlichen Schutzmaßnahmen auf seinen Geräten tatsächlich umgesetzt und überprüft werden.
Für die Orientierung sind zwei BSI-Quellen zu unterscheiden: der IT-Grundschutz-Baustein SYS.3.2.2 zum Mobile Device Management und der eigenständige Mindeststandard für MDM. Dieser Artikel erläutert den geprüften Mindeststandard Version 2.0 vom 5. September 2022 und seinen Anwendungskontext. Technische Empfehlungen für die betriebliche Umsetzung werden ausdrücklich von konkreten Anforderungen dieses Standards und gesetzlichen Pflichten getrennt.
Welche Verbindlichkeit haben die BSI-Vorgaben?
Die BSI-Seite zum MDM-Mindeststandard erläutert seine Ausrichtung auf Stellen des Bundes. Der dort angebotene Mindeststandard Version 2.0 verwendet noch die damalige Bezugnahme auf § 8 BSIG. Die aktuelle gesetzliche Einordnung muss zusätzlich anhand des heutigen Rechts geprüft werden; ein älteres Deckblatt ist keine verlässliche Quelle für die inzwischen geltende Paragrafennummer.
§ 44 BSIG regelt Vorgaben des Bundesamtes für Einrichtungen der Bundesverwaltung einschließlich der dort bezeichneten Ausnahmen. Daraus lässt sich keine identische Verpflichtung für sämtliche Kommunen oder privaten Arbeitgeber ableiten. Für diese können andere gesetzliche, vertragliche oder interne Bindungen bestehen. Ein Unternehmen kann den Standard außerdem als fachliche Orientierung verwenden, ohne damit automatisch dem gesamten Regelungsregime der Bundesverwaltung zu unterliegen.
Die IT-Grundschutz-Methodik ordnet Anforderungen nach ihrem jeweiligen Baustein und Schutzbedarf ein. Übernehmen Sie deshalb keine vermeintliche BSI-Liste mit frei erfundenen Patchfristen, Produktvorgaben oder Kontrollintervallen. Eine Anforderung sollte mit Dokumentversion, Kennung, Modalverb und Anwendungsbereich nachvollziehbar sein. Ein unternehmensintern festgelegtes Ziel kann sinnvoll sein, muss aber als eigenes Ziel bezeichnet werden.
Was der geprüfte Mindeststandard tatsächlich abdeckt
Der Mindeststandard Version 2.0 behandelt technische Funktionen, den Betrieb des MDM-Systems und Prozesse zur Verwaltung mobiler Endgeräte. Er unterscheidet Anforderungen an das System, die betreibende Einrichtung und weitere beteiligte Stellen. Eine Funktion im Herstellerprospekt genügt daher nicht, wenn die Organisation sie weder konfiguriert noch betreibt.
Beispielsweise verlangt MDM.2.1.02 die Festlegung erlaubter Geräte und Betriebssysteme sowie die Berücksichtigung von Sicherheitsaktualisierungen über die vorgesehene Nutzungsdauer. MDM.2.6.14 betrifft die automatische Bildschirmsperre und ihre angemessen kurze Einstellung entsprechend dem Schutzniveau. Diese Aussagen tragen eine Beschaffungs- und Konfigurationsentscheidung, aber keine frei gewählte allgemeine Frist von 30 Tagen für jeden Patch.
Der Standard erklärt ausdrücklich, dass er keine spezifischen Anforderungen für BYOD behandelt. Zugleich berücksichtigt er technische Beschränkungen verschiedener Betriebsmodelle: MDM.2.2.01 fordert eine Behandlung der dadurch entstehenden Risiken. Ein BYOD-Konzept muss deshalb zusätzlich entwickelt werden. Die bloße Übereinstimmung mit einzelnen MDM-Funktionen beweist weder die arbeitsrechtliche Zulässigkeit noch den ausreichenden Schutz privater Inhalte.
Gerätebesitz und Verwaltungsumfang getrennt entscheiden
Bei ausschließlich dienstlichen Firmengeräten kann die Organisation ein anderes Verwaltungskonzept wählen als bei Privatgeräten. Erlaubte Privatnutzung eines Firmengeräts verändert wiederum die Datenschutzabwägung. Die Kürzel COBO, COPE und BYOD beschreiben typische Modelle, ersetzen aber keine Festlegung des tatsächlichen Umfangs. Auch die Auswahl eines Geräts durch Beschäftigte sagt noch nichts darüber aus, ob private Nutzung zulässig ist.
Schreiben Sie vor der Produktauswahl auf, welche Daten die Administration sehen darf und welche Befehle sie ausführen können muss. Die Kenntnis des Betriebssystemstands kann für Sicherheit nötig sein; die Liste privater Anwendungen oder eine dauerhafte Standortverfolgung verlangt eine andere Begründung. Technische Zugriffsmöglichkeiten und zulässige Verarbeitung sind zwei verschiedene Ebenen. Ein mächtiges Administratorprofil erweitert die rechtlichen Befugnisse nicht.
Bei BYOD sollte die Organisation zuerst prüfen, ob die beabsichtigte Arbeit ohne Zugriff auf den privaten Bereich zuverlässig möglich ist. Dazu gehören Datenablage, Zwischenablage, Backups, geteilte Anwendungen und der Austritt aus dem Unternehmen. Die BYOD-Richtlinie für Deutschland vertieft diese organisatorische Entscheidung. Wenn das vorgesehene Modell sensible Daten nicht ausreichend schützt, kann ein verwaltetes Dienstgerät die angemessenere Lösung sein.
Vom Datenfluss zur Konfiguration
Beginnen Sie mit den konkreten Arbeitsabläufen. Ein Gerät, das lediglich Termine anzeigt, benötigt möglicherweise andere Funktionen als ein Tablet mit offline gespeicherten Gesundheitsunterlagen. Erfassen Sie Datenkategorien, lokale Speicherung, Schnittstellen und Empfänger. Prüfen Sie auch, ob Benachrichtigungen Inhalte auf dem Sperrbildschirm offenlegen oder eine private Sicherung dienstliche Anhänge übernimmt. Solche Details werden bei einer reinen Inventarliste leicht übersehen.
Aus diesen Szenarien folgen Einstellungen für Authentisierung, Verschlüsselung, Freigaben und Datenübertragung. Artikel 32 DSGVO verlangt eine risikogerechte Auswahl unter Berücksichtigung der gesetzlichen Kriterien. Er begründet keine allgemeine Pflicht, jeden Zugriff durch ein VPN zu führen. Ein sicher konfigurierter Zugriff auf einen Cloud-Dienst kann anders abgesichert sein als der Zugang zu einem internen Verwaltungsnetz.
Dokumentieren Sie dabei, welche Schutzwirkung Sie erwarten. Eine Bildschirmsperre begrenzt Gelegenheitszugriffe, schützt aber keinen bereits kompromittierten Benutzeraccount. Das Konzept zur Verschlüsselung personenbezogener Daten hilft beim Schutz eines verlorenen gesperrten Geräts. Verschlüsselung beseitigt jedoch keine unzulässige Synchronisierung zu einem Dritten. Das Verständnis dieser Grenzen verhindert, dass ein grüner Status in der Verwaltungskonsole als vollständiger Nachweis der Datensicherheit missverstanden wird.
Enrollment sicher organisieren
Beim Enrollment wird das Gerät dem Verwaltungssystem und einer berechtigten Person oder Funktion zugeordnet. Prüfen Sie, wie diese Zuordnung entsteht: Wer darf ein neues Gerät aufnehmen, wie wird seine Herkunft kontrolliert und welches Profil erhält es? Ein frei weiterleitbarer Einladungslink oder ein gemeinsam verwendetes Administratorkonto kann die vorgesehenen Kontrollen unterlaufen, bevor die eigentliche Richtlinie überhaupt greift.
Eine sinnvolle betriebliche Freigabe verlangt, dass notwendige Einstellungen wirksam sind, bevor produktive Daten verfügbar werden. Kontrollieren Sie an einem Pilotgerät, ob fehlgeschlagene Konfigurationen sichtbar werden. Das System sollte nicht allein melden, dass ein Profil versendet wurde, wenn dessen Anwendung auf dem Gerät offen ist. Für eingeschränkte oder ältere Plattformen braucht die Organisation einen ausdrücklich bewerteten Umgang mit fehlenden Funktionen.
Erklären Sie Beschäftigten vor der Aufnahme verständlich, welche Daten die Administration erhält und welche Eingriffe möglich sind. Eine Anzeige auf dem Gerät kann hierzu beitragen, ersetzt aber nicht die passenden Datenschutzinformationen. Erfassen Sie die Information und die organisatorische Freigabe, ohne eine Kenntnisnahme automatisch als Einwilligung in sämtliche denkbaren Kontrollen zu behandeln. Die tatsächliche Rechtsgrundlage ist gesondert zu bestimmen.
Die MDM-Zentrale besonders schützen
Ein kompromittiertes MDM-Konto kann zahlreiche Geräte gleichzeitig beeinflussen. Die Verwaltungsumgebung verdient daher eine eigene Risikoanalyse. Trennen Sie normale Benutzerkonten von administrativen Rollen, begrenzen Sie Berechtigungen und sichern Sie die Anmeldung angemessen ab. Ein Helpdesk, der Gerätezuordnungen prüfen muss, benötigt nicht zwangsläufig die Möglichkeit, den gesamten Gerätebestand zu löschen oder globale Sicherheitsregeln zu verändern.
Der Mindeststandard behandelt unter anderem Berechtigungsmanagement und die Absicherung der Betriebsumgebung. Für Ihre praktische Umsetzung sollten Sie nachvollziehen können, wer kritische Änderungen vorgenommen hat und wie Fehlkonfigurationen zurückgenommen werden. Dazu gehört eine geschützte Dokumentation der verwendeten Profile. Ein Export mit vertraulichen Schlüsseln darf nicht aus Bequemlichkeit in einer allgemein zugänglichen Projektablage landen.
Berücksichtigen Sie Ausfälle und Notzugänge. Wenn die einzige zuständige Person nicht erreichbar ist, müssen Sicherheitsvorfälle dennoch bearbeitet werden können. Ein Notzugang braucht klar begrenzte Berechtigungen, geschützte Aufbewahrung und nachträgliche Überprüfung seiner Verwendung. Eine Umgehung sämtlicher Kontrollen über ein dauerhaft geteiltes Passwort würde die mühsam eingerichtete Rollentrennung wieder aufheben.
Protokollierung ohne verdeckte Verhaltenskontrolle
Gerätekennung, Sicherheitsstatus, Nutzerzuordnung und Ereignisprotokolle können personenbezogene Daten sein. Das MDM schützt deshalb nicht nur andere Daten, sondern erzeugt einen eigenen Verarbeitungsvorgang. Beschreiben Sie diesen im Verzeichnis der Verarbeitungstätigkeiten, soweit die gesetzliche Pflicht besteht. Legen Sie Zwecke, zugriffsberechtigte Rollen, Empfänger und Löschregeln für die tatsächlich erhobenen Informationen fest.
Die Kontrollen MDM.2.3.01 und MDM.2.3.02 betreffen Gerätestatus und sicherheitsrelevante Aktionen am Verwaltungssystem. Der Standard weist darauf hin, dass Datenschutzvorgaben zusätzlich zu beachten sind. Aus einer technischen Protokollierungsfunktion folgt keine Berechtigung zur dauerhaften Leistungsmessung. Ein Sicherheitsbericht sollte daher nicht ohne neue Prüfung in eine Rangliste zur Arbeitsintensität einzelner Beschäftigter umgewandelt werden.
Für die praktische Ausgestaltung hilft ein Konzept für Sicherheitsprotokollierung. Bestimmen Sie, welche Ereignisse eine Untersuchung auslösen, wer sie auswertet und wie unnötige Identitätsbezüge vermieden werden. Der normale Betrieb braucht häufig nur eine Übersicht über nicht konforme Geräte. Eine personenbezogene Detailanalyse kann auf den konkreten Störungs- oder Sicherheitsfall beschränkt werden, sofern dies den tatsächlichen Anforderungen genügt.
Beschäftigtendatenschutz und Mitbestimmung
Die Verarbeitung von Beschäftigtendaten benötigt eine tragfähige Rechtsgrundlage und muss erforderlich sowie verhältnismäßig sein. § 26 BDSG ist dabei zusammen mit den unionsrechtlichen Anforderungen und der konkreten Situation zu prüfen. Artikel 88 DSGVO ist keine pauschale Erlaubnis für MDM. Eine unterschriebene Gerätevereinbarung heilt auch keine unnötige Erhebung privater Kommunikationsinhalte.
Besteht ein Betriebsrat, kann insbesondere § 87 Absatz 1 Nummer 6 BetrVG einschlägig sein. Eine Aussage, jeder Arbeitgeber müsse für jedes MDM eine Betriebsvereinbarung abschließen, wäre schon wegen der unterschiedlichen betrieblichen Strukturen zu weit. Prüfen Sie die Mitbestimmung vor der Einführung und vor wesentlichen Funktionserweiterungen. Bei öffentlichen Arbeitgebern sind die jeweils einschlägigen Regeln der Personalvertretung zu berücksichtigen.
Auch eine Datenschutz-Folgenabschätzung ist nicht allein wegen des Etiketts MDM oder BYOD ausnahmslos erforderlich. Entscheidend ist, ob die geplante Verarbeitung voraussichtlich ein hohes Risiko mit sich bringt, einschließlich einschlägiger aufsichtsbehördlicher Listen. Umfangreiche Standort- oder Verhaltensauswertungen können die Bewertung deutlich verändern. Dokumentieren Sie die Vorprüfung und beziehen Sie den Datenschutzbeauftragten ein, soweit ein solcher benannt ist.
Updates, Ausnahmen und nicht erreichbare Geräte
Legen Sie fest, wie Geräte ohne Sicherheitsupdates erkannt und behandelt werden. Die passende Reaktion hängt von Schwachstelle, Datenzugriff und technischen Möglichkeiten ab. Eine interne Frist darf nach Dringlichkeit unterscheiden; sie ist keine universelle BSI-Frist. Bei einer bereits ausgenutzten Schwachstelle kann eine schnelle Zugangsbeschränkung erforderlich sein, auch wenn ein gewöhnlicher Wartungszyklus noch nicht abgelaufen ist.
Ein Gerät, das seit längerer Zeit keinen Kontakt mehr hatte, ist kein nachweislich konformes Gerät. Prüfen Sie, ob sein Zugriff vorsorglich eingeschränkt werden muss und wie die zuständige Person informiert wird. Gleichzeitig sollten kurzzeitige Verbindungsprobleme nicht unkontrolliert zu Datenverlust führen. Die Regeln müssen den betrieblichen Ablauf berücksichtigen und sichere Hilfestellung ermöglichen, statt Beschäftigte zu privaten Ausweichlösungen zu drängen.
Ausnahmen brauchen eine konkrete Begründung, einen Verantwortlichen und einen überprüfbaren Endpunkt. Ein Spezialgerät ohne aktuelle Verwaltungsfunktion kann etwa nur noch auf einen begrenzten Dienst zugreifen. Ob dies ausreichend ist, ergibt sich aus seiner Risikobewertung. Ein offener Ausnahmeeintrag ohne Ersatzmaßnahme sollte nicht dauerhaft als grüner Compliance-Status erscheinen. Die regelmäßige Überprüfung muss die tatsächlichen Bedingungen erneut betrachten.
Verlust, Remote-Lock und Remote-Wipe
Beim Verlust eines Geräts sollten Sperrung von Accounts oder Zertifikaten, Fernsperre und Fernlöschung getrennt betrachtet werden. Ein versendeter Löschbefehl beweist nicht, dass das Gerät ihn empfangen und ausgeführt hat. Ein offline befindliches Smartphone kann zunächst unerreichbar bleiben. Deshalb sind Verschlüsselung und begrenzte lokale Datenhaltung wichtige Schutzmaßnahmen, die bereits vor dem Verlust wirksam sein müssen.
Bei privater Nutzung und insbesondere BYOD sind Umfang und Folgen einer Fernlöschung sorgfältig festzulegen. Die Löschung eines dienstlichen Profils kann private Inhalte schonen, muss aber die tatsächlich vorhandenen dienstlichen Kopien erfassen. Ein vollständiges Zurücksetzen darf nicht als automatische Standardreaktion ohne Prüfung von Befugnissen, Erforderlichkeit und Auswirkungen vorgesehen werden. Testen Sie die gewählte Funktion vorab mit unkritischen Beispieldaten.
Der Verlust kann eine Verletzung des Schutzes personenbezogener Daten sein. Der Verantwortliche meldet nach Artikel 33 unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für Rechte und Freiheiten. Verzögerungen sind zu begründen, jede Datenschutzverletzung ist zu dokumentieren und Artikel 34 ist gesondert zu prüfen. Ein erfolgreich gesperrtes Gerät beantwortet diese rechtlichen Fragen nicht automatisch.
Dienstleister und Vertragsende einplanen
Bei einem gehosteten MDM sind die Rollen und gegebenenfalls die Regelung nach Artikel 28 zu prüfen. Ermitteln Sie die konkrete betreibende Gesellschaft, Supportzugriffe und Unterauftragnehmer. Datenschutz und Sicherheit betreffen auch die MDM-Metadaten selbst. Ein Anbieter kann Zugriff auf Gerätekennungen, Benutzerzuordnungen und Protokolle haben, obwohl er die auf den Endgeräten gespeicherten Fachunterlagen nicht lesen kann.
Planen Sie den Wechsel zu einem anderen System vor dem Vertragsabschluss. Welche Profile, Zertifikate und Anwendungen müssen entfernt werden? Wie werden Geräte neu aufgenommen, ohne den Zugangsschutz zwischenzeitlich aufzuheben? Prüfen Sie Exportmöglichkeiten für notwendige Konfigurations- und Nachweisdaten sowie die Löschung beim bisherigen Anbieter. Eine erfolgreiche Kündigung der Lizenz beendet nicht zwangsläufig alle technischen Abhängigkeiten.
Beim Ausscheiden einer Person sollten dienstliche Zugänge, Tokens und Zertifikate widerrufen sowie erforderliche Daten geordnet übergeben werden. Anschließend wird das Gerät nach dem festgelegten Verfahren bereinigt oder freigegeben. Die Personalabteilung meldet die Veränderung, die IT führt die Schritte aus und eine zuständige Rolle bestätigt den Abschluss. Eine einzelne Fernlöschung ersetzt diesen gesamten Lebenszyklus nicht.
Ein Pilot, der die entscheidenden Fragen beantwortet
Ein aussagekräftiger Pilot umfasst mindestens die unterschiedlichen freigegebenen Nutzungsmodelle. Lassen Sie beispielsweise ein hypothetisches Außendienstgerät offline arbeiten und prüfen Sie anschließend, welche Daten verblieben sind. Simulieren Sie eine abgelehnte Richtlinie, einen Accountwechsel und die Rückgabe. Beobachten Sie sowohl die Anzeige in der Konsole als auch das tatsächliche Geräteverhalten. So werden technische Grenzen vor dem Rollout sichtbar.
Bewerten Sie Anbieter anhand Ihrer Anforderungen statt anhand unbelegter Marktführerschaft oder pauschaler Preise. Benötigte Plattformen, Supportdauer, Administrationsaufwand, Datentrennung und nachvollziehbare Protokolle sind konkrete Kriterien. Für Einrichtungen mit zusätzlichen Pflichten ist außerdem die deutsche NIS2-Einordnung gesondert zu prüfen. Ein MDM-System oder eine Zertifizierung allein erfüllt nicht sämtliche Anforderungen anderer Regelungsbereiche.
Nach dem Pilot sollten die offenen Punkte in eine freigegebene Betriebsentscheidung münden: unterstützte Geräte, notwendige Einstellungen, zulässige Ausnahmen und klare Verantwortlichkeiten. Überprüfen Sie diese Entscheidung bei relevanten Änderungen von Plattform, Betriebsmodell oder Datenverarbeitung erneut. Dadurch bleibt die BSI-Orientierung mit dem realen Betrieb verbunden und reduziert sich nicht auf eine abgelegte Beschaffungsliste.
Bearbeitungsstand: 29. September 2026. Die BSI-Erläuterungen beziehen sich auf die oben bezeichnete Version 2.0; die gesetzliche Anwendbarkeit wird davon getrennt anhand des aktuellen § 44 BSIG beschrieben. Umsetzungsvorschläge in diesem Beitrag sind keine zusätzlichen, vom BSI erfundenen Pflichtanforderungen.