Sophos Mobile: assessing and preparing Windows kiosk mode safely

In brief: The Sophos Mobile Kiosk mode configuration binds a Windows user account to a UWP app via its App AUMID. It is not general guidance for arbitrary Win32 applications, Microsoft Edge or a multi-app kiosk. This draft describes the documented policy procedure; a working combination of Sophos Mobile version, Windows edition and app has not been tested on a device here.

Before the first pilot device

First check whether Windows device management and the Kiosk mode configuration are actually available in your tenant. Sophos documents Device as the Windows management mode. The current Sophos Mobile release notes (version 2026.38, published on 21 September 2026) list Windows 11 Pro, Education and Enterprise and Windows 10 Pro, Education and Enterprise from 20H2 onwards for the native MDM client. This does not mean that Windows 10 is still supported by Microsoft or that the kiosk configuration works with every app and build. Microsoft lists Pro, Education, Enterprise/Enterprise LTSC and IoT Enterprise/IoT Enterprise LTSC as Assigned Access editions; Home is not included. Standard support for Windows 10 version 22H2 ended on 14 October 2025. Windows 10 LTSC has its own support periods; eligibility for ESU must be checked separately.

Check administrator permissions before following the policy procedure: Before Create, any policy change or Assign in your tenant, make sure an authorised person with the Sophos Fusion role Super Admin or Admin is performing the action; Sophos Mobile maps both roles to Administrator. Help Desk maps to Helpdesk and cannot create or edit policies; Read-only has read access only. If the required permissions are missing, do not start or continue the policy procedure; involve the responsible Mobile administrators.

Record the following before the pilot:

Device and licence: Choose an already managed test device with a suitable Windows edition that is still supported. Check that the tenant has an entitlement to Sophos Mobile Device Management or Sophos Mobile (including MDM); Mobile Threat Defense alone does not entitle you to the device management required here. This still does not establish that a usable kiosk configuration is available. Windows User Account Control (UAC) must be enabled for Assigned Access. Do not start with a production till or an unattended terminal.
Account: Choose an existing non-administrative kiosk account; for a publicly accessible device, Microsoft recommends a local account rather than a domain or Entra account with access to confidential company data. Sophos requires the account to already exist on the device when the policy is assigned. For User account, Sophos specifies these formats: local <computer name>\<username>, .\<username> or <username>; domain <domain>\<username>; Microsoft Entra AzureAD\<email>. The angle-bracketed terms are placeholders and must not be entered literally; use the actual values for the verified account. .\kiosk-pilot is only a local example, and kiosk-pilot is not a universal account name. An Entra email address and a local username are not interchangeable.
Optional restart sign-in check before assignment: If the kiosk should not resume automatically after a restart, sign in with the intended kiosk account before assigning Kiosk mode, while Windows settings are still freely accessible. Under Settings > Accounts > Sign-in options, turn off the option Sophos calls Use my sign-in info to automatically finish setting up my device after an update or restart, if it is present and can be changed on the device; its wording may differ. Microsoft requires this step before configuring the kiosk for its single-app kiosk through Windows settings on devices not joined to a domain or Entra; that does not establish the same effect or sequence for Sophos MDM. For domain- or Entra-joined devices, or if the option is missing, differently named or locked by policy, clarify the procedure on the actual device and do not assign the pilot until then. This setting does not remove a Sophos MDM policy or replace an independent administrative route back.
App: Install or provision a suitable UWP app for the kiosk account and check in advance that it starts under that exact account. Then determine its AUMID on that device. In Windows PowerShell, Get-StartApps displays the names and AUMIDs of apps listed in the Start menu; its output alone does not prove that the app is installed and usable for the kiosk account. If the app is absent from that list, the list is not proof that the app is unavailable; for Store apps, Microsoft describes finding the AUMID using Get-AppxPackage together with Get-AppxPackageManifest. Without a user parameter, Get-AppxPackage only covers apps belonging to the current user; for other accounts, -User requires an elevated Windows PowerShell session. An AUMID entry alone does not prove that an app is suitable as a UWP kiosk app: check whether it can run above the lock screen and whether its core workflow needs to launch other apps (blocked in a single-app kiosk). Also check file selection, sign-in and access to confidential files under the kiosk account. Recheck the AUMID after app updates: it may change. According to Sophos, a Win32 app installed from an .msi cannot be used in this field. Microsoft’s broader Assigned Access support for Edge must not be assumed to apply to the Sophos interface.
Route back: Before distributing the policy, establish physical access, sign-in with a separate administrator account, network connectivity for synchronisation and a prepared alternative Windows policy without the kiosk configuration. Check Forbid manual MDM unenrollment and Forbid resetting the computer in the effective Windows policy: where the Sophos Restrictions configuration applies, the latter can block a reset both through Windows settings and through Windows RE. According to Sophos, this configuration does not apply to Windows Pro; do not assume its effects are the same across all editions. Do not try to bypass such restrictions simply by deleting the device record; do not plan a factory reset as a guaranteed route back when reset is blocked. Instead, require a separately authorised, physically verified recovery plan. On the pilot device, also account for a possible automatic return to the kiosk from the sign-in screen; the Microsoft exit sequence has not been confirmed as a Sophos route back. According to Sophos, a restart alone does not disable kiosk mode by default. Any BitLocker recovery key that might be needed must be accessible to authorised administrators; this article does not change BitLocker settings.

For the distinction between MDM and MTD entitlements, see Choosing and using Sophos Mobile licences. If the Windows device is already enrolled in Sophos Mobile, Windows Wi-Fi and certificates with Sophos Mobile covers the separate network and certificate path for management connectivity. These links replace neither Windows kiosk enrolment nor kiosk-specific policy assignment, offboarding or a route back tested on the device. If there is no verified procedure for these in your own tenant, do not assign the policy; involve the responsible Mobile administrators.

Documented policy procedure for a limited pilot

Under Policies > Windows, click Create, select the policy type and enter a name and description on the Edit policy page. Use Add configuration to add Kiosk mode, then click its name to edit the settings.
In User account, enter the verified existing account; in App AUMID, enter the identifier of the suitable UWP app found on the pilot device. The account name and identifier are not universal example values. Save the policy with Save.
Before Assign, check the target device, its previously assigned Windows policy and all assignments of the policy you are about to edit again. Use a separate pilot policy; do not alter a policy already assigned to other devices for this pilot, because the change may affect those devices too. Select only one pilot device, not an entire device group: blue triangle next to the pilot policy > Assign > target device > Finish. The Sophos Schedule task dialogue is not displayed for Windows policies.
After assignment, wait for device synchronisation and check on the device whether the policy has arrived; successful assignment in the Sophos console alone does not establish an effect on the device, nor does it guarantee a specific delivery time. Sign out any kiosk-account session that was already active; check the app only at that account’s next sign-in locally at the device console. According to Microsoft, Assigned Access takes effect for the targeted user at their next sign-in; a session already active before assignment is not a meaningful functional test. Testing through Remote Desktop is not sufficient. The selected app is expected to start for that account. Also check app functionality, network requirements and sign-in again after a restart; if the result differs, first compare the account, actual AUMID, app installation and device synchronisation. If the app still does not start, the local Windows event log Applications and Services Logs > Microsoft > Windows > AssignedAccess > Operational (enable it if necessary) may help with troubleshooting; it neither proves Sophos delivery nor replaces correcting the policy. Do not assign any further devices until the pilot has passed.

Leaving the kiosk and withdrawing the policy

For Microsoft Assigned Access, Ctrl+Alt+Del is the default, configurable exit sequence – not a confirmed exit for a Sophos-managed device and not an MDM policy withdrawal. According to Microsoft, the kiosk may start again when signing back in as the kiosk account or after the timeout at the sign-in screen (30 seconds by default). On the actual pilot device, with a physical keyboard and any configured automatic sign-in or keyboard filtering, check whether signing in with the separate administrator account really works before the kiosk restarts. Stop the rollout if this cannot be demonstrated.

Check restart behaviour after assignment: If the optional sign-in setting was changed under the kiosk account before assignment, restart the pilot device afterwards and, if relevant, perform an update-related restart; check locally what actually happens at the sign-in screen and when signing back in with the kiosk account. Do not assume that the sign-in option remains accessible after kiosk assignment. Sophos describes restart behaviour here, not removal of the assigned policy, a guaranteed release of the device or a substitute for a tested route back. If the desired behaviour cannot be observed on the actual device, do not infer that the setting has taken effect and do not roll out.

For a permanent rollback, Sophos describes the following for Windows policies: change the active policy or assign another policy to remove its settings. Therefore document the previous policy state and every assignment of the pilot policy, and switch only when a safe alternative is ready. Do not edit a shared policy as a route back: changing it could affect all devices assigned to it. Then wait for device synchronisation and check on the device, using the former kiosk account, whether the restriction has been removed. A local PowerShell rollback from a Microsoft guide is not an established substitute for removing a Sophos MDM policy that remains assigned. Deleting a device record is not MDM unenrolment: According to Sophos, deleting a Windows computer that is still enrolled does not make it unenrol itself at the next synchronisation. It must be unenrolled manually as a separate step; if Forbid manual MDM unenrollment is active, Sophos instead specifies a factory reset. This is not a guarantee that a reset path is available: Where Sophos Restrictions applies, Forbid resetting the computer can block resets through Windows settings and Windows RE; according to Sophos, Restrictions does not apply to Windows Pro. Check both restrictions in the effective policy in advance. MDM unenrolment and reset are not a proven route out of the kiosk here and do not replace verified policy withdrawal on the pilot device; a reset may destroy data and should only be considered after separate authorisation and a physically verified recovery plan.

Scope of this draft: No tenant or device test has been performed for policy delivery, the AUMID, the actual exit sequence or policy withdrawal; a production rollout remains contingent on testing the specific Windows/Sophos/app combination.