Sophos Mobile: Manage Wi-Fi and certificates for Windows

Quick path: For a Windows device already managed in Sophos Mobile, create a separate pilot policy under Policies > Windows, add the appropriate Wi-Fi and, if needed, Root certificate, Client Certificate, or SCEP configurations, save it, and assign it to one test device only. First, retain access that does not depend on the new Wi-Fi network and keep the existing working connection. Then check both the connection and access to Sophos Mobile from the device. A saved policy does not prove that the device has applied the new profile.

This procedure covers Sophos Mobile MDM for Windows computers that are already enrolled, not the Sophos endpoint agent, Sophos Firewall VPN configuration, or the Sophos Connect client. The Windows policy pages document configurations but do not establish support for every Windows build and edition. Before assigning a policy in production, independently check the specific device’s Windows edition and build, Microsoft support status (including any required ESU entitlement), Sophos Mobile enrollment mode, and current Sophos compatibility. Windows 10 support is not guaranteed here. No tenant or device testing was performed.

Before making any changes

Check that the specific device is already enrolled in Sophos Mobile, that Policies > Windows and the required configurations are available in your tenant, and that the responsible person has authorized the assignment. Enrollment is a separate process; an existing endpoint agent does not replace it.
Confirm the SSID, authentication method, existing chain of trust, and required user or device identity with the Wi-Fi and PKI owners. A WPA2-Personal test profile is not a substitute for certificate-based 802.1X. The manual Wi-Fi form documents only WPA (Personal) and WPA2 (Personal). For other existing connections, Sophos describes importing an XML profile previously exported from Windows; whether it suits the specific Wi-Fi network must be checked on the pilot device.
Keep a second working network path for the pilot, such as an approved wired connection, as well as local access. If Wi-Fi is the only management path, do not remove the existing profile or CA first. Arrange an alternative access path and a responsible person to handle rollback.
Do not enable Forbid manual configuration under Restrictions for this pilot: Sophos says applying it deletes existing user-configured and Wi-Fi Sense Wi-Fi profiles. The entire Restrictions configuration is also not applicable to Windows Pro. Disable VPN settings merely blocks access to Windows settings; it is not a VPN configuration.
For certificates, obtain approval for the issuing CA, validity, intended Target store, and permitted key storage. A root certificate is a trust anchor, not a client certificate. Enable Key is exportable only for a justified need; neither a private key nor an exported Wi-Fi file belongs in tickets, chats, or public storage.

Set up the policy and Wi-Fi on the pilot device

In Sophos Mobile, open Policies > Windows > Create, choose a Windows policy type, and enter a name clearly identifying the policy as a pilot and a description on Edit policy. Use Add configuration to add the required components and edit each one by selecting its name.
For a simple test network, choose Wi-Fi > Configure manually. Example: replace SSID PILOT-WLAN with the actual SSID; set Security type to the network’s actual WPA (Personal) or WPA2 (Personal) configuration and enter the matching password. Enable Hidden network only for a network that is actually hidden, and Connect automatically only if automatic connection is desired. The example does not endorse any particular production Wi-Fi security architecture.
Alternatively, to reuse an existing Windows connection: on an authorized Windows computer where the network appears under Known networks, open Command Prompt as an administrator. Check the profile name with netsh wlan show profiles and export it to a preconfigured, access-restricted folder with netsh wlan export profile "<SSID>" key=clear folder=<Destination>. Replace <SSID> with the displayed profile name and <Destination> with the destination folder. The resulting XML contains the Wi-Fi password in plain text. Upload the XML file under Wi-Fi > Create from existing connection > Wi-Fi profile, then securely delete the local export file after uploading; do not copy the command output or file into a ticket. Do not run key=clear on shared or unprotected computers.
On Edit policy, select Save. Under Policies > Windows, select the blue triangle next to the pilot entry and choose Assign; on Select devices, select only the named test device and choose Finish. Do not accidentally use Select device groups for a production group: according to Sophos, Windows policies do not offer a subsequent Schedule task screen.
With independent access still available, check the Wi-Fi connection on the pilot device and access to an internal resource that is actually needed; then confirm that the device continues to communicate with Sophos Mobile. If the change has no effect, first check the target device, policy assignment, next device contact, SSID/security type, and status of the existing Wi-Fi connection. Do not mask an error with mass reassignments.

Distinguish certificate trust, identity, and SCEP

The WPA-Personal example above is not sufficient for 802.1X or another certificate-dependent connection. Importing an enterprise Wi-Fi XML profile together with a client or SCEP certificate is not a documented, ready-to-deploy Sophos 802.1X procedure: it remains unverified whether import, certificate selection, authentication, and application order work in the specific Windows, enrollment, PKI, and Wi-Fi setup. Therefore, test the following certificate components only on one device, with the Wi-Fi and PKI owners and independent network access:

