Sophos Mobile Self Service Portal: Aktionen und Geräteeinschreibung sicher freigeben

Berechtigung für diesen Ablauf: Zum Erstellen und Ändern der Mobile-SSP-Einstellungen benötigt man Zugriff mit den entsprechenden Rechten der Sophos-Mobile-Rolle Administrator. Die vordefinierten Sophos-Fusion-Rollen Admin und Super Admin werden in Mobile dieser Rolle zugeordnet; für diesen Ablauf allein ist Super Admin deshalb nicht nötig. Help Desk entspricht in Mobile Helpdesk und darf diese Einstellungen nicht definieren; Read-only darf sie nur lesen, User hat keinen Zugang zur Mobile-Administration. Daraus lässt sich keine Mindestberechtigung einer Custom Role ableiten: Deren konkrete Mobile-Bearbeitungsrechte müssen im Tenant separat geklärt sein, bevor man mit den Einstellungen beginnt. Die vorhandene, passend berechtigte Identität verwenden, nicht pauschal zusätzliche Rechte vergeben.

Schnellweg für Admins: Unter Setup > Self Service Portal eine Konfiguration für eine eng begrenzte Pilotgruppe erstellen, Plattform und Besitzmodus passend zur Geräteflotte wählen und unter Actions > Show nur die für diese Gruppe benötigten Aktionen markieren. Vor Save Pilotgruppe und Aktionen eng begrenzen: Das Speichern kann gewählte Aktionen für bereits zugeordnete Gruppen verfügbar machen. Nach Save auf Self Service Portal configurations die Priorität mit den Pfeilen gegenüber allen passenden Konfigurationen und Default prüfen und nötigenfalls korrigieren. Erst nach Prüfung mit Pilot- und Default-Testkonto und tatsächlicher Einschreibung freigegebener Testgeräte auf jeder vorgesehenen Plattform und in jedem vorgesehenen Besitz-/Verwaltungsmodus weitere Benutzer zuordnen. Destruktive Aktionen nicht allein deshalb freigeben, weil sie in der Liste erscheinen.

Das ist die Sophos-Mobile-Berechtigung innerhalb des SSP, nicht die allgemeine Kontoanmeldung. Die Vergabe und Zustellung des Sophos-Fusion-SSP-Zugriffs sowie Administrationsrollen in Sophos Fusion sind eigenständige Aufgaben. Eine SSP-Benutzergruppe ist keine Admin-Rolle: Sie bestimmt hier, welche Mobile-Konfiguration für ein angemeldetes Mitglied gilt. Der gemeinsame Sophos Fusion Self Service Portal-Zugang kann bei entsprechender Produktberechtigung auch Sophos Email und Sophos Device Encryption umfassen. Weniger Mobile-Gruppen- oder Aktionsrechte entziehen weder eine separat erteilte Portal-Anmeldung noch den Zugang zu diesen anderen Produktfunktionen. Auch das Ausschalten des automatischen User Access entzieht bereits gewährten Portalzugriff nicht. Dieser Artikel behandelt die Konfiguration durch den Admin, nicht die Klickfolge der betroffenen Person bei Verlust, Wiederherstellung oder Einrichtung auf dem eigenen Gerät.

Vor der Freigabe den Geltungsbereich festlegen

Man inventarisiert zuerst den tatsächlichen Mobile-Produktumfang im Tenant, die verwalteten Plattformen und Besitzmodelle (corporate oder personal), die Benutzergruppen und die vorgesehenen Einschreibepakete. Die Dokumentation für Sophos Mobile Device Management beziehungsweise die kombinierte Lizenz beschreibt mehr Geräteaktionen als die getrennte Sophos-Mobile-Threat-Defense-Dokumentation. Eine in einer Editionsliste genannte Aktion ist deshalb keine Zusage, dass sie im eigenen Tenant, für das konkrete Betriebssystem und dessen Verwaltungsmodus zur Verfügung steht.

