Sophos Mobile: Windows-Passwortregeln und Sicherheitsrichtlinien sicher planen

Bei Windows-Policies in Sophos Mobile ist die wichtigste Entscheidung nicht die strengste Einstellung, sondern ein wiederherstellbarer Pilot: Edition und verwalteten Zustand bestätigen, BitLocker-Recovery vor einem möglichen Neustart prüfen, lokale Konten inventarisieren und erst dann genau eine Änderung an einem Testgerät zuweisen. Eine Windows-Policy ist nicht die Device-Encryption-Policy von Sophos Fusion und ersetzt keinen BitLocker-Recovery-Prozess. Für dessen Schlüsselverwaltung und Wiederherstellung siehe BitLocker mit Sophos Fusion verwalten.

Vor der ersten Zuweisung

1. Plattform und Geltungsbereich: Das Zielgerät muss tatsächlich als Windows-Computer über Sophos Mobile verwaltet sein; Sophos Endpoint Protection allein ist keine MDM-Registrierung. Die Sophos-Mobile-Anforderungsliste nennt Windows 10/11 Enterprise, Education und Pro, aber nicht Home; sie ist keine Zusage, dass jede einzelne Policy-Konfiguration auf jeder aufgeführten Edition oder Build wirkt. Restrictions gilt laut Sophos nicht für Pro, Device Guard weder für Pro noch für Windows im S-Modus. Edition, Windows-Version, Hardwarevoraussetzungen und wirksame GPO-/MDM-Vorgaben am konkreten Gerät prüfen; aus einer alten Hilfeseite folgt keine aktuelle Freigabe.
2. Lebenszyklus: Für die regulären Windows-10-Editionen endete der Microsoft-Support am 14. Oktober 2025; LTSC-/LTSB-Ausgaben und Geräte mit berechtigten, aktivierten Extended Security Updates (ESU) sind gesondert nach Edition und Version zu prüfen. ESU verlängert den Microsoft-Produktlebenszyklus oder den regulären Support nicht, sondern stellt für berechtigte und korrekt registrierte Geräte befristet Sicherheitsupdates bereit. Die Sophos-Mobile-Anforderungsliste (Release 2026.38 vom 21. September 2026) führt trotzdem Windows 10 Enterprise/Education/Pro ab 20H2 sowie Windows 11 Enterprise/Education/Pro auf. Das ist eine Sophos-Plattformliste, keine Microsoft-Supportzusage für ältere Windows-10-Builds und kein Funktionsnachweis für jede Windows-Policy. Auch Windows 11 ist versions- und editionsabhängig: Beispielsweise ist 23H2 Pro bereits ausserhalb des Microsoft-Updatesupports, während 23H2 Enterprise/Education noch eigene Fristen haben. Vor dem Pilot die konkrete Version im Microsoft-Release-Health-Lebenszyklus prüfen und die gewünschte Einstellung auf genau diesem Gerät testen.
3. Zugriff und Rückweg: Einen lokalen, autorisierten Wiederherstellungszugang, erreichbare Betreuung am Gerät und ein Änderungsfenster organisieren. Bei BitLocker den zum betroffenen Gerät und aktuellen Protector passenden Recovery Key im freigegebenen Verfahren abrufbar halten und die Verfügbarkeit vor der Änderung prüfen; einen bloss vorhandenen oder veralteten Eintrag nicht als getestete Wiederherstellung behandeln. Zuerst den tatsächlichen Verwalter und Ablageort des aktuellen BitLocker-Recovery-Keys für dieses Gerät ermitteln (beispielsweise Fusion Device Encryption oder eine andere autorisierte Schlüsselverwaltung). Sophos-Mobile-MDM allein belegt keinen in Fusion hinterlegten Key. Einen produktiven Fusion-Key nicht allein zur Bereitschaftskontrolle mit Show Key offenlegen. Bestehende Passwortvorgaben und GPOs dokumentieren. Für Device Guard zusätzlich den Ist-Zustand von VBS/Credential Guard sowie Secure Boot und DMA-Fähigkeit prüfen.
4. Kleine Pilotgruppe: Nicht zuerst eine breite Gerätegruppe zuweisen. Ausgangszustand, betroffene Benutzer und die erwartete sichtbare Änderung dokumentieren. Für eine Windows-Policy gibt es laut Sophos keinen allgemeinen Uninstall policy-Rückweg; Einstellungen werden durch Aktualisierung oder Zuweisung einer anderen Policy korrigiert. Eine abgemeldete oder nicht synchronisierende Maschine erhält eine solche Korrektur nicht zuverlässig sofort.