Root certificate: upload the approved trust anchor

Before uploading the approved X.509 CA file (PEM or DER), verify it independently of the Sophos display against the PKI approval: file identity/fingerprint, subject, issuer, validity, and intended certificate chain. Common file extensions are .cer, .crt, and .pem for PEM, and .cer and .der for DER. These are examples, not an exhaustive list of permitted extensions. In particular, .cer can contain either encoding; the extension alone does not determine the format.

Upload the approved file under Edit policy > Add configuration > Root certificate > Upload a file. Alternatively, drag the file from File Explorer and drop it into the File area. According to Sophos, Certificate name displays the uploaded certificate’s Issuer Distinguished Name (DN), not a verified identity of the CA certificate; this field alone does not establish that it is the right trust anchor. Select Apply, then Save.

For each additional root certificate, add a separate Root certificate configuration to the same policy. The certificates in this policy can then be selected as Root certificate in its SCEP configuration. Distribute only the intended trust anchor, not an arbitrary downloaded certificate.

Client Certificate: define the identity and private key storage

For an existing issued client certificate, File accepts PEM or PKCS #12. In the Client Certificate configuration, click Upload a file and select the file containing the certificate. Alternatively, drag the file from File Explorer into the Upload a file area. After upload, Certificate name displays the subject value. Target store > User applies to the user enrolled with Sophos Mobile; Device makes the certificate available to all users of that computer.

Key location > Software stores the private key in a software-based key store; TPM or software instead uses a TPM if one is available, otherwise a software-based key store. TPM does not install the certificate if a TPM is missing or disabled in the BIOS. Windows Hello for Business stores the private key in a Windows Hello for Business container. Container name identifies the exact container in which this certificate’s private key is stored; specify a container appropriate to the environment.

Key is exportable allows users to export the certificate’s private key when exporting the certificate. This makes not only the public certificate copyable, but also its associated secret key material. The choice of storage location and exportability must therefore meet PKI security requirements, not merely allow the upload to succeed. The requirement from the prerequisites still applies: enable this only for a justified need, and do not put private keys in tickets, chats, or public storage. On the pilot device, verify the actual certificate store and intended authentication.

SCEP: coordinate issuance and identity with the PKI team

Instead of uploading an existing identity, the client requests a certificate from the CA. For the integration with a SCEP-capable Windows CA documented by Sophos, Sophos Fusion must generally be able to reach both separate paths over HTTP(S): <YOUR-SCEP-SERVER>/CertSrv/MSCEP (SCEP server URL) and <YOUR-SCEP-SERVER>/CertSrv/MSCEP_ADMIN (challenge URL); check firewall access and authorized credentials for each with the PKI team. For a Windows 2003 SCEP server, Sophos instead specifies /CertSrv/MSCEP as the challenge URL as well; do not extend this exception to other servers.

Before allowing network access, open My Products > Mobile in Sophos Fusion and check the hostname in the browser’s address bar: in the first URL component, the account region appears immediately after smc-user-if-cloudstation-. Use this account region, not the administrator’s or device’s location. For SCEP, allow inbound connections from Sophos Fusion to the SCEP server over TCP 443 and restrict source addresses to those documented for that region. Before the firewall rule is created or activated, the person responsible for the PKI/network change must retrieve the current Sophos source-address list for SCEP now, select only the addresses for the identified account region and approve them for this specific change. Record the account region, retrieval date and approved source addresses in the change record. This live retrieval provides the changing addresses, not an additional configuration guide; do not derive a permanently valid IP list from an old example. If no current list approved for this account region is available, stop here and neither create nor activate the firewall rule; never widen the allowed sources to other regions or arbitrary addresses.

These URLs are configured globally under Setup > Sophos setup > SCEP. Global configuration is a separate PKI change; do not assume these Windows CA paths apply to other SCEP implementations. Also coordinate the following settings with the PKI team:

Under User and Password, enter the credentials of the account authorized to create a challenge code and with the required permissions for certificate enrollment. In User, use the login format username@domain. This global SCEP service account is not the user identity intended for the certificate’s Subject; do not include credentials in examples or tickets.
Under Challenge characters, select the character types for the challenge password. Under Challenge length, accept the default length. These fields concern the password, not the Challenge URL in the Windows policy.
Clear Use HTTP proxy only if Sophos Mobile is intentionally meant to bypass the HTTP proxy when connecting to the SCEP server. This option is available only when the HTTP proxy is enabled; bypassing it is not a general SCEP prerequisite.