App-Registrierung und MDM-Einschreibung getrennt planen: Für Android sowie iPhone/iPad betrifft der Threat-Defense-Weg die Registrierung von Sophos Intercept X for Mobile und die zugehörige MTD-Richtlinie, nicht automatisch die MDM-Verwaltung des Geräts oder eines Arbeitsprofils. Vor der SSP-Freigabe prüfen, welche Registrierungsaufgabe das ausgewählte Paket im eigenen Tenant auslöst. Die Intercept-X-Registrierung erklärt die App-Voraussetzungen und Registrierungswege; eine geplante MDM-Einschreibung benötigt dagegen einen gesondert bestätigten Verwaltungsmodus. Eine registrierte App oder ein Geräteeintrag allein belegt weder MDM-Verwaltung noch wirksamen Schutz.

ChromeOS bleibt ein eigener Weg: Die manuelle SSP-Registrierung betrifft die Erweiterung Sophos Chrome Security: Der Benutzer installiert sie und gibt ein Registrierungstoken ein. Sie ist weder die Android-/iOS-App-Registrierung noch deren MDM-Einschreibung. Die Chrome-Security-Anleitung trennt diesen Weg von der automatischen Google-Workspace-Verteilung.

Als Pilotbeispiel dient eine eigens angelegte Gruppe Mobile-SSP-Pilot, die nur benannte Testpersonen enthält. Der Name ist frei wählbar; entscheidend ist die Mitgliedschaft: Bestehende produktive Gruppen werden nicht bloss für einen Schnelltest hinzugefügt. Eine Person kann Mitglied mehrerer Gruppen sein; dann gilt die SSP-Konfiguration mit der höchsten Priorität. Die immer vorhandene Default-Konfiguration hat die niedrigste Priorität und greift, wenn keine höher priorisierte Konfiguration passt. Vor dem Rollout werden deshalb alle Überschneidungen mit breiteren Gruppen geprüft.

Konfiguration und Texte vorbereiten

Administrative Basiseinstellungen getrennt vorbereiten: Zur Mobile-Starteinrichtung gehören neben der SSP-Konfiguration auch persönliche Einstellungen und der technische Supportkontakt. Der zuständige Admin richtet unter Setup > General > Personal die Anzeigeeinstellungen für sein angemeldetes Admin-Konto ein und speichert sie mit Save; daraus folgt weder ein vorgeschriebener Einstellungswert noch eine allgemeine Einschreibevoraussetzung. Die zuständige IT hinterlegt getrennt davon unter Setup > General > IT contact die freigegebenen Kontaktinformationen und wählt Save. Den Ablauf und die weiterführende Einrichtung samt Kontrolle erklärt Vor der Übergabe an Benutzer. Das spätere Öffnen von Support in Mobile Control zeigt hinterlegte Angaben, richtet sie aber nicht ein.

Avanet-Sequenzschutz vor dem SSP-Update oder Save: Für jede tatsächlich vorgesehene Plattform, den Besitzmodus und den gewählten App- oder MDM-Weg vor dem Aktualisieren oder Speichern prüfen, ob die benötigte Konfiguration vorbereitet ist: passende Compliance- und MTD- beziehungsweise Geräterichtlinien, Gerätegruppen sowie vorhandene, zum Pfad und zur Edition passende Einschreibepakete beziehungsweise Task Bundles. Bei geplantem Android-Enterprise-MDM-Pfad dessen Einrichtung, bei geplanter MDM-Verwaltung von iPhone, iPad oder Mac ein gültiges APNs-Zertifikat einbeziehen. Diese MDM-Voraussetzungen nicht allein aus der Android-/iOS-App-Registrierung ableiten; Anforderungen eines zusätzlich vorgesehenen iOS-Webfilterprofils getrennt nach dem App-Ablauf prüfen. Lizenzaktivierung und EAS-Proxy nur prüfen, soweit der eingesetzte Produktumfang beziehungsweise E-Mail-Pfad sie benötigt; beides ist keine allgemeine SSP-Voraussetzung. Fehlt etwas für einen vorgesehenen Pfad, zuerst diese Vorbereitung klären, statt die SSP-Einstellungen dafür freizugeben. Dies ist eine Avanet-Empfehlung zur Reihenfolge, keine von Sophos vorgeschriebene zusätzliche formale Freigabe und kein Ersatz für den anschliessenden echten Einschreibetest.

