Sophos Mobile: Plan Windows password rules and security policies safely

For Windows policies in Sophos Mobile, the most important decision is not to choose the strictest setting but to run a recoverable pilot: confirm the edition and managed state, check BitLocker recovery before a possible restart, inventory local accounts, and only then assign exactly one change to a test device. A Windows policy is not the Sophos Fusion Device Encryption policy and does not replace a BitLocker recovery process. For key management and recovery, see Manage BitLocker with Sophos Fusion.

Before the first assignment

1. Platform and scope: The target device must actually be managed as a Windows computer through Sophos Mobile; Sophos Endpoint Protection alone is not MDM enrollment. The Sophos Mobile requirements list names Windows 10/11 Enterprise, Education, and Pro, but not Home; it does not guarantee that every individual policy configuration works on every listed edition or build. According to Sophos, Restrictions does not apply to Pro, and Device Guard applies neither to Pro nor to Windows in S mode. Check the edition, Windows version, hardware requirements, and effective GPO/MDM settings on the actual device; an old help page does not constitute current approval.
2. Support lifecycle: Microsoft’s support for the standard Windows 10 editions ended on October 14, 2025; LTSC/LTSB editions and devices with eligible, activated Extended Security Updates (ESU) must be assessed separately by edition and version. ESU does not extend the Microsoft product lifecycle or standard support; it provides security updates for a limited period to eligible, correctly enrolled devices. The Sophos Mobile requirements list (release 2026.38 of September 21, 2026) nevertheless includes Windows 10 Enterprise/Education/Pro from 20H2 onward and Windows 11 Enterprise/Education/Pro. This is a Sophos platform list, not a Microsoft support commitment for older Windows 10 builds and not proof that every Windows policy feature works. Windows 11 support also depends on version and edition: for example, 23H2 Pro is already outside Microsoft’s update support, while 23H2 Enterprise/Education have their own deadlines. Before the pilot, check the exact version against Microsoft’s release health lifecycle and test the desired setting on that specific device.
3. Access and recovery path: Arrange authorized local recovery access, someone available at the device, and a change window. For BitLocker, keep the recovery key matching the affected device and current protector retrievable through the approved procedure and verify availability before the change; do not treat a merely existing or outdated entry as tested recovery. First determine who actually manages the current BitLocker recovery key for this device and where it is stored (for example, Fusion Device Encryption or another authorized key-management system). Sophos Mobile MDM alone does not establish that the key is stored in Fusion. Do not expose a production Fusion key with Show Key merely to check readiness. Document existing password settings and GPOs. For Device Guard, also check the current VBS/Credential Guard state and Secure Boot and DMA capabilities.
4. Small pilot group: Do not assign a broad device group first. Document the starting state, affected users, and expected visible change. According to Sophos, there is no general Uninstall policy recovery path for a Windows policy; settings are corrected by updating the policy or assigning a different one. A device that is offline or not syncing will not reliably receive such a correction immediately.

Password rules: avoid restarts and locked accounts

The Password policies configuration controls Maximum number of failed attempts, Time in minutes until the device is locked, Password history, and Maximum password age in days.

Time in minutes until the device is locked specifies how many minutes of inactivity elapse before the device locks. The user can unlock it themselves. This inactivity lock is not the failed-attempt threshold that can trigger a restart and BitLocker recovery prompt. Maximum password age in days specifies how many days elapse before users must change their password.

Password history is the number of previously used passwords that Sophos Mobile stores to prevent reuse; a new password must not match any of them. Sophos allows 0 for no corresponding restriction on failed attempts, lock time, and maximum password age. This is not a recommendation to disable all protections: choose values appropriate to the account model and recoverability, and test them separately. Password complexity (such as length or character classes) cannot be set with this Mobile policy; it is determined by Windows and depends, among other things, on the account type. Do not treat historically documented specific complexity figures as universal current Windows defaults.

If an appropriate Windows password complexity policy is enabled and effective for the affected account, checks against the account name and parts of the full name or display name may also apply when a password is created or changed. Whether and how these name checks apply depends on the effective policy and account type; clarify this for the affected accounts before the pilot. This establishes neither a universal rule for arbitrary consecutive characters from a name nor the current requirements for Microsoft accounts.