Passwortregeln: Neustart und gesperrte Konten vermeiden

Die Konfiguration Password policies steuert Maximum number of failed attempts, Time in minutes until the device is locked, Password history und Maximum password age in days.

Time in minutes until the device is locked legt fest, nach wie vielen Minuten ohne Nutzung das Gerät gesperrt wird. Der Benutzer kann es selbst wieder entsperren. Diese Inaktivitätssperre ist nicht die Fehlversuchsschwelle, die einen Neustart mit BitLocker-Recovery-Abfrage auslösen kann. Maximum password age in days legt fest, nach wie vielen Tagen Benutzer ihr Passwort ändern müssen.

Password history ist die Anzahl früher verwendeter Passwörter, die Sophos Mobile für die Wiederverwendungssperre speichert; ein neues Passwort darf keinem dieser Werte entsprechen. Sophos erlaubt bei Fehlversuchen, Sperrzeit und maximalem Passwortalter den Wert 0 für keine entsprechende Einschränkung. Das ist keine Empfehlung, alle Schutzvorgaben auszuschalten: Man wählt die Werte passend zu Kontenmodell und Wiederherstellbarkeit und testet sie separat. Die Passwortkomplexität (etwa Länge oder Zeichenklassen) lässt sich mit dieser Mobile-Policy nicht einstellen; sie kommt von Windows und hängt unter anderem vom Kontotyp ab. Historisch dokumentierte konkrete Komplexitätszahlen nicht als universell gültigen heutigen Windows-Default übernehmen.

Ist für das betroffene Konto eine entsprechende Windows-Komplexitätsrichtlinie aktiviert und wirksam, können beim Erstellen oder Ändern des Passworts auch Prüfungen gegen den Kontonamen und Bestandteile des vollständigen Namens beziehungsweise Anzeigenamens greifen. Ob und wie diese Namensprüfungen gelten, hängt von der wirksamen Richtlinie und dem Kontotyp ab; dies vor dem Pilot für die betroffenen Konten klären. Daraus folgt weder eine universelle Regel für beliebige aufeinanderfolgende Namenszeichen noch ein Nachweis der heutigen Anforderungen an Microsoft-Konten.

Vor dem Aktivieren von „Maximum number of failed attempts“: Für Windows-Computer beschreibt Sophos bei Erreichen der Schwelle einen Neustart mit BitLocker-Recovery-Abfrage. Microsoft präzisiert für die entsprechende Windows-MDM-Regel: Auf einem Desktop wird dabei nicht gelöscht, sondern BitLocker-Recovery ausgelöst; ohne aktiviertes BitLocker ist die Regel nicht durchsetzbar. Eine gesetzte Fehlversuchsschwelle deshalb weder als Datenlöschung noch als wirksamen Schutz auf einem unverschlüsselten Gerät behandeln. BitLocker-Status und tatsächlich hinterlegten Recovery-Zugang vor der Zuweisung am konkreten Gerät prüfen; Fehlversuche nicht absichtlich auf produktiv genutzten Geräten provozieren. Wenn zusätzlich zum bei Sophos Mobile registrierten Benutzer weitere lokale Benutzer vorhanden sind und mindestens einer davon sein Passwort nicht ändern darf, kann diese Password-Policy laut Sophos nicht zugewiesen werden. Die Kontenberechtigungen erst in einem separaten, genehmigten Schritt prüfen und korrigieren; nicht blind Benutzerrechte erweitern oder Konten löschen, um die Policy durchzusetzen.

Für den Pilot zunächst Konten und vorhandene Richtlinien erfassen, Inaktivitätsdauer und Passwortalter passend zum Arbeitsablauf festlegen und vor einer Fehlversuchsschwelle die Recovery-Bereitschaft bestätigen. Nach der Zuweisung nur lesend prüfen, welche Policy dem Gerät zugeordnet ist und ob die gewählte Inaktivitätsdauer und das maximale Passwortalter wirksam werden. Ein Test der Fehlversuchsschwelle gehört ausschliesslich in eine freigegebene isolierte Testumgebung mit erreichbarem Recovery Key. Bei überraschender BitLocker-Abfrage nicht erneut versuchen oder andere Schlüssel raten: Geräte- und Key-ID zuordnen und den autorisierten Recovery-Prozess der tatsächlich zuständigen Schlüsselverwaltung verwenden; nur falls Sophos Device Encryption den aktuellen Key verwahrt, gilt der Fusion-Recovery-Ablauf.

Restrictions: Folgen jeder Checkbox vorab klären

Restrictions ist keine allgemeine Pro-Härtung: Sophos schliesst Windows Pro ausdrücklich aus. Die Konfiguration enthält unter anderem Forbid resetting the computer (unterbindet das Zurücksetzen über Einstellungen und Windows RE), Disable VPN settings, Disable Account settings, Forbid Bluetooth, Telemetry level und Forbid manual MDM unenrollment. Gerade ein gesperrter Reset oder eine gesperrte MDM-Abmeldung kann einen geplanten Support-/Offboarding-Ablauf blockieren. Nur eine begründete Einstellung pro Pilotänderung wählen und ihre Funktion vor und nach der Zuweisung am Gerät überprüfen.

Forbid manual configuration im Abschnitt Wi-Fi ist ein besonderer Risikofall: Bereits vom Benutzer konfigurierte sowie Wi-Fi-Sense-Profile werden beim Anwenden gelöscht. Das Zurücksetzen der Checkbox erstellt gelöschte Profile nicht automatisch wieder. Vor diesem Eingriff einen anderen getesteten Management- und Netzwerkzugang sowie einen dokumentierten Weg zum Wiederherstellen benötigter WLAN-Profile sicherstellen. WLAN-Profile, Zertifikate und SCEP gehören in den getrennten Windows-Netzwerk-/Zertifikatsablauf; ohne diesen Nachweis hier keine WLAN-Sperre aktivieren.

Telemetry level bezeichnet in Sophos’ Liste die Stufen Full, Enhanced, Basic und Security. Ihre tatsächliche Windows-Wirkung und Zulässigkeit hängen von der aktuellen Edition und Microsoft-Richtlinie ab; die Sophos-Liste ist kein Nachweis, dass jede Stufe auf jedem Pilotgerät funktioniert. Ebenso sind historische UI-Begriffe wie Cortana oder Wi-Fi Sense kein Beleg für eine Wirkung auf aktuellen Windows-Versionen.

Device Guard: zuerst einen reversiblen Weg wählen

Sophos’ Device Guard-Konfiguration kann virtualisierungsbasierte Sicherheit (VBS) und Credential Guard aktivieren. Turn on virtualization-based security (VBS) ist das eigene Feld zum Einschalten von VBS; die Auswahl unter Credential Guard configuration ist davon getrennt. Die Einstellungen werden laut Sophos beim ersten Start des Windows-Computers nach Policy-Zuweisung angewendet. Vor der Zuweisung Hardware und bestehende GPO-/MDM-Vorgaben prüfen und einen kontrollierten Neustart einplanen.

Unter Platform security level unterscheidet Sophos zwei Optionen:

• Secure Boot nutzt die vom Gerät unterstützten Schutzfunktionen. Ohne Input/Output Memory Management Units (IOMMUs) verwendet VBS die Secure-Boot-Funktion von UEFI; mit IOMMUs verwendet VBS Secure Boot mit Schutz vor direkten Speicherzugriffen (DMA).
• Secure Boot and DMA protection verlangt Secure Boot mit DMA-Schutz. Unterstützt das Gerät DMA-Schutz nicht, wird VBS mit dieser Auswahl nicht aktiviert.

Credential-Guard-Preflight vor der Zuweisung: Nur falls Credential Guard auf dem Pilotgerät aktiviert werden soll, die tatsächlich genutzten Anmelde- und Zugriffspfade im konkreten Tenant erfassen: WLAN oder kabelgebundenes 802.1X, VPN (insbesondere PEAP-/EAP-MSCHAPv2), NTLMv1-SSO, RDP/Fernsupport mit gespeicherten Windows-Anmeldedaten oder CredSSP sowie Anwendungen mit uneingeschränkter Kerberos-Delegierung. Microsoft dokumentiert die Authentifizierungsfolgen: Bei MS-CHAP und NTLMv1 kann SSO entfallen und eine erneute manuelle Anmeldung nötig werden; diese Protokolle sind dadurch nicht pauschal vollständig gesperrt. Zertifikatsbasierte WLAN-/VPN-Authentifizierung wird dadurch nicht blockiert. Der Remotedesktop-Client kann gespeicherte Windows-Anmeldedaten nicht an den Zielhost weitergeben; CredSSP kann gespeicherte oder SSO-Anmeldedaten nicht mehr verwenden, während ausdrücklich eingegebene Anmeldedaten möglich bleiben. Uneingeschränkte Kerberos-Delegierung ist dagegen blockiert. Zusätzliche Abhängigkeiten nur prüfen, wenn sie im Pilot tatsächlich vorkommen: Mit den zuständigen Identitäts- und Anwendungsverantwortlichen klären, ob Kerberos-PKINIT mit RSA statt Diffie-Hellman oder Kerberos-DES benötigt wird: PKINIT mit RSA und DES werden durch Credential Guard blockiert; eine erneute Passworteingabe behebt diese Fälle nicht. Ebenso eingesetzte eigene oder nicht von Microsoft stammende Security Support Provider/Authentication Packages (SSP/AP) und Anwendungen erfassen, die gespeicherte Windows-Anmeldedaten auslesen: Solche Integrationen können ausfallen, insbesondere wenn sie LSA-Passworthashes oder nicht unterstützte Schnittstellen benötigen. Für tatsächlich betroffene Pfade vor der Zuweisung eine kompatible Alternative und einen repräsentativen Funktionstest vereinbaren; wenn ein kritischer Pfad ungeklärt bleibt, Credential Guard nicht zuweisen. Nur die für das gewählte Gerät tatsächlich relevanten Wege mit zuständigen Identitäts-/Netzwerkverantwortlichen bewerten; vor dem Neustart einen unabhängig getesteten Management- oder lokalen Konsolenzugang und einen freigegebenen Rückweg ohne UEFI-Sperre bereithalten. Wenn die reguläre Netzwerk- oder Fernsupportverbindung die einzige Zugriffsmöglichkeit ist, Credential Guard noch nicht zuweisen.

Für einen Pilot mit erforderlicher Fern-Rücknahme ist Credential Guard configuration: Turn on without lock die relevante Wahl: Sophos beschreibt hier Turn off oder eine Windows-Gruppenrichtlinie als Rückweg. Turn on with UEFI lock darf nicht als reversibler Fernschalter geplant werden. Sophos verweist für die Abschaltung auf physische Präsenz am Rechner; Microsoft dokumentiert dafür einen eigenen EFI-/Startvorgang mit Bestätigung vor dem Boot. Ohne ausdrücklich vorbereiteten lokalen Rückweg diesen Modus nicht aktivieren. Turn off hilft nicht gegen eine bereits gesetzte UEFI-Sperre. Auch ohne UEFI-Sperre können andere Managementvorgaben die Änderung übersteuern oder Windows kann Credential Guard bereits standardmässig aktivieren.

Den Ist- und Zielzustand am Testgerät unter System Information (msinfo32.exe) bei Virtualization-based Security Services Running vergleichen: Dort muss Credential Guard als laufend erscheinen, wenn seine Aktivierung das Pilotziel war. Ein erfolgreicher Policy-Task allein beweist die tatsächliche Ausführung nicht. Nach dem Neustart auf dem repräsentativen Pilotgerät mit einem autorisierten Testkonto die zuvor erfassten, tatsächlich genutzten Anmeldungen und Verbindungen (insbesondere 802.1X/WLAN, VPN, RDP/Fernsupport und betroffene SSO-/Delegierungsanwendungen; sofern vorhanden auch PKINIT-RSA-/DES- und SSP/AP-Integrationen sowie Anwendungen, die gespeicherte Windows-Anmeldedaten auslesen) sowie den unabhängigen Rückweg prüfen; nicht vom laufenden Credential Guard auf funktionierende Netzwerk- und Supportpfade schliessen. Bei Abweichung zuerst Edition, Secure Boot/DMA, andere Richtlinien und Neustartstatus prüfen; nicht durch Umschalten der UEFI-Sperre experimentieren. Rücknahme bei without lock über die vorbereitete Windows-Policy oder zuständige GPO planen, Gerät synchronisieren und nach Neustart den Zustand erneut prüfen. Bei with UEFI lock stoppen und den freigegebenen lokalen Microsoft-Wiederherstellungsprozess mit physischem Zugriff verwenden.

E-Mail-Konfigurationen nicht blind ausrollen

Die Mobile-Hilfe führt Email account für Exchange Online/Server und IMAP/POP als Windows-Konfigurationen. Für Platzhalter wie %_EMAILADDRESS_% und %_USERNAME_% müssen beim zugewiesenen Benutzer in Sophos Fusion die Felder Exchange Login und Email Address gepflegt sein. Bei mehreren Exchange-Konten mit unterschiedlichen Mailbox-Policies kann Windows laut Sophos nur eine Richtlinie durchsetzen; zudem kann der Benutzer Änderungen an der Exchange-Konfiguration ablehnen. Passwortfelder in einem Policy-Entwurf sind kein Ersatz für ein freigegebenes Identitäts- und Geheimnisverfahren.

Wichtiger Aktualitätskonflikt: Sophos beschreibt die Exchange-E-Mail-Konfiguration ausdrücklich für Microsofts Mail-App; Microsoft hat den Support für Windows Mail/Calendar/People am 31. Dezember 2024 beendet und erklärt, dass darüber keine E-Mails oder Ereignisse mehr gesendet und empfangen werden können. Die Sophos-Seite zu IMAP/POP nennt keinen aktuell unterstützten Zielclient; eine Übernahme dieser Konfiguration in das neue Outlook ist ebenfalls nicht nachgewiesen. Deshalb hier keine Schrittfolge für die Produktivbereitstellung dieser Mail-App oder eine angenommene automatische Übernahme in das neue Outlook. Zuerst Zielclient, Authentifizierung, Mailbox-Policy und aktuelle Unterstützung im konkreten Tenant klären und separat testen.

Rollout, Kontrolle und Rücknahme

Nach den Vorprüfungen in Sophos Mobile unter Policies > Windows eine neue, ausschliesslich für den Pilot vorgesehene Policy erstellen. Vor jeder Bearbeitung einer bestehenden Policy zuerst alle zugewiesenen Geräte und Gruppen kontrollieren: Änderungen an einer bereits zugewiesenen Windows-Policy werden bei deren nächster Verbindung automatisch synchronisiert und sind kein Einzelgeräte-Test. Per Add configuration nur die geprüfte Konfiguration hinzufügen, speichern und über Assign ausschliesslich das gewählte Pilotgerät auswählen. Bei Windows-Policies steht die im Sophos-Dialog beschriebene Schedule task-Seite für Android-, Knox- und iOS-Policies zur Verfügung, nicht für Windows; eine zeitversetzte Windows-Zuweisung hier nicht versprechen. Der Test beginnt also erst, wenn der vorgesehene Betreuer bereit ist.

Nach der Zuweisung die Policies-Ansicht des betroffenen Geräts, Aufgabenstatus und tatsächliches Verhalten am Gerät vergleichen. Windows-Policies werden bei Geräteverbindung automatisch synchronisiert; eine UI-Anzeige ist allein kein Nachweis für die lokale Wirkung. Bei unerwarteter Änderung keinen zweiten sicherheitsrelevanten Schalter aktivieren: Gerät erreichbar halten, nur die dem Pilotgerät vorbehaltene Policy kontrolliert korrigieren oder eine geprüfte Ersatz-Policy zuweisen, Synchronisation und erforderlichen Neustart abwarten und erneut lokal prüfen. Vor Änderungen an einer zusätzlich zugewiesenen gemeinsamen Policy deren Geräte- und Gruppenzuweisungen prüfen. Bereits entfernte WLAN-Profile, eine UEFI-Sperre oder ein ausgelöster BitLocker-Recovery-Prompt werden dadurch nicht automatisch rückgängig gemacht.

Abgrenzung: Root-/Client-Zertifikate, SCEP und WLAN-Profile sind ein eigenständiger Windows-Netzwerk-/Zertifikatsprozess. BitLocker-Protectoren und Recovery-Key-Verwaltung gehören zu Device Encryption. Kiosk-Modus und Windows-Registrierung haben jeweils eigene Voraussetzungen und Rückwege; keine dieser Aufgaben ist mit der hier geprüften Sicherheits-Policy automatisch erledigt.