Nur wenn der geplante E-Mail-Pfad EAS nutzt: Der optionale Sophos-Mobile-EAS-Proxy dient dazu, E-Mail-Verkehr von verwalteten Geräten zum Mailserver zu filtern beziehungsweise den EAS-Zugriff zu kontrollieren. Im Proxy-Modus läuft dieser Verkehr durch den Proxy; im PowerShell-Modus verbinden sich die Geräte direkt mit Exchange und der Dienst steuert den Zugriff über eine getrennte Verwaltungsverbindung. Dafür zuerst die modusabhängige EAS-Architektur und Zugriffskontrolle und die EAS-Installationsvorprüfung mit dokumentiertem Konfigurationsumfang mit dem zuständigen Mobile-/Exchange-Team klären. Diese Übergabe ist eine dokumentarische Vorprüfung, keine Installations- oder Umstellungsfreigabe; konkrete Build-, Mailclient- und Tenant-Kompatibilität sowie der separat autorisierte Pilot bleiben zu bestätigen. Sie ersetzt keinen Labortest und klärt insbesondere keine dort noch offene Dienststart-Reihenfolge. EAS ist weder eine allgemeine SSP-Voraussetzung noch Bestandteil der hier beschriebenen SSP-Klickfolge.

1. Setup > Self Service Portal > Enrollment texts öffnen. Bei Bedarf unter Terms of use einen verständlichen Text vor und unter Post-enrollment text eine kurze Anleitung nach der Einschreibung anlegen, jeweils Namen und Inhalt speichern. Sophos erlaubt HTML-Formatierung; nur geprüfte, datensparsame Inhalte ohne persönliche Gerätekennungen oder Zugangsdaten verwenden. Die Zustimmung zum Terms-of-use-Text ist erforderlich, wenn dieser Text dem Einschreibetyp zugewiesen ist; ein leeres Feld zeigt keinen Text.
2. Auf Self Service Portal configurations mit Create eine Konfiguration anlegen. Unter Name den Namen festlegen, anhand dessen Benutzer im SSP die Konfiguration auswählen; das ist nicht der Display name, mit dem sie später einen Einschreibetyp wählen. Unter User groups > Add die Pilotgruppe wählen. Eine Konfiguration kann mehrere Benutzergruppen enthalten; für diesen Pilot bleibt es zunächst bei der eng begrenzten Testgruppe. Dieselbe Gruppe lässt sich nicht mehreren Konfigurationen zuordnen. Unter Maximum number of devices ein zur eigenen Richtlinie passendes Limit festlegen; es begrenzt die Zahl der Geräte, die ein Benutzer über das SSP einschreiben kann, und ist kein pauschales Lösch- oder Bestandslimit.
3. Unter Actions > Show zunächst nur die benötigten Aktionen auswählen. Danach mit Add eine Plattform hinzufügen. Im Dialog Configure platform settings Display name und Description aus Benutzersicht formulieren. Benutzer sehen Description im SSP neben dem Display name des Einschreibetyps, nicht neben dem Konfigurationsnamen Name. Owner, Device group und Enrollment package mit dem geplanten App- oder MDM-Weg und einer bewusst gewählten Gerätegruppe abgleichen. In der vollständigen Mobile-Edition ist das Enrollment package für Android, iOS und macOS ein Task Bundle, für Windows eine Policy; in der Threat-Defense-Anleitung wird ein Task Bundle genannt. Nicht das Paket einer anderen Edition übernehmen. Für den Android-/iOS-App-Weg prüfen, ob das vorhandene Bundle die vorgesehene MTD-Registrierungsaufgabe und Richtlinienzuweisung enthält. Die Policy-Auswahl im Add device wizard ist keine zusätzliche SSP-Paketoption.
4. Optional je Einschreibetyp einen Terms of use- und einen Post-enrollment text auswählen, Apply wählen und für andere Plattformen oder Besitzmodelle eigene Plattform-Einstellungen konfigurieren. Erst wenn Pilotgruppe und Aktionen eng begrenzt sind, auf der Bearbeitungsseite Save wählen. Danach auf Self Service Portal configurations mit den Pfeilen die Priorität gegenüber allen Konfigurationen mit passenden Gruppen und Default prüfen und gegebenenfalls korrigieren. Das Speichern ist kein folgenloser Entwurfsschritt: Bei bereits zugeordneten Benutzern können Aktionen schon vor der Prioritätskorrektur sichtbar werden.

Aktionen nach Wirkung und Modus trennen

Plattformzuordnung in Mobile Threat Defense: Die Aktionsliste nennt Reconfigure device und Show compliance violations für Android-Geräte sowie iPhone und iPad. Refresh data und Delete unmanaged device sind für Android-Geräte, iPhone und iPad sowie Chromebooks aufgeführt. Diese und die folgenden Plattformangaben für die vollständige Mobile-Edition beschreiben die dokumentierten Editionslisten. Sie garantieren keine Verfügbarkeit für den eigenen Tenant, die Lizenz, das konkrete Gerät, dessen Besitz- oder Verwaltungsmodus; diese Voraussetzungen vor einer Freigabe prüfen.

• Beobachten / aktualisieren: Die vollständige Mobile-Edition nennt Show compliance violations für Android-Geräte, iPhone/iPad, Mac und Windows. Die Aktion zeigt Details von Regelverstössen bei nicht konformen Geräten, nicht einen allgemeinen Compliance-Bericht. Refresh data ist dort für Android-Geräte, iPhone/iPad, Mac, Windows und Chromebooks aufgeführt; es stösst die Synchronisation des Geräts mit Sophos Mobile an und kann dessen Compliance-Status beeinflussen. Je nach Compliance-Richtlinie kann längere ausbleibende Synchronisation ein Gerät nicht konform machen, etwa wenn es lange ausgeschaltet war. Ist dies die Ursache, kann Refresh data durch erneute Synchronisation die Konformität wiederherstellen; andere Regelverstösse werden dadurch nicht automatisch behoben. Für den ersten Berechtigungstest nur die Sichtbarkeit dieser Optionen mit dem Pilotkonto prüfen, ohne eine Aktion auszulösen. Refresh data bei Bedarf erst separat am freigegebenen Testgerät ausführen und danach Synchronisation und Compliance-Status prüfen; Plattform und Edition vorher abgleichen.
• Rekonfiguration ist kein harmloses Aktualisieren: Die vollständige Mobile-Edition nennt Reconfigure device für Android-Geräte, iPhone/iPad, Mac und Windows. Sie beschreibt die Neukonfiguration der Sophos Mobile Control-App, etwa nach versehentlicher Deinstallation; Mobile Threat Defense betrifft dagegen die Sophos Intercept X for Mobile-App. Die benutzerseitige Anleitung zur Neukonfiguration der Geräteverwaltung warnt: Ein bereits verwaltetes Gerät wird dabei abgemeldet und muss erneut eingeschrieben werden. Diese Warnung gilt für den beschriebenen Geräteverwaltungs-Ablauf, nicht pauschal für die heutige Mobile-Control- oder Threat-Defense-App-Rekonfiguration. Vor Freigabe oder Ausführung den exakten Ablauf für Edition, Tenant und Testgerät prüfen und eine gegebenenfalls nötige erneute Einschreibung samt Auswirkungen auf Richtlinien einplanen; nicht als blossen Reparatur-Refresh testen.
• Getrennte App-Rekonfiguration (vollständige Mobile-Edition): Reconfigure the SMC app betrifft eine bereits installierte Sophos Mobile Control-App auf iPhone oder iPad. Diese eigene SSP-Aktion nicht mit Reconfigure device gleichsetzen. Der Admin prüft vor einer möglichen Freigabe, ob sie im Tenant für das betreffende Gerät und dessen Verwaltungsmodus angeboten wird und welche Folgen der konkrete Ablauf hat; die Auswahl unter Actions > Show delegiert nur eine mögliche Benutzeraktion, sie führt keine Rekonfiguration aus.
• Eingriff mit Sicherheits- oder Datenschutzfolge: Locate device kann Standortdaten offenlegen; die vollständige Mobile-Edition nennt Android, iPhone/iPad, Windows und ChromeOS, die Threat-Defense-Liste dagegen nur Chromebooks. Lock device ist in der vollständigen Mobile-Liste für Android, iPhone/iPad und Mac aufgeführt; daraus folgt keine Verfügbarkeit in jeder Edition und jedem Verwaltungsmodus. Keine dieser Optionen als universelle «Gerät finden»-Hilfe freischalten.
• Geräte- oder Profil-Sperrkennwort (vollständige Mobile-Edition): Reset password betrifft die Gerätesperre, nicht die Anmeldung am Fusion SSP. Sophos beschreibt für Android-Geräte sowie iPhone/iPad ein Einmalkennwort, das nach dem Entsperren geändert werden muss; bei Android Enterprise mit Arbeitsprofil wird stattdessen das Kennwort des Arbeitsprofils zurückgesetzt, nicht pauschal die Sperre des ganzen Privatgeräts. Für iPhone/iPad nennt dieselbe Aktionsbeschreibung zusätzlich das Löschen des bisherigen Gerätekennworts: Ein neues muss innerhalb von 60 Minuten gesetzt werden. Diese je nach Plattform und Profil unterschiedlichen Folgen vor einer Delegation mit dem zuständigen Geräte- und Incident-Verantwortlichen klären; die Angaben sind keine Anleitung zum Auslösen oder Testen eines Resets.
• Apple User Enrollment (vollständige Mobile-Edition): Sophos schliesst diesen Verwaltungsmodus ausdrücklich von Locate device, Reset password, Wipe, Managed Lost Mode und Play Lost Mode sound aus. Die beiden Lost-Mode-Aktionen gelten laut Aktionsliste für iPhone/iPad ausserhalb dieses Modus, nicht für Android oder jede Apple-Einschreibung. Managed Lost Mode schaltet den verwalteten Verlustmodus ein oder aus; Play Lost Mode sound spielt einen Ton auf einem Gerät, das sich bereits in Managed Lost Mode befindet. Das beschreibt die Aktionen, nicht ihre erfolgreiche Zustellung oder Ausführung am konkreten Gerät. Für andere Aktionen weder aus dieser Ausschlussliste eine Freigabe noch aus allgemeinen Plattformangaben eine konkrete Verfügbarkeit ableiten.
• App-Schutz-Kennwort (vollständige Mobile-Edition): Reset App Protection password ist als eigene SSP-Aktion für Android-Geräte aufgeführt und setzt das Kennwort für als geschützt definierte Apps zurück; es ist nicht Reset password für die Gerätesperre. Nur bei tatsächlich eingesetztem App-Schutz und nach Prüfung der Geräte-/Tenant-Verfügbarkeit als Benutzeraktion freigeben, nicht pauschal für alle Android-Benutzer.
• Wipe (vollständige Mobile-Edition): Die Aktionsliste nennt Android-Geräte, iPhone/iPad, Mac und Windows für das Zurücksetzen eines verlorenen oder gestohlenen Geräts auf Werkseinstellungen; dabei werden alle Gerätedaten gelöscht. Für iPhone/iPad mit Apple User Enrollment ausdrücklich ausgeschlossen. Die getrennte Arbeitsprofil-Löschung ist keine vollständige Gerätezurücksetzung.
• Wipe Android work profile (vollständige Mobile-Edition): Entfernt bei Android-Geräten, auf denen Sophos Mobile nur das Arbeitsprofil verwaltet, alle Arbeits-Apps und Arbeitsdaten einschliesslich Sophos Mobile Control und hebt die Sophos-Mobile-Einschreibung auf. Persönliche Apps und Daten werden dabei nicht entfernt. Das Entfernen lässt sich nicht rückgängig machen; es ist nicht mit einem vollständigen Geräte-Wipe gleichzusetzen.
• Unenroll device (Abmeldung im dokumentierten Mobile-MDM-Selbstbedienungsablauf): Die Aktionsliste der vollständigen Mobile-Edition nennt Android-Geräte, iPhone/iPad, Mac, Windows und Chromebooks. Diese Plattformliste ist von den modusabhängigen Abmeldewegen und Folgen zu trennen. Die Abmeldung beendet nicht bloss die Verwaltung: Bei Android Enterprise fully managed setzt sie das gesamte Gerät auf Werkseinstellungen zurück. Bei iPhone/iPad entfernt sie die von Sophos Mobile installierten Verwaltungsprofile, verwalteten Apps, Konten samt zugehörigen Daten (einschliesslich geschäftlicher E-Mail) und Zertifikate; bei Macs die von Sophos Mobile installierten Richtlinien, Konten samt zugehörigen Daten (einschliesslich geschäftlicher E-Mail) und Zertifikate. Für Android mit Arbeitsprofil gilt dieser allgemeine Abmeldeablauf laut Sophos nicht: Dafür ist Wipe Android work profile der getrennte Entfernungsweg. Andere Gerätearten haben wiederum andere Folgen; weder ein genereller Werksreset noch folgenloses Abmelden lässt sich aus dem Aktionsnamen ableiten. Die Abmeldung lässt sich nicht rückgängig machen.
• Delete unmanaged device: Die vollständige Mobile-Edition nennt Android-Geräte, iPhone/iPad, Mac, Windows und Chromebooks. Die Aktion löscht nach Abmeldung oder Zurücksetzen den nicht mehr verwalteten Geräteeintrag aus Sophos Mobile; sie ist weder Geräte-Wipe noch Ersatz für die Abmeldung. Die Threat-Defense-Aktionsliste enthält kein Wipe und keine Arbeitsprofil-Löschung, nennt aber unter anderem Unenroll device für Android, iOS/iPadOS und ChromeOS. Ein dokumentierter Eintrag beweist nicht die Wirkung auf dem konkreten Gerät.

Vor Freigabe und erst recht vor Ausführung von Wipe, Unenroll device oder Wipe Android work profile: Für die konkreten Geräte Plattform, Besitz und Verwaltungs-/Profilmodus bestätigen; Backup und Datenaufbewahrung, Datenschutz und Incident-Verfahren sowie die zuständige Änderungs-/Incident-Freigabe vor Delegation klären und ausdrücklich autorisieren lassen. Dasselbe gilt entsprechend für andere Lösch-, Sperr- oder Verlustmodusaktionen. Ohne ausdrückliche Autorisierung keine dieser Aktionen zur «Validierung» auslösen; erneute Einschreibung stellt gelöschte Daten nicht automatisch wieder her.

Für privat genutzte Geräte dürfen Standortermittlung und vollständiges Löschen nicht aus einer allgemeinen Plattformübersicht abgeleitet werden; die fünf ausdrücklichen Ausschlüsse für Apple User Enrollment stehen oben und sind nicht auf jede private Einschreibung übertragbar. Geräte- und Profilmodus sind vor jeder Notfallentscheidung am konkreten Gerät zu bestätigen. Die Aktionsfreigabe im SSP ist eine Delegation an Benutzer, keine Anweisung an den Administrator, selbst ein verlorenes Gerät aus der Ferne zu löschen.

Pilot prüfen und bei Abweichungen stoppen

Vor dem abschliessenden SSP-Einschreibetest die Voraussetzungen für den tatsächlich gewählten App- oder MDM-Weg prüfen. Für die Android-/iOS-App-Registrierung müssen App-Unterstützung, MTD-Berechtigung, das vorhandene Registrierungsbundle und die vorgesehene MTD-Richtlinie passen; zusätzliche iOS-Webfilterprofil-Anforderungen nach der verlinkten App-Anleitung gesondert prüfen. Bei einer MDM-Einschreibung gilt dagegen: Wenn Android Enterprise für den vorgesehenen Android-Verwaltungsmodus genutzt wird, müssen der passende Modus und die Android-Enterprise-Einrichtung der Organisation bereitstehen; bei einem anderen unterstützten Android-Verwaltungsmodus dessen Voraussetzungen gesondert prüfen. Für die MDM-Verwaltung von iPhone, iPad oder Mac muss ein gültiges APNs-Zertifikat bereitstehen. Android Enterprise und dieses APNs-Erfordernis nicht pauschal zur Voraussetzung der reinen App-Registrierung machen. Relevante Compliance- und MTD- beziehungsweise Geräterichtlinien, Gerätegruppen und Einschreibepakete sowie die wirksamen Portal-Einstellungen und ein erreichbarer Supportkontakt müssen zum geplanten Testpfad passen. Eine Lizenzaktivierung nur prüfen, soweit sie für den eingesetzten Produktumfang erforderlich ist; einen EAS-Proxy nur, wenn der vorgesehene E-Mail-Zugriff ihn nutzt. Beides ist keine allgemeine Voraussetzung für jeden SSP-Test. Ohne diese plattform- und pfadspezifische Prüfung einen fehlgeschlagenen Einschreibeversuch nicht allein als SSP-Berechtigungsfehler deuten.

Nach Save und Prioritätskorrektur in frischen Sitzungen mindestens zwei Gruppenzuordnungen prüfen: Eine Testperson in Mobile-SSP-Pilot (bei realistischen Überschneidungen zusätzlich in einer breiteren Gruppe) muss die beabsichtigte Konfiguration erhalten; eine Testperson ohne passende Gruppenzuordnung muss auf Default fallen. Für beide Konfigurationsname, nur vorgesehene Einschreibetypen und Aktionen, Texte und Gerätegrenze prüfen. Falls der Name nicht eindeutig sichtbar ist, Gruppenzuordnung und Prioritätsliste im Admin-Bereich abgleichen; eine Portalanzeige allein bestätigt keine tatsächliche Geräteberechtigung. Noch keine Aktion auslösen.

Vor Einladungen oder breiter Gruppenzuordnung den freigegebenen Registrierungsweg mit ausdrücklich autorisierten Testbenutzern, Tenant und Geräten tatsächlich durchlaufen. Für jede vorgesehene Plattform, den Besitzmodus und den App- beziehungsweise MDM-Weg das passende Enrollment package und die Ziel-Device group prüfen und den Ablauf mit der jeweiligen Testgruppe durchführen. Danach am gleichen Testgerät und seinem Datensatz in Sophos Mobile getrennt kontrollieren:

• Android – Intercept X for Mobile: Die abgeschlossene App-Registrierung, die Verbindung zu Sophos Mobile und die zugewiesene Android-MTD-Richtlinie prüfen. Das bestätigt keine MDM-Verwaltung des ganzen Geräts oder eines Arbeitsprofils.
• iPhone/iPad – Intercept X for Mobile: App-Registrierung, Verbindung zu Sophos Mobile und die zugewiesene iOS-MTD-Richtlinie prüfen; ein vorgesehenes Webfilterprofil gesondert abgleichen. Weder App-Registrierung noch Webfilterprofil belegen eine Apple-MDM-Einschreibung.
• Tatsächliche MDM-Einschreibung: Den vorher festgelegten Verwaltungs-/Profilmodus und den tatsächlichen Verwaltungszustand am Gerät und in Sophos Mobile bestätigen. Eine zusätzlich registrierte Schutz-App ersetzt diese Kontrolle nicht.
• Chrome-Security-SSP-Weg: Die installierte Erweiterung, ihre Registrierung per Token und die vorgesehene Sophos-Gerätegruppe und Chrome-Security-Richtlinie prüfen; weder Intercept-X-App-Status noch Android-MDM als Erfolgskriterium verwenden.

Die App-Kontrollen für Android und iPhone/iPad sind kein Nachweis wirksamen Schutzes; dessen Wirkung ist im jeweiligen Plattform-Policy-Pilot separat zu prüfen. Bei mehreren Zielgruppen deren Gruppenzuordnung ebenfalls testen. Ein bloss sichtbarer Portaleintrag reicht für keinen dieser Wege. Dieser Artikel dokumentiert keinen bereits durchgeführten Gerätetest. Weder Wipe noch Abmeldung, Sperre oder Lost Mode als Pilotaktion ausführen.

• Falsche Aktionen nach Save sichtbar: Rollout, Einladungen und weitere Gruppenzuordnungen sofort stoppen; keine Geräteaktion als Gegenprobe auslösen. Unter freigegebenem Änderungsverfahren die betroffene Konfiguration auf Self Service Portal configurations bearbeiten: Unter Actions > Show die Aktionsauswahl und unter User groups die Konfigurationszuordnung auf den dokumentierten, zuvor freigegebenen Stand zurücksetzen und auf Edit Self Service Portal configuration mit Save speichern; irrtümlich veränderte Mitgliedschaften betroffener Benutzergruppen nach demselben genehmigten Sollstand korrigieren. Anschliessend auf Self Service Portal configurations die Reihenfolge mit den Pfeilen für alle überlappenden Gruppen auf den freigegebenen Stand zurückstellen; Default als Auffangkonfiguration mit niedrigster Priorität mitprüfen, aber nicht ohne Folgenabschätzung für andere Benutzer breit ändern. In frischen Sitzungen erneut ein Pilotkonto mit Gruppenüberschneidung und ein Konto ohne passende Gruppenzuordnung auf sichtbare Aktionen und Einschreibetypen prüfen; bei weiterhin falscher Sichtbarkeit die Freigabe gesperrt lassen und an den zuständigen Tenant-Admin eskalieren. Klären, ob in der Zwischenzeit eine Aktion bereits ausgelöst wurde; dann Incident-/Datenschutzverantwortliche für gerätespezifische Wiederherstellung und weitere Massnahmen einschalten. Diese Korrektur begrenzt nur künftige Mobile-Berechtigungen; separat erteilter Portalzugriff und Berechtigungen für Sophos Email oder Device Encryption müssen von den zuständigen Verantwortlichen getrennt geprüft werden. Bereits ausgeführtes Wipe, Unenroll device und eine Standortoffenlegung lassen sich dadurch nicht rückgängig machen; nach der Abmeldung kann eine erneute Einschreibung nötig sein.
• Einschreibung fehlt oder schlägt fehl: Plattform, Owner, Ziel-Device group, Enrollment package und editionsspezifische Berechtigung prüfen. Ohne bestätigten Testpfad nicht im produktiven Benutzerkreis experimentieren.
• Portal nicht erreichbar: Zuerst die allgemeine SSP-Zugriffsvergabe getrennt von der Mobile-Konfiguration prüfen. Reset password und Reset App Protection password sind Geräte-/App-Aktionen, kein Reset des Fusion-/SSP-Anmeldekennworts. Anmeldemodus und Login-Kennwort gehören zum Fusion-Identitätsverantwortlichen: Bei ausschliesslich föderierter Anmeldung ist der Sophos-Kennwort-Reset nicht verfügbar; ein Wechsel der Anmeldeart ist keine Mobile-SSP-Korrektur und kann den Zugang produktübergreifend beeinflussen. Auch das Entfernen einer Admin-Rolle löscht die Person nicht und entzieht nicht nachweislich den Portalzugriff; diesen separat mit dem Fusion-Zugriffsverantwortlichen prüfen. Ein erfolgreicher Login beweist noch keine korrekte Mobile-Gruppenregel.

Für die Kommunikation an Benutzer gehören nur freigegebene, nach Plattform und Verwaltungstyp geprüfte Selbsthilfeaktionen in die Anleitung. Die Mobile-SSP-Benutzerübergabe behandelt Registrierung, Wiederherstellung, sichtbare Geräteschritte und Supportkontakt bei Verlust oder fehlgeschlagener Rekonfiguration samt Folgen für Verwaltung und Daten separat; die hier gezeigten Admin-Einstellungen und insbesondere destruktive Aktionen werden nicht als allgemeine Benutzerempfehlung weitergegeben. Die oben verlinkte allgemeine SSP-Zugriffsvergabe erklärt nur Anmeldung und Einladung.