Before enabling “Maximum number of failed attempts”: Sophos describes a restart and BitLocker recovery prompt when a Windows computer reaches the threshold. Microsoft clarifies that the corresponding Windows MDM rule does not wipe a desktop; instead, it triggers BitLocker recovery, and the rule cannot be enforced without BitLocker enabled. Therefore, do not interpret a configured failed-attempt threshold either as data erasure or as effective protection on an unencrypted device. Check BitLocker status and actual access to the stored recovery key on the specific device before assignment; do not deliberately trigger failed attempts on production devices. If there are additional local users besides the user enrolled in Sophos Mobile and at least one of them is not allowed to change their password, Sophos says this password policy cannot be assigned. Review and correct account permissions only in a separate, approved step; do not blindly expand user rights or delete accounts to enforce the policy.

For the pilot, first record accounts and existing policies, choose an inactivity timeout and password age appropriate to the workflow, and confirm recovery readiness before setting a failed-attempt threshold. After assignment, check read-only which policy is assigned to the device and whether the selected inactivity timeout and maximum password age take effect. Testing the failed-attempt threshold belongs only in an approved, isolated test environment with an accessible recovery key. If a BitLocker prompt appears unexpectedly, do not retry or guess other keys: match the device and key IDs and use the authorized recovery process of the key-management system actually responsible; only if Sophos Device Encryption holds the current key does the Fusion recovery procedure apply.

Restrictions: assess the consequences of every checkbox first

Restrictions is not general-purpose hardening for Pro: Sophos explicitly excludes Windows Pro. The configuration includes Forbid resetting the computer (prevents reset through both Settings and Windows RE), Disable VPN settings, Disable Account settings, Forbid Bluetooth, Telemetry level, and Forbid manual MDM unenrollment, among others. Blocking reset or MDM unenrollment can obstruct a planned support or offboarding process. Select only one justified setting per pilot change and verify its effect on the device before and after assignment.

Forbid manual configuration in the Wi-Fi section is a particular risk: existing user-configured and Wi-Fi Sense profiles are deleted when it is applied. Clearing the checkbox does not automatically recreate deleted profiles. Before taking this step, ensure another tested management and network access path and a documented way to restore required Wi-Fi profiles. Wi-Fi profiles, certificates, and SCEP belong to the separate Windows network/certificate process; do not enable a Wi-Fi restriction here without that assurance.

Telemetry level in Sophos’s list names Full, Enhanced, Basic, and Security. Their actual effect and permissibility in Windows depend on the current edition and Microsoft policy; Sophos’s list is not evidence that every level works on every pilot device. Likewise, historical UI terms such as Cortana or Wi-Fi Sense do not establish an effect on current Windows versions.

Device Guard: choose a reversible path first

Sophos’s Device Guard configuration can enable virtualization-based security (VBS) and Credential Guard. Turn on virtualization-based security (VBS) is the separate field for enabling VBS; the selection under Credential Guard configuration is distinct from it. According to Sophos, the settings are applied at the Windows computer’s first startup after policy assignment. Check hardware and existing GPO/MDM settings before assignment and schedule a controlled restart.

Under Platform security level, Sophos distinguishes two options:

• Secure Boot uses the protections supported by the device. Without Input/Output Memory Management Units (IOMMUs), VBS uses UEFI’s Secure Boot functionality; with IOMMUs, VBS uses Secure Boot with direct memory access (DMA) protection.
• Secure Boot and DMA protection requires Secure Boot with DMA protection. If the device does not support DMA protection, VBS is not enabled with this selection.

Credential Guard preflight before assignment: Only if Credential Guard is to be enabled on the pilot device, identify the sign-in and access paths actually used in the specific tenant: Wi-Fi or wired 802.1X, VPN (especially PEAP/EAP-MSCHAPv2), NTLMv1 SSO, RDP/remote support using saved Windows credentials or CredSSP, and applications using unconstrained Kerberos delegation. Microsoft documents the authentication implications: MS-CHAP and NTLMv1 may lose SSO and require another manual sign-in; these protocols are not categorically blocked in their entirety. Certificate-based Wi-Fi/VPN authentication is not blocked by this. The Remote Desktop client cannot pass saved Windows credentials to the destination host; CredSSP can no longer use saved or SSO credentials, although explicitly entered credentials remain possible. Unconstrained Kerberos delegation, by contrast, is blocked. Check additional dependencies only if they actually occur in the pilot: Clarify with the responsible identity and application owners whether Kerberos PKINIT with RSA rather than Diffie-Hellman, or Kerberos DES, is needed: PKINIT with RSA and DES are blocked by Credential Guard, and re-entering a password does not resolve these cases. Also identify any custom or non-Microsoft Security Support Providers/Authentication Packages (SSP/AP) in use and applications that read saved Windows credentials: such integrations can fail, particularly if they require LSA password hashes or unsupported interfaces. For paths actually affected, agree on a compatible alternative and a representative functional test before assignment; if a critical path remains unresolved, do not assign Credential Guard. Evaluate only the paths actually relevant to the chosen device with the responsible identity/network owners; before restarting, have an independently tested management or local console access path and an approved recovery path without UEFI lock ready. If the normal network or remote-support connection is the only access path, do not assign Credential Guard yet.

For a pilot that requires remote rollback, Credential Guard configuration: Turn on without lock is the relevant choice: Sophos describes Turn off or a Windows Group Policy as the recovery path. Turn on with UEFI lock must not be planned as a reversible remote switch. Sophos refers to physical presence at the computer for disabling it; Microsoft documents a separate EFI/startup process requiring confirmation before boot. Do not enable this mode without an explicitly prepared local recovery path. Turn off will not remove a UEFI lock already set. Even without a UEFI lock, other management settings can override the change, or Windows may already enable Credential Guard by default.

Compare the current and target states on the test device in System Information (msinfo32.exe) under Virtualization-based Security Services Running: Credential Guard must appear as running there if enabling it was the pilot goal. A successful policy task alone does not prove that it is actually running. After the restart, use an authorized test account on the representative pilot device to test the previously recorded sign-ins and connections actually in use (especially 802.1X/Wi-Fi, VPN, RDP/remote support, and affected SSO/delegation applications; where present, also PKINIT-RSA/DES and SSP/AP integrations and applications that read saved Windows credentials), as well as the independent recovery path; do not infer working network and support paths merely because Credential Guard is running. If results differ, first check the edition, Secure Boot/DMA, other policies, and restart status; do not experiment by toggling the UEFI lock. For without lock, plan rollback through the prepared Windows policy or responsible GPO, sync the device, and check the state again after a restart. For with UEFI lock, stop and use the approved local Microsoft recovery procedure with physical access.

Do not deploy email configurations blindly

The Mobile help lists Email account for Exchange Online/Server and IMAP/POP as Windows configurations. For placeholders such as %_EMAILADDRESS_% and %_USERNAME_%, the assigned user’s Exchange Login and Email Address fields must be populated in Sophos Fusion. Where multiple Exchange accounts have different mailbox policies, Sophos says Windows can enforce only one policy; the user may also reject changes to the Exchange configuration. Password fields in a draft policy are no substitute for an approved identity and secrets-management procedure.

Important currency conflict: Sophos explicitly describes the Exchange email configuration for Microsoft’s Mail app; Microsoft ended support for Windows Mail/Calendar/People on December 31, 2024, and states that they can no longer send or receive emails or events. The Sophos page for IMAP/POP does not identify a currently supported target client; migration of this configuration into the new Outlook is likewise unproven. Therefore, this article gives no production deployment steps for that Mail app or an assumed automatic migration to the new Outlook. First clarify the target client, authentication, mailbox policy, and current support in the specific tenant, and test separately.

Rollout, verification, and rollback

After the prechecks, create a new policy exclusively for the pilot in Sophos Mobile under Policies > Windows. Before editing an existing policy, first check every assigned device and group: changes to an already assigned Windows policy sync automatically on the devices’ next connection and are not a single-device test. Use Add configuration to add only the verified configuration, save, and use Assign to select only the chosen pilot device. For Windows policies, the Schedule task page described in the Sophos dialog is available for Android, Knox, and iOS policies, not Windows; do not promise delayed Windows assignment here. The test should therefore start only when the designated support person is ready.

After assignment, compare the affected device’s Policies view, task status, and actual behavior on the device. Windows policies sync automatically when the device connects; a UI display alone does not prove the local effect. If a change is unexpected, do not enable a second security-sensitive switch: keep the device accessible, carefully correct only the policy reserved for the pilot device or assign a verified replacement policy, wait for synchronization and any required restart, and check locally again. Before changing another assigned shared policy, check its device and group assignments. Wi-Fi profiles already removed, a UEFI lock, or a triggered BitLocker recovery prompt are not automatically reversed by this.

Scope: Root/client certificates, SCEP, and Wi-Fi profiles are a separate Windows network/certificate process. BitLocker protectors and recovery-key management belong to Device Encryption. Kiosk mode and Windows enrollment each have their own prerequisites and recovery paths; none of these tasks is automatically completed by the security policy examined here.