According to Sophos, Save tests only the connection to the SCEP server, not certificate issuance or renewal on the device.

In the Windows policy, first add the CA certificate as Root certificate, then add SCEP and define the fields with the PKI team:

Description describes this individual SCEP configuration, not the entire policy. Under URL, enter the CA server’s web address; %_SCEPPROXYURL_% references the globally configured SCEP server URL.
Subject is the name of the person or device that is to receive the certificate. Placeholders for user data or device properties can be used here. What matters is the resolved value after all placeholders have been replaced with the actual data: it must be a valid X.500 name and match the intended identity. CN=%_USERNAME_% is only a syntax example for a user identity, not a universally valid device subject. When the policy is assigned, %_USERNAME_% is replaced with the Exchange Login property of the user assigned to the device. This is not automatically the user’s email address, Windows login name, or the global SCEP service account under User. Check this property before assignment and, on the pilot device, check the resulting X.500 name against Exchange Login and PKI requirements; use a device placeholder only if its suitability for the specific Windows/enrollment mode has been confirmed.
Under Subject Alternative Name, add one or more SAN entries if needed. For each entry, select Add, then enter the SAN type and SAN value. Check the values against the required identity and CA requirements; a suitable subject does not replace this check.
Challenge is the web address used to obtain a challenge password from the SCEP server. %_CACHALLENGE_% references the globally configured challenge URL; it is a URL placeholder, not the challenge password itself. Under Root certificate, select the appropriate CA certificate. The list contains all certificates uploaded in Root certificate configurations in the current policy; it is not a general tenant-wide certificate inventory.
Retries specifies the number of retries when the server responds with pending, meaning issuance is still outstanding. Retry delay is the interval between these retries in seconds. Align both values with the PKI’s issuance process; additional retries do not fix incorrect challenge authorization or an invalid identity.
Key size is the size of the public key in the issued certificate. The value must match the key size configured on the SCEP server, not just the CA in general. Confirm the specific value with the PKI team; this does not imply any particular key storage location or exportability as with Client Certificate.
Under Certificate usage, specify the intended purpose: Use as digital signature permits use for digital signatures, and Use for encryption permits use for data encryption. Do not equate these purposes with an already working Wi-Fi connection or VPN tunnel; the selection must match the intended certificate and CA requirements.

Set the SCEP renewal interval when creating the policy and verify actual issuance and renewal with the CA on the pilot device. Do not assign the policy in production without confirmed CA connectivity and unambiguous identity mapping.

Success means more than “policy assigned”: on the pilot device, the correct certificate with the intended identity and validity must appear in the intended user or device context, the intended connection must authenticate, and contact with Sophos Mobile must continue. If SCEP fails, first check CA reachability, challenge authorization, subject/SAN, CA trust, key parameters, and device status with the PKI team; do not disable certificate checks or server validation just to make the test pass.

Prepare a rollback path with independent access

If something fails, leave the existing working connection and CA untouched if possible; an interruption-free rollback is not guaranteed. Using the independent access path verified beforehand, first check the policy name actually assigned to the affected device and its local connection. Correct the pilot policy or assign a previously prepared working Windows policy specifically to the same single device; replace the test configuration only after the device has contacted Sophos Mobile again and Wi-Fi has demonstrably worked. Sophos documents no device-specific Uninstall policy for Windows policies: that action applies only to Android, Knox, and iOS policies. According to the documentation, Unassign affects all devices assigned to a policy and is therefore not a safe rollback for a single device. Changes to other policies synchronize automatically at the next device contact; without contact, do not claim a successful rollback. Before any production change, policy synchronization, actual Wi-Fi authentication, and the local rollback path must be observed and approved on the exact enrolled Windows device while secondary access is secured.

If the device is already offline, do not centrally revoke the CA or SCEP credentials, remove old Wi-Fi profiles, or change a group policy on a hunch. First restore local access using the agreed alternative path and record the current state; then recheck the pilot assignment and certificate validity. Whether or when certificates or profiles left on the client are removed by a policy change is not documented here as a guaranteed automatic behavior and must be verified in your own Windows/Sophos Mobile setup.

VPN boundary: Sophos’s current list of Windows policy configurations includes Wi-Fi, root/client certificates, and SCEP, but no standalone Windows VPN payload. Disable VPN settings under Restrictions blocks settings; it does not deploy a VPN. For a VPN connection, plan the client, tunnel protocol, gateway, and authentication separately; an installed certificate alone does not create a VPN tunnel. The existing Sophos Connect provisioning steps for Windows cover the separate firewall/VPN client path.