Sophos Mobile: Android-Geräteadministrator zu Android Enterprise migrieren

Dieser Artikel hilft, den Migrationsweg und die nötigen Prüfungen festzulegen. Er erteilt keine Freigabe für einen produktiven Reset. Sophos bezeichnet Geräteadministrator als veralteten Verwaltungsmodus: In Sophos Mobile ist er nur für Android 9 oder älter verfügbar; Android 10 und neuer können in diesem Modus nicht registriert werden. Dies ist keine Aussage, dass jede Android-Device-Policy-Manager-Funktion generell abgeschafft wäre, und keine Empfehlung, Android 9 weiter zu betreiben. Neue Geräte nicht im alten Modus einschreiben. Die nachfolgend beschriebenen Migrationszweige setzen eine bereits eingerichtete und konfigurierte Android-Enterprise-Umgebung voraus.

Zuerst Eigentum und Zielmodus festlegen

Vor jeder Änderung den tatsächlichen Verwaltungsmodus, Geräteidentität, Eigentum, Android-Version, Benutzerzuordnung, Richtlinien, Anwendungen, Erreichbarkeit und letzten Gerätestatus am Gerät und im richtigen Sophos-Mandanten abgleichen.

Neueinschreibung vor dem Eingriff vorbereiten

Diese Prüfung erfolgt, solange das alte Gerät noch verwaltet wird. Sie löst weder Reset noch Deregistrierung aus. Im Migrationsprotokoll die folgenden Angaben für den gewählten Zielmodus festhalten:

Unter Sophos Fusion > My Products > Mobile > Setup > Google setup > Android Enterprise den vorhandenen Android Enterprise mode, die angezeigten Kontodetails und den Zustand von Use managed Google domain device enrollment prüfen. Eine bestehende Organisationsregistrierung weiterverwenden, nicht erneut Register account ausführen oder die Google-Bindung ersetzen. Fehlende oder unklare Bindung zuerst nach dem Abschnitt Organisation bei Google anbinden klären.
Für das Firmengerät eine Android Enterprise device policy, für das Privatgerät eine Android Enterprise work profile policy bereithalten. Namen der Zielrichtlinie und des zugehörigen Aufgabenpakets notieren. Das Paket für den jeweiligen Gerätetyp muss mindestens Enroll und Assign policy mit genau dieser Richtlinie enthalten. Eine alte Geräteadministrator-Richtlinie ist kein Ersatz.
Bei Nutzung des Self Service Portals unter Setup > Self Service Portal die für den Benutzer wirksame Konfiguration öffnen. In den Android-Plattformeinstellungen muss Enrollment package auf das vorbereitete Aufgabenpaket zeigen. Owner, Ziel-Device group, Gruppenpriorität und verbleibendes Gerätekontingent abgleichen. Eine vorhandene passende Konfiguration prüfen, nicht pauschal eine neue erstellen oder Default ändern. Die Vorbereitung beschreibt Richtlinie, Paket und Benutzeridentität vorbereiten.
Die Freigabe von Sophos Mobile Control in Managed Google Play prüfen. Ohne diese Freigabe aktualisiert sich die verwaltete App nicht automatisch. Bei aktivierter Domain-Geräteanmeldung müssen die vorgesehenen Benutzer in der verwalteten Google-Domain vorhanden sein. Für diese Domain-Geräteanmeldung ist Mobile Control 9.8 oder neuer erforderlich; bei Arbeitsprofilen müssen zusätzlich alle verfügbaren Betriebssystem- und App-Updates installiert sein. Bei einem von Sophos Mobile gestarteten Auftrag muss die zugewiesene E-Mail exakt dem Google-Login entsprechen.
Einen im vorhandenen Organisationsmodus zulässigen Einschreibungsweg auswählen und die folgende Benutzerübergabe vorab mit der zuständigen IT vorbereiten. Bei einer vor dem 9. April 2024 im managed-Google-domain-Modus registrierten Organisation ohne aktivierte Domain-Geräteanmeldung ist Administrator-Enrollment nicht verfügbar; dann den zulässigen SSP-Weg vorbereiten. Den Schalter nicht beiläufig als Migrationsschritt einschalten. Änderungen an Organisationsbindung oder Anmeldemodus benötigen eine eigene Freigabe.

Für ein Firmengerät mit zugewiesenem Benutzer beschreibt der Android-Enterprise-Leitfaden unter “Administrator-Pilot” den unterstützten Assistentenweg über Devices > Add > Add device wizard, Benutzerauswahl, Platform: Android und das vorbereitete Enrollment-Paket. Diesen Weg erst nach dem separat freigegebenen und am Gerät bestätigten Werksreset ausführen. Bei erforderlichem SSP den dort beschriebenen SSP-Ablauf verwenden. QR-, Zero-touch- und nutzerlose Verfahren sind Alternativen mit eigener Vorbereitung, keine zusätzlichen Pflichtschritte.

Für ein nachweislich persönliches Gerät vorab den Abschnitt Arbeitsprofil einrichten im Android-BYOD-Leitfaden für die Benutzerübergabe bereitstellen. Er führt durch Owner: Personal, das Work-Profile-Paket und die Einrichtung von Mobile Control am Gerät. Diese neue Einschreibung beginnt erst nach bestätigter alter Deregistrierung und anschliessendem Löschen des richtigen Alt-Eintrags. Die Datenschutz- und Einwilligungsprüfung unter “Vor dem Einschreiben” gehört ebenfalls dazu; der BYOD-Ablauf gilt nicht für Firmengeräte mit Arbeitsprofil.

Fehlt eine dieser Voraussetzungen, vor beiden Migrationszweigen stoppen. Vor einem produktiven Eingriff den ausgewählten Weg an einem autorisierten repräsentativen Testgerät prüfen. Vorbereitete Konten, ein gespeichertes Paket oder sichtbare Portaloptionen belegen noch keine erfolgreiche Geräteanmeldung. Nach der Einschreibung Verwaltungsmodus, Benutzerzuordnung, Aufgabenstatus und wirksame Richtlinie in Sophos Mobile und am Gerät kontrollieren.

Dokumentierte Migrationszweige

Die zwei dokumentierten Wege nicht vermischen:

Firmeneigen, bisher Geräteadministrator → Android Enterprise: Vollständige Geräteverwaltung. Auf Gerät anzeigen > Aktionen > Zurücksetzen wird das Gerät auf Werkseinstellungen zurückgesetzt; danach neu registrieren. Sophos nennt Assistent „Gerät hinzufügen“, Sophos Fusion Self Service Portal, QR-Code- und Zero-Touch-Registrierung als mögliche Wege. Diesen Eingriff nur nach gesonderter Freigabe ausführen.
Privat, bisher Geräteadministrator → Android Enterprise: Arbeitsprofilverwaltung. Auf Gerät anzeigen > Aktionen > Deregistrieren, danach Aktionen > Löschen; erst danach Arbeitsprofil neu registrieren. Sophos nennt den Assistenten „Gerät hinzufügen“ oder das Sophos Fusion Self Service Portal. Auch dieser Eingriff benötigt eine gesonderte Freigabe. Kein Werksreset als BYOD-Standardschritt.

Diese Bezeichnungen stammen aus der deutschsprachigen Sophos-Hilfe vom 22. September 2026; in einer englisch eingestellten Konsole stehen Show device > Actions > Wipe, Unenroll und Delete. Die konkreten Menüs, Berechtigungen und verfügbaren Registrierungswege im Ziel-Mandanten vorab prüfen. Ein Sophos-Fusion-Wipe, ein Mobile-Admin-Zurücksetzen und das Entfernen eines bereits eingerichteten Arbeitsprofils sind nicht austauschbare Bezeichnungen oder Migrationsschritte. Bestehende firmeneigene Geräte mit Arbeitsprofil und andere Modi brauchen eine getrennte Entscheidung, nicht diese Zweiteilung als automatische Zuordnung.

Stopp vor jeder destruktiven Aktion

Firmengerät: Schriftliche Freigabe für genau dieses Gerät und den Werksreset einholen; lokale Daten, Geschäftskonten, Apps, Authentisierung, nutzbares Backup und Wiederherstellung prüfen. Ein geplanter Reset vernichtet nicht gesicherte lokale Daten. Ein tatsächlich funktionierender Android-Enterprise-Neueinschreibungsweg, WLAN/Mobilfunkzugang, nötige Zugangsdaten und Berechtigungen müssen bereitstehen. Google-Konten und Reset-Sperren vorab geräte- und resetwegspezifisch prüfen. Sophos dokumentiert die Factory Reset Protection für vollständig verwaltete Android-Enterprise-Geräte; daraus folgt nicht, dass dieselbe FRP-Konfiguration bereits den alten Geräteadministrator-Reset steuerte. Keine FRP-Umgehung versprechen.
Privatgerät: Einwilligung und Abgleich persönlicher/geschäftlicher Daten sowie Wirkung der alten Deregistrierung mit dem Benutzer klären. Bei der alten Deregistrierung wird dabei der Sophos-Mobile-Control-Geräteadministrator deaktiviert, werden Server-Zugangsdaten und erhaltene Daten entfernt und wird Sophos Intercept X for Mobile zurückgesetzt. Erst die bestätigte Deregistrierung, dann das Löschen des zugehörigen Eintrags; ein ausstehender Auftrag und ein verschwundener Konsoleneintrag belegen keinen vollzogenen Rückbau am Gerät. Auf einem später eingerichteten Arbeitsprofil führt dessen Entfernung zum Verlust seiner Apps und lokalen Daten, nicht zu einem wiederherstellbaren alten Profil. Persönliche Daten nicht ohne Gerätekontrolle als erhalten zusichern.
Offline, unbekannter Zustand oder gesperrtes Gerät: Nicht als erledigt verbuchen und keine zweite Lösch- oder Resetaktion auf Verdacht auslösen. Mit Benutzer und Sophos-/Gerätesupport tatsächlichen Gerätezustand, Auftragszustellung und autorisierten Wiederherstellungsweg klären. Ein Cloud-Auftrag ist kein Beweis für seine Ausführung.

Vor dem Eingriff bei vorhandenen Restrictions tatsächlichen Geräte- und SD-Verschlüsselungszustand sowie einen erlaubten, nachweislich nutzbaren Sicherungs- und Wiederherstellungsweg erfassen. Eine angeforderte SD-Verschlüsselung kann auf manchen Altgeräten abgebrochen worden sein; die Zuweisung belegt keinen Zustand. Ein deaktiviertes Allow backup schaltet laut Altquelle Google-Backup aus, nicht sämtliche alternativen Sicherungen. USB-/MTP-Sperren können den benötigten Dateiübertragungsweg verhindern. Keine Sperren auf Verdacht lockern. Allow factory reset betrifft den Benutzer-Reset; daraus weder Freigabe noch Durchführbarkeit des separat autorisierten Konsolen-Wipe ableiten.

Alte Richtlinie nur als Inventar, nicht als Vorlage für Android Enterprise

Die Android-Geräterichtlinie richtet sich an den alten Geräteadministrator-Modus. Für Android Enterprise full device und Android Enterprise work profile gelten jeweils eigene Richtlinienfamilien. Vor Freigabe eine dokumentierte Quell-/Zielmatrix für alle 14 alten Unterkonfigurationen erstellen; pro Zeile Zielmodus, unterstützte neue Einstellung oder ausdrücklich fehlenden Ersatz, OS/OEM/Lizenz, Test, Auswirkungen und Rückweg festhalten:

Die folgenden Prüfbereiche gehören in diese Matrix. Erfasst werden bestehende Werte, nicht neu anzulegende Geräteadministrator-Konfigurationen. Ein fehlender Ersatz bleibt als offene Entscheidung sichtbar; ähnlich benannte Zieloptionen belegen keine gleiche Wirkung.

Verbindungen und Zertifikate

Für jede bestehende APN-Konfiguration zusätzlich folgende Felder aufnehmen:

User-friendly name als am Gerät angezeigten Zusatznamen; die beiden Server-Angaben getrennt als HTTP-Server für Webverkehr und als WAP-Gateway, dazu Port des Webservers.
User name und die Abhängigkeit von User password nur mit zugriffsgeschütztem Identitäts- bzw. sicherem Geheimnisverweis; MMSC (Multimedia Messaging Service Center), MMS proxy server und MMS proxy port getrennt für den MMS-Weg.
Authentication type als PPP-Authentisierung, APN type als verwendete Datenverbindungsarten, Bearer als Funkzugangstechnologie sowie Protocol und Roaming protocol als Betreiberprotokolle im Heimnetz bzw. Roaming.

Ausser APN sind die Altfelder optional; unbenutzte Felder ausdrücklich als nicht konfiguriert markieren, nicht mit geratenen Werten auffüllen. Bei APN type bedeutet * oder ein leeres Feld alle Datenarten. Nur eine APN-Konfiguration darf Use as default APN verwenden. Diese Bedeutungen erklären den Altzustand, nicht die Einrichtung eines neuen Alt-APN. Jeden verwendeten Wert einem separat unterstützten Zielersatz oder ausdrücklich fehlenden Ersatz zuordnen und die Betreiberakzeptanz für das Ziel mit SIM/Abonnement gesondert bestätigen. Der unabhängige Wiederherstellungszugang bleibt erforderlich.

Bei APN den bisherigen Zugangspunkt, Netzbetreiber und die verwendete SIM bzw. das Abonnement festhalten. Mit dem Netzbetreiber klären, ob er diesen APN für das vorgesehene Abonnement akzeptiert. Vorhandene Mobile Country Code (MCC) und Mobile Network Code (MNC) ebenfalls erfassen und abgleichen: Diese Werte beschränken die Nutzung des alten APN auf den angegebenen Betreiber. Ein falscher Use as default APN kann mobile Daten abschneiden. Deshalb Netzbetreiberwerte und eine unabhängige Verbindung vor dem Eingriff sichern, nicht probeweise den Standard-APN ändern.

Für Wi-Fi und VPN alte WLAN-/EAP-Zertifikate, SSID und VPN-Typen erfassen und den Zielzugang gesondert prüfen; WEP ist kein sicherer Zielstandard. Den Management-Check-in auch über einen unabhängigen Zugang testen.

Für jede bestehende Wi-Fi-Konfiguration folgende Altwerte in die Matrix aufnehmen:

SSID und den tatsächlichen Security type: None, WEP, WPA/WPA2 PSK, EAP/PEAP, EAP/TLS oder EAP/TTLS. None und WEP sind keine Zielempfehlungen. Die Altbeschreibung schliesst bei WEP die Richtlinienzuweisung an Android 12 und neuer aus; diese historische Bedingung eröffnet keinen Registrierungsweg im alten Verwaltungsmodus.
Phase 2 authorization nur bei EAP/PEAP und EAP/TTLS: vorhandene Auswahl None, PAP, CHAP, MSCHAP oder MSCHAPv2 festhalten. Für EAP/TLS keinen solchen Altwert ergänzen.
Bei EAP Identity und Anonymous identity getrennt zuordnen. Letztere ist das Pseudonym, das in Phase 1 der EAP-Aushandlung unverschlüsselt gesendet wird. Für Password die bestehende WLAN-Kennwortabhängigkeit und den sicheren Verwahrungs- bzw. Ersatzbereitstellungsweg dokumentieren, nicht das Kennwort selbst.
Proxy host als Namen oder IP-Adresse des Proxys dieser WLAN-Verbindung und Proxy port separat erfassen. Ein Global HTTP proxy ist kein nachgewiesener gleichwertiger Ersatz für diesen verbindungsbezogenen Proxy.

Für jede bestehende VPN-Konfiguration Connection name (am Gerät sichtbarer Name), Server (Hostname oder IP-Adresse des Gateways) und den tatsächlichen Connection type erfassen. Die Altbeschreibung unterscheidet diese Abhängigkeiten:

L2TP/IPsec (PSK): Benutzerbezug unter User und Kennwortabhängigkeit unter Password getrennt vom vorab vereinbarten Authentisierungsschlüssel im Feld L2TP/IPsec (PSK) dokumentieren.
L2TP/IPsec (certificate): ausgewähltes Client certificate und Root certificate sowie zusätzlich User und die Password-Abhängigkeit aufnehmen. Die Zertifikatsauswahl ersetzt in diesem Altzweig nicht die Benutzer-/Kennwortabhängigkeit.
Cisco AnyConnect: vorhandenes VPN-Profil-XML und NVM-Profil-XML (Network Visibility Module) getrennt inventarisieren, jeweils mit Verantwortlichem, Version und sicherem Ablageverweis; ein nicht vorhandenes Profil als fehlend kennzeichnen. Daraus weder automatischen XML-Import noch gleiche Netzwerk-Sichtbarkeit im Ziel ableiten.

Identitätsbindungen nur im zugriffsgeschützten Migrationsprotokoll festhalten. Für Kennwörter, PSKs und private Schlüssel ausschliesslich sichere Verwahrungs-/Bereitstellungsverweise aufnehmen; weder Geheimnisse noch sensible reale Identitäten in öffentliche Nachweise übernehmen. Jeden verwendeten WLAN-Altwert und jede VPN-Abhängigkeit einem separat geprüften Zielersatz zuordnen oder dessen Fehlen ausdrücklich dokumentieren. Bei VPN dafür App-, OS-, Gateway- und Authentisierungsunterstützung prüfen, nicht aus dem alten Verbindungstyp ableiten. Zielfeldbedeutungen, Zertifikatsrollen und VPN-App-Konfiguration im verlinkten Artikel Android-Verbindungen prüfen; die folgenden Zertifikatsprüfungen bleiben zusätzlich erforderlich.

Client certificate, Root certificate und SCEP getrennt erfassen. Alte Clientzertifikate und Vertrauensanker sind richtliniengebunden; SCEP benötigt die CA des SCEP-Servers als Root-Konfiguration. Ziel-Identität, Ausstellung/Erneuerung, CA-Vertrauen und Anmeldung für WLAN/VPN neu nachweisen; niemals Zertifikatsprüfung zur Fehlerbehebung ausschalten.

Bei der alten Android-Geräterichtlinie wurde das in Root certificate hinterlegte Stammzertifikat mit der Richtlinienzuweisung auf dem Gerät installiert. Für den Altbestand die hinterlegte X.509-Zertifikatdatei samt PEM- oder DER-Kodierung dokumentieren. Jedes zusätzliche Stammzertifikat benötigte eine eigene Root certificate-Konfiguration; deshalb alle vorhandenen Root-Konfigurationen einzeln in die Quell-/Zielmatrix aufnehmen. Die alte Zuweisung allein belegt weder den tatsächlichen Zertifikatszustand des konkreten Geräts noch eine automatische Übernahme in Android Enterprise.

Für jede vorhandene Root certificate-Konfiguration zusätzlich die Altrichtlinie und die anderen Konfigurationen derselben Richtlinie erfassen, die dieses Stammzertifikat tatsächlich verwenden, einschliesslich WLAN-/EAP-Serververtrauen, falls vorhanden. Serververtrauen von Clientidentität und der CA des SCEP-Servers trennen. Jede Abhängigkeit der gewählten Zielrichtlinie und dem Zielmodus zuordnen oder einen fehlenden unterstützten Ersatz dokumentieren. Im autorisierten Zielpilot erwartete Serveridentität, CA-Vertrauen und Verbindung/Authentisierung nachweisen; keine automatische Übernahme annehmen.

Nur zur Auslegung der alten SCEP-Felder: URL konnte mit %_SCEPPROXYURL_% an die Server-URL auf dem Tab SCEP der Seite Sophos setup gebunden sein; Challenge konnte mit %_CACHALLENGE_% auf die dort konfigurierte Challenge-URL verweisen. Subject muss nach Ersetzung der Platzhalter durch die tatsächlichen Daten ein gültiger X.500-Name sein. Die alten SAN-Auswahlen bedeuten: RFC 822 name = gültige E-Mail-Adresse; DNS name = DNS-Name des CA-Servers; Uniform resource identifier = vollständig qualifizierte URL des CA-Servers. Konfigurierte und nicht konfigurierte Felder sowie die tatsächlich aufgelöste Identität im zugriffsgeschützten Inventar festhalten; für Geheimnisse nur sichere Verwahrungs-/Bereitstellungsverweise verwenden. Dies ist keine Anleitung zur neuen Altbereitstellung oder zur Wiederverwendung von Challenge-Geheimnissen. Daraus weder Ziel-SAN-Bedeutungen ableiten noch die alten CA-bezogenen Bedeutungen in eine neue Clientidentität kopieren.

Für jede bestehende SCEP-Konfiguration die folgenden Abhängigkeiten mit der zuständigen PKI-/MDM-Stelle aufnehmen, ohne Alteinträge zur Ermittlung zu verändern:

Bezug: Server- und Challenge-Endpunkt samt Abhängigkeit und gegebenenfalls über das Setup aufgelöster Variablenbindung dokumentieren. Keine Challenge-Passwörter oder anderen Geheimnisse ins Protokoll oder in den Artikel aufnehmen.
Identität und Auswahl: Alten Alias bzw. Auswahlverweis, Benutzer-/Gerätebezug, Subject-Ausdruck und aufgelösten Namen sowie konfigurierte SAN-Art/-Werte und AD-UPN erfassen. Nicht konfigurierte Felder ausdrücklich als fehlend kennzeichnen. Im Pilot mit der benötigten Dienstidentität und tatsächlichen Ziel-Zertifikatsauswahl vergleichen; nicht unterstützte Zuordnungen offenlassen.
Vertrauensbindung: Das tatsächlich ausgewählte Stammzertifikat der aktuellen Altrichtlinie eindeutig zuordnen, bei Bedarf mit Fingerabdruck. SCEP-Serververtrauen getrennt vom Vertrauen in das ausgestellte Clientzertifikat und vom Dienst-Serververtrauen prüfen. Einen noch benötigten Vertrauensanker nicht vor beobachteter Zielabnahme entfernen.
Schlüssel und Zweck: Vorhandene Key size, Kompatibilitätsanforderung der CA und die getrennten Auswahlen/Zwecke für digitale Signatur und Verschlüsselung festhalten. Zielanforderungen mit PKI und nutzendem Dienst klären, das ausgestellte Zertifikat und seine benötigte Verwendung im Pilot prüfen. Weder beide Zwecke pauschal aktivieren noch den alten Schlüsselwert automatisch übernehmen.

Den unterstützten Ziel-Bezugsweg, Zertifikatsrollen und Verwendungszwecke unabhängig anhand der Android-Verbindungen und des dort verlinkten Zertifikats-/SCEP-Runbooks prüfen. Diese Zielanleitungen ersetzen weder die Bestandsaufnahme noch den Nachweis der tatsächlichen Zielwirkung.

Zusätzlich das bestehende Client certificate durch sicheren Verweis auf die tatsächliche PKCS #12 (.pfx)-Datei und den daraus gelesenen Certificate name eindeutig identifizieren. In der Zertifikatsinventur festhalten, welche Konfigurationen derselben Altrichtlinie dieses Zertifikat auswählen. Andere Altrichtlinien benötigten separate Uploads; dies ist eine Altabhängigkeit, keine Aufforderung zur neuen Altbereitstellung. Keinen privaten Schlüssel veröffentlichen oder exportieren und keine automatische Zielübernahme annehmen.

Apps, Berechtigungen und App-Passwort

Restrictions-App-Filter: Den Wert Filter type getrennt von App Control aufnehmen: Allowed apps oder Forbidden apps, zugehörige App-Gruppe und Mitglieder sowie tatsächlich betroffene Apps dokumentieren. Laut Altquelle sind durch Sophos Mobile installierte Apps von diesem Filter ausgenommen; die App-Control-Startsperre ist deshalb kein nachgewiesener Ersatz. Auch eine Sperre des nativen Browsers betrifft laut Altquelle keine Drittanbieter-Browser. Für die benötigte App-/Browser-Schutzabsicht Zielumfang und tatsächliche Wirkung separat nachweisen.
App Control: Die ausgewählte alte App-Gruppe samt Mitgliedern dokumentieren. Diese Sperre verhindert das Starten, auch bei nicht deinstallierbaren Hersteller-Apps; sie entfernt die Apps nicht. Für jede gesperrte App Zielmodus und neue Gruppenzuordnung festhalten. Daraus folgt weder eine automatische Play-Store-Übertragung noch eine Sperre privater Apps im Ziel.
App permissions: Für jede alte App die genaue App-Identität und jede konfigurierte Laufzeitberechtigung mit ihrem Wert notieren: Selectable bedeutet vom Benutzer änderbar, Granted gewährt und Denied verweigert. Je App und Berechtigung Zielmodus, Ziel-App, gewünschte Wirkung und erlaubte Benutzeränderung zuordnen oder einen fehlenden Ersatz benennen. Im Arbeitsprofil ab Android 12 können Standort, Kamera, Mikrofon, Körpersensoren und körperliche Aktivität zwar stellvertretend verweigert, aber nicht gewährt werden. Diese Grenze muss in der Zielentscheidung berücksichtigt sein.
App Protection: Alte App-Gruppe und Mitglieder, Password complexity, Grace period in minutes und Allow fingerprint authentication erfassen. Alle geschützten Apps verwenden dasselbe Passwort; der Benutzer legt es beim ersten Öffnen einer dieser Apps fest. Während der eingestellten Gültigkeitsdauer nach dem Schliessen einer geschützten App können geschützte Apps ohne erneute Passwortabfrage geöffnet werden. Fingerabdruck ist eine mögliche Alternative zum App-Passwort. Der alte Schutz kann über andere Apps/Systemfunktionen oder Mehrfenster umgangen werden; daraus folgt kein gleichwertiger Unternehmensschutz. Die unterstützten Einstellungen für vollständige Geräteverwaltung und Arbeitsprofil unabhängig vergleichen.

E-Mail-Konto und Benutzerübergabe

Für Email account Mail-App, Exchange-Cloud, unterstützte OAuth-Anmeldung und realen Mailfluss gesondert prüfen. Ein altes Passwortfeld oder Allow all certificates ist kein Exchange-Online-Fallback. Neben Server, Zertifikaten und Benutzerzuordnung gehören folgende Altwerte ins Protokoll:

Kontobezeichnung, Route, Transport und Inhalte

Account name und tatsächlichen Server name aufnehmen; direkte Exchange-Adresse von der URL eines EAS proxy unterscheiden. outlook.office365.com gilt für die weltweite Microsoft-365-Cloud, nicht universell für andere Microsoft-Clouds. Den tatsächlich genehmigten Mailweg beobachten, nicht ungeprüft ersetzen.
Die aufgelösten Werte von Email address und Sender unabhängig von User erfassen; %_EMAILADDRESS_% wird in beiden Feldern durch die tatsächliche E-Mail-Adresse ersetzt. Identitätsdaten bleiben im zugriffsgeschützten Protokoll.
Bei Password nur den sicheren Verwahrungs-/Bereitstellungsverweis und die vorhandene Abhängigkeit dokumentieren: Ein leeres Altfeld erforderte die Kennworteingabe durch den Benutzer am Gerät. Das ist keine Empfehlung für Passwort-Fallback statt unterstütztem OAuth.
Vorhandene Zustände von SSL/TLS und Allow all certificates, ausgewähltes Client certificate und Synchronize content types aufnehmen. Die Altoption zur Umgehung der Zertifikatsprüfung ist kein sicherer Zielwert. Für jedes verwendete Mailfeld unterstützte Zielwirkung oder ausdrücklich fehlenden Ersatz festhalten. Im autorisierten Zielpilot tatsächliche Konto-/Absender- und Serveridentität, TLS-Vertrauen sowie die ausgewählten synchronisierten Inhalte mit harmlosen Daten prüfen; weder Passwort-Fallback noch Zertifikatsumgehung einsetzen.

Identität im alten Konto und im Ziel

Zuerst den alten Wert von User und den tatsächlich daraus aufgelösten Anmeldenamen festhalten. Für die Platzhalter %_USERNAME_% und %_EMAILADDRESS_% müssen beim zugewiesenen Benutzer die Felder Exchange Login und Email Address in Sophos Fusion ausgefüllt sein. Die Altquelle beschreibt für Exchange Online in der Regel %_EMAILADDRESS_%, für Exchange Server %_USERNAME_%. E-Mail-Adresse und tatsächlicher Login sind trotzdem nicht automatisch identisch.

Auch Domain gehört ins Protokoll. Laut Altbeschreibung bleibt das Feld bei Exchange Online leer und enthält bei Exchange Server die Domäne des Benutzerkontos. Diese Angaben erklären, welche Identität das alte Konto verwendet. Vor Freigabe die aufgelösten Altwerte und die Benutzerzuordnung mit der gewählten Zielidentität vergleichen. Dabei prüfen, wie Benutzername und Domäne im Ziel dargestellt werden; die unterstützte Anmeldung wird wie oben beschrieben gesondert geprüft.

Einrichtung am Altgerät

OEM/API und automatische oder manuelle Kontoeinrichtung dokumentieren. Die Altbeschreibung nennt LG GATE, Samsung Knox und Sony Enterprise API für automatische Einrichtung. Auf anderen Geräten musste der Benutzer die Mail-App anhand der Konfigurationsdetails in Sophos Mobile Control einrichten. Für den Zielclient eine eigene Benutzerübergabe und einen App-Pilot vorsehen, nicht die alte Einrichtung wiederholen.

Synchronisation und Standardkonto

Synchronization interval als Abstand zwischen Synchronisationen erfassen, getrennt von Synchronization period, dem Alter der berücksichtigten Nachrichten. Zielmechanismus oder fehlenden Ersatz für die Abrufhäufigkeit dokumentieren. Auch Default account aufnehmen und klären, wie die Ziel-App das Standardkonto auswählt oder ob eine verwaltete Vorgabe fehlt.

Datenfluss, Format und Nachrichtengrösse

Bei Allow forwarding emails und Allow use of HTML format die bestehenden Werte und die bisherigen Entscheidungen zum geschäftlichen Bedarf und zum Datenschutz erfassen. Für beide Vorgaben festhalten, ob die Ziel-App oder Exchange sie durchsetzen kann. Andernfalls den fehlenden Ersatz ausdrücklich nennen.

Den Wert von Maximum attachment size in MB wörtlich aufnehmen. Trotz des Feldnamens beschreibt Sophos damit die maximale Grösse einer einzelnen E-Mail-Nachricht, nicht ausdrücklich nur eines Anhangs. Gesondert prüfen, welche Wirkung für den Betrieb relevant ist und welche Grenze die Ziel-App oder Exchange setzt.

Sony-Sonderfall im Altbestand

Die deutsche Quelle nennt Enterprise API Level 6.x oder älter, die englische Level 6 oder früher. Bei betroffenen Geräten müssen die Exchange-Kontoinformationen zum zugewiesenen Benutzer passen. Mobile Control kann dort die ActiveSync-ID nicht übermitteln. Beim ersten EAS-Proxy-Kontakt sucht der Proxy deshalb nach einem Gerät mit unbekannter ActiveSync-ID und passender Benutzerzuordnung. Bei einem Treffer bindet er die vom Mailclient gesendete ID und leitet die Anfrage weiter; andernfalls weist er sie ab. API-Version, zugewiesenen Benutzer und tatsächliche Clientidentität vor Freigabe des alten Kontos abgleichen. Den bestehenden autorisierten Mailweg beobachten, ohne Identitäten zurückzusetzen oder Zugriffskontrollen zu umgehen. Den Zielweg separat nachweisen; diese Altbedingung nicht auf Android-Enterprise-Gmail übertragen.

Kiosk und autorisierter Ausstieg

Bei Kiosk mode den bestehenden Wert von Select source (Custom, App list oder No app), die genaue App ID, tatsächliche Installation, Zuweisungsstatus und Gerätezustand festhalten. Bei App list den ausgewählten, bereits in Sophos Mobile hinzugefügten Android-App-Eintrag dokumentieren und dessen aufgelöste Paketidentität vor der Zielzuordnung mit App ID und der tatsächlich installierten App abgleichen. Fehlt die konfigurierte Kiosk-App bei der alten Richtlinienzuweisung, bleibt die Aufgabe zur Richtlinienzuweisung Incomplete / Unvollständig, bis die App installiert ist. Bei einem solchen Altstatus zuerst Identität und Installation abgleichen; ein Reset ist keine Fehlerbehebung auf Verdacht. No app bedeutet dagegen, dass die Einschränkungen übertragen werden, aber keine App startet. Dies nicht mit einem fehlenden Paket oder einer Enterprise-Option namens None gleichsetzen.

Ohne deaktivierte Gerätefunktionen kann der Benutzer die alte Kiosk-App verlassen und das Gerät normal nutzen; die App-Auswahl allein belegt keine Einsperrung. Insbesondere die vorhandenen Zustände von Allow Home button und Allow task manager sowie den autorisierten physischen oder alternativen Admin-Zugang dokumentieren. Kiosk-App, Startbarkeit und Ausstieg vor Reset prüfen und für den Zielmodus getrennt nachweisen.

Bei Sony Enterprise API Level 9 oder neuer gilt laut Altquelle: Ist auch nur eine der Optionen Allow volume up, Allow volume down oder Allow volume mute deaktiviert, sind alle Lautstärketasten deaktiviert. Betroffenes Modell, API-Level und Altzustand aufnehmen. Im autorisierten Zielpilot prüfen, welche Ton- und Tastensteuerung für dieses Modell und den gewählten Verwaltungsmodus unterstützt wird. Den benötigten Ton und die benötigten Tasten am Gerät testen, statt die alte Wirkung vorauszusetzen.

Knox Premium, Startschutz und Administrator-Apps

Den bestehenden Wert von Allow firmware auto update options samt Zuständigkeit und Geräte-/Lizenzunterstützung aufnehmen. Die Altoption lässt das Gerät automatisch nach Firmware-Updates suchen; der Benutzer kann dies in den Geräteeinstellungen nicht ändern. Das bedeutet nicht, dass jedes Firmware-Update automatisch installiert wird. Den unterstützten Zielersatz oder dessen Fehlen getrennt festhalten und das tatsächliche Ziel-Updateverhalten im autorisierten Pilot beobachten, ohne alte Optionen neu zu aktivieren.

Alte Knox Premium restrictions wirken auf das Samsung-Knox-Gerät, nicht auf den Knox-Container. Die Durchsetzung setzt eine in Sophos Mobile registrierte Samsung Knox Premium-Lizenz voraus. Gerätetyp, Lizenzregistrierung und tatsächliche Gerätewirkung getrennt prüfen. Für den gewählten Enterprise-Zielmodus eigens klären, welche Lizenz benötigt wird und welche Gerätewirkung unterstützt ist; die alte Lizenzregistrierung belegt keine Übertragung.

Den vorhandenen Zustand von Enable ODE Trusted Boot verification festhalten. Laut Altbeschreibung wird die Datenpartition beim Start nur bei offiziellem Binary und Kernel entschlüsselt. Datenzugang und autorisierten Wiederherstellungsweg vor Neustart oder Reset klären; die Verifikation nicht als Migrations- oder Recovery-Abkürzung deaktivieren.

Prevent installation of another administrator app und Prevent activation of another administration app getrennt erfassen. Die erste Altoption verhindert die Installation von Apps mit Geräteadministrator-Rechten, ausgenommen durch Sophos Mobile installierte Apps; die zweite verhindert die Aktivierung dieser Rechte. Die tatsächliche Wirkung auf benötigte Apps und den vorgesehenen Einschreibungsweg vorab prüfen, ohne die Sperren pauschal zu lockern.

Bei vorhandenem Allow Common Criteria mode zusätzlich alle sechs Altbedingungen erfassen:

Geräteverschlüsselung ein;
Schnellverschlüsselung aus;
Verschlüsselung externen Speichers ein;
Fehlversuchsschwelle bis zum Geräte-Wipe gesetzt;
Zertifikat-Widerruf ein;
Kennwortverlauf aus.

Ohne diese Bedingungen wird der CC Mode laut Altquelle nicht angewendet. Dies sind Ausgangsabhängigkeiten, keine Aufforderung, alte Optionen neu zu aktivieren oder den Passwortschutz im Ziel zu schwächen. Keine Fehlversuchs-Löschtests auf produktiven Geräten. Aktuelle Unterstützung, Zielersatz und Wiederherstellung separat am autorisierten Pilot prüfen; die Altbeschreibung ist kein aktueller Zertifizierungsnachweis.

Displaysperre und Einschränkungen

Für die bestehende Displaysperre unter Password policies den Wert von Password type und seine Altbedeutung erfassen: Pattern, PIN or password verlangt eine Displaysperre ohne zusätzliche Einschränkungen; Simple password verlangt ein Passwort mit mindestens einem Buchstaben, Ziffern sind erlaubt; PIN or password erlaubt diese beiden Sperrtypen. Alphanumeric password und Complex password verlangen ein Passwort mit Buchstaben und Ziffern. Nur Complex password ergänzt die unten genannten sechs Zusammensetzungs-Mindestwerte. Dies beschreibt die Ausgangsrichtlinie, nicht die Einrichtung einer neuen Altrichtlinie oder identisches Android-Enterprise-Verhalten.

Für Simple password, PIN or password, Alphanumeric password und Complex password zusätzlich die jeweils vorhandenen Werte aufnehmen: Minimum password length (Gesamtzahl der Zeichen), Maximum idle time before password prompt (eingestellte Inaktivitätsdauer; das Gerät kann eine kürzere Dauer erzwingen), Maximum password age in days (Wechselintervall; Altbereich 0–730 Tage, bei 0 ist kein Wechsel verlangt), Maximum sign-in attempts (Fehlversuche bis zum alten Geräte-Wipe) und Password history (Anzahl gespeicherter früherer Passwörter, die nicht wiederverwendet werden dürfen). Für beim gewählten Typ fehlende Felder keine Werte erfinden. Vor Freigabe für Typ und jedes Feld unterstützte Zielwirkung oder ausdrückliches Fehlen, OS/OEM und gewählte Geräte- oder Arbeitsprofilsperre dokumentieren; Altwerte nicht automatisch übernehmen.

Bei Password policies für einen bestehenden Complex password die sechs Mindestwerte einzeln erfassen: Buchstaben, Kleinbuchstaben, Grossbuchstaben, nicht-alphabetische Zeichen, Ziffern und Sonderzeichen. Nicht-alphabetische Zeichen und Sonderzeichen sind separate Altwerte, keine zusammengefasste Anforderung. Jeden Wert mit der gewählten vollständigen Geräteverwaltung, Gerätesperre oder Arbeitsprofilsperre und den OS-/OEM-Kennzeichnungen abgleichen. Für jeden Mindestwert den unterstützten Ersatz oder dessen Fehlen sowie die nicht destruktiv beobachtete Durchsetzung dokumentieren.

Auch Allow fingerprint authentication und Allow iris authentication samt vorhandener Auswahl aufnehmen. Die alten Entsperrmethoden gelten nur auf Geräten, die sie unterstützen. Verfügbarkeit und tatsächlich erlaubte Entsperrmethoden im Zielmodus nach OS und OEM separat prüfen. App-Protection-Fingerabdruck oder Weak biometric recognition belegen keinen identischen Ersatz.

Für Password policies und Restrictions Wiederherstellung, Backup sowie OS-/Modus-Wirkung jeder relevanten Sperre und Einschränkung prüfen; keine Gleichwirkung auf Privat- und Firmengeräten annehmen. Eine Fehlversuchsschwelle kann das Gerät löschen; nicht auf produktiven Geräten testen.

Für die tatsächlich verwendeten Restrictions die Matrix bis zur einzelnen relevanten Einstellung ausfüllen: Altwert, am Gerät beobachtete Wirkung, geschäftliche Schutzabsicht, OS/OEM und Haupt-/Unterabhängigkeiten, unterstützter Zielersatz oder ausdrückliche Abweichung mit Freigabe. Einzubeziehen sind insbesondere Datenweitergabe und Aufzeichnung, Funk-/Sharing- und Peripherienutzung, Erreichbarkeit/Notfallkommunikation/Roaming, Updates/Recovery, Konten einschliesslich Google-Kontoentfernung sowie App-Installationsquellen und Deinstallation. Unbenutztes oder Nichtanwendbares begründet ausschliessen. Sperren nicht nur nach Namen bewerten: Ein Videoverbot lässt laut Altquelle Fotos und Streaming zu; die geteilte Zwischenablage setzt Allow clipboard voraus. Bei genutztem Bluetooth auch bestehende Paarungen und Profile, bei Tethering oder Lockscreen-Kamera auch die Hauptoption prüfen; relevante SD-/USB-Unterwerte ebenfalls gemeinsam mit ihren Hauptoptionen erfassen. Eine alte Beam-Sperre kontrolliert Quick Share nicht. Im autorisierten Zielpilot die benötigten Funktionen und verbotenen Datenflüsse mit harmlosen Testdaten nachweisen; bei fehlendem Ersatz oder anderer Wirkung den Rollout bis zur dokumentierten Entscheidung stoppen.

Die historischen Unterseiten beschreiben Ausgangseinstellungen, teils aus 2022–2023, nicht die aktuelle Unterstützung alter Protokolle/OEM-Funktionen auf Zielgeräten. Die Prüfbereiche zeigen, welche Abhängigkeiten vor der Migration zu klären sind. Vor konkreten Richtlinienempfehlungen beide vollständigen Zielrichtlinien und den eigenen Mandanten prüfen. Die getrennten KB-Themen für vollständig verwaltete Geräterichtlinien, Arbeitsprofilrichtlinien, Android-Verbindungen, BYOD und FRP ersetzen die Migrationsfreigabe nicht. Mail-Authentisierung behandelt zusätzlich der Artikel zur Exchange-Migration.

Pilot, Abbruch und Rückweg

Nur nach geklärter Eigentums-/Tenant-/Lizenzlage und autorisiertem Wiederherstellungsweg an entbehrlichen repräsentativen Geräten pro Modus pilotieren. Vorher Gerätedaten und bisherige Richtlinien sichern, neue Richtlinie und Registrierungsmethode getrennt vorbereiten. Im Pilot den Auftrag am Gerät bestätigen, den neuen Verwaltungsmodus und die tatsächliche Zuweisung kontrollieren und Apps, Kontoanmeldung/Mailfluss, Kiosk (falls vorhanden), WLAN/VPN, Zertifikatsausstellung und -erneuerung sowie private Daten nach BYOD-Umstellung beobachten. Erst nach belegter Wirkung über weitere Geräte entscheiden.

Für die erfassten Altwerte im Pilot konkrete Soll-/Ist-Ergebnisse festhalten:

Mobilfunk

Mit der vorgesehenen SIM beim vorgesehenen Betreiber mobilen Datenzugang prüfen, getrennt vom zuvor getesteten unabhängigen Wiederherstellungs-/Management-Zugang. Danach den Management-Check-in kontrollieren. Bei fehlendem Datenzugang keine weiteren Geräte migrieren; den vorab autorisierten unabhängigen Zugang und Eskalationsweg verwenden.

Apps und Berechtigungen

Zuerst das Startverhalten jeder bisher gesperrten App sowie die benötigten Betriebs- und Notfall-Apps prüfen. Anschliessend mit Testdaten jede Ziel-App und ihre Laufzeitberechtigungen kontrollieren. Den Sollzustand mit der tatsächlichen App-Funktion bei gewährter oder verweigerter Berechtigung vergleichen. Auch prüfen, ob der Benutzer die Berechtigung wie vorgesehen ändern darf oder eine Änderung verhindert wird. Dabei die Android-12-Grenzen im Arbeitsprofil berücksichtigen.

Vor einer Änderung die Einstellungen und die Zuweisung protokollieren. Nur den unterstützten, zuvor getesteten Aktualisierungs- oder Ersatzweg verwenden. Muss eine Richtlinienänderung zurückgenommen werden, die Synchronisation bestätigen und dieselben Berechtigungsprüfungen wiederholen.

Nicht pauschal Berechtigungen gewähren, nur damit eine App funktioniert. Ein späterer Entzug holt bereits offengelegte Daten nicht zurück.

App-Passwort und Displaysperre

Im Ziel die erwartete Passwortabfrage, erlaubte alternative Zugriffe, Gültigkeitsdauer ohne erneute Abfrage und Authentisierung prüfen. Bei Geräte- bzw. Arbeitsprofilsperre die einzelnen Mindestanforderungen und verfügbaren biometrischen Methoden nicht destruktiv kontrollieren, ohne die Fehlversuchsschwelle auszureizen.

Für die gewählte Zielsperre erlaubte Sperrtypen und Gesamtlänge mit der dokumentierten Entscheidung vergleichen und die tatsächliche Inaktivitätsdauer bis zur Passwortabfrage einschliesslich kürzerer Gerätelimits beobachten. Wechsel- und Wiederverwendungsverhalten, soweit unterstützt, an einem autorisierten Testkonto/-gerät oder anhand unterstützter Statusnachweise prüfen; fehlende Unterstützung ausdrücklich festhalten. Auf produktiven Geräten weder Passwortwechsel beschleunigen noch den Schutz schwächen oder Fehlversuche ausschöpfen. Den vorbereiteten Wiederherstellungsweg beibehalten und bei Abweichungen den Rollout stoppen.

Mail

In einem autorisierten Testkonto Zustellzeit, Standardkonto beim Verfassen, erlaubte/verbotene Weiterleitung, HTML-Verhalten und relevante Nachrichtengrössen mit harmlosen Inhalten prüfen. Keine echten vertraulichen Daten verwenden. Ergebnis mit der dokumentierten Zielentscheidung vergleichen, auch wenn eine bisher verwaltete Vorgabe im Ziel fehlt.

Bei Abweichungen anhalten

Bei einer Abweichung den Rollout stoppen. Eine sichtbare Zielkonfiguration allein genügt nicht; zuerst Ursache, unterstützten Ersatz und sicheren Rückweg klären.

Bei fehlender Erreichbarkeit, unklarem Datenstand, falschem Gerät/Modus, fehlgeschlagener Anmeldung oder Reset-Sperre anhalten und eskalieren. Vor dem Eingriff den zuständigen Support, eine funktionierende unabhängige Verbindung und einen Wiederbereitstellungsweg festlegen. Rollback ist nicht das Rückgängigmachen von Werksreset oder gelöschtem Arbeitsprofil: Wiederherstellung gelingt nur aus nachweislich nutzbaren Sicherungen und durch autorisierte Neueinschreibung; weder sofortige Fernzustellung noch identische Richtlinienwirkung ist belegt. Ohne Tenant- und Gerätetest keine produktive Migrationsanleitung oder Erfolgsgarantie.