Sophos Mobile: Manage macOS connectivity with device or user policies

This article covers Sophos Mobile policies on managed Macs, not general Apple Wi-Fi/VPN setup, Sophos Endpoint, ZTNA, or Sophos Firewall configuration. For client installation and firewall remote access rather than Mobile policy, see Sophos Connect on macOS. Device and user contexts are distinct: matching configuration names do not make identity, certificate access, or application timing interchangeable. Assigning a profile alone does not prove that the connection works.

Prerequisites: secure management access and a recovery path first

• Required MDM license: Managing Macs requires Sophos Mobile Device Management, either as a standalone license or included in the bundled Sophos Mobile license. Sophos Mobile Threat Defense alone is not sufficient: that license covers management of Sophos Intercept X for Mobile and Sophos Chrome Security, not Mac MDM. Check the corresponding MDM entitlement in the tenant before creating policies.
• Check that the Mac is enrolled in Sophos Mobile, which macOS version it runs, which policies are already assigned, and whether the required function must apply to the device or to a specific managed user. Macs have only one management mode in Sophos Mobile, but they can have device, declarative, and user policies. Apple User Enrollment for personal iPhones/iPads is not a macOS enrollment mode. For manual Mac enrollment, the user to be managed must enroll the Mac and enter an administrator password for the enrollment profile; for automatic enrollment through Apple Business, check whether No (no user assigned at enrollment) or Yes - LDAPS authentication is selected under Assign user to device. Do not infer user assignment from the device policy.
• Device policies apply to every user of the Mac. User policies apply to the user who enrolls locally and to network users known to Sophos Mobile from the external LDAP directory of the Self Service Portal. If a device policy joins a Mac to the same AD domain as the Self Service Portal, the user policy applies to all AD users who log in there. Verify this with the intended accounts before assigning widely.
• In addition to the enrollment device policy, a Mac can be assigned one further device policy, one declarative policy, and one user policy. Before changing any payload, record the target Macs, affected users and groups, and every assignment of the existing policy: never modify a policy already assigned beyond the pilot for the pilot. Document existing Wi-Fi, VPN, proxy, and certificate payloads and their owners; conflicting settings generally resolve to the more restrictive value, with a special precedence rule for declarative software update/app configurations. Do not layer additional assignments over existing profiles without control.
• Preflight check only for macOS 26 with a user policy: If the status is Failed to apply the policy, investigate previously assigned Restrictions configurations and policy history: the obsolete Allow Time Machine key can remain in an older assigned policy even when it is no longer visible in configuration options. Do not require finding the key in the current UI. If this legacy-policy cause is suspected, stop the pilot and assessment of that user policy’s Wi-Fi/VPN/certificate payloads: according to Sophos, the entire user policy may fail to apply, not just the restriction. Coordinate controlled cleanup and retesting with the macOS security and privacy policy owners; do not silently edit a shared production policy. This is not a general failure of all macOS 26 Macs or of device policies.
• Maintain independent access to the pilot Mac (for example, a working alternative network and local administrator access). Confirm the SSID, RADIUS/VPN endpoint, DNS, PKI trust chain, certificate expiration, PAC/proxy reachability, and any third-party VPN app with their respective owners in advance. Do not put access passwords or .pfx files in tickets or public storage. Check product, license, and OS support for the actual environment in the tenant; the configuration pages do not provide universal support for every macOS version.

Choose the policy and its dependencies

For a manually configured Global HTTP proxy that uses credentials, enter the proxy username in Authentication and the corresponding proxy password in Password. Authentication is a username field here, not an authentication-method selector. Confirm with the proxy operator whether credentials are required; do not put passwords in tickets or public storage.

Wi-Fi: define the network and authentication

The following field descriptions reflect Sophos’s documented settings, not a connection tested on a Mac. Connect automatically connects the Mac automatically when the Wi-Fi network is available. Hidden network identifies a network that does not broadcast its SSID. Match the selection to the target network; a hidden SSID is not a security approval.

Security type selects the security method and the Personal or Enterprise variant. Agree on both with the Wi-Fi operator. For Personal, enter the Wi-Fi password in Password. For Enterprise, Protocols provides the authentication protocols and Authentication provides client authentication:

• Under Protocols > Accepted EAP types, specify the EAP types the Mac accepts for authentication, matching the RADIUS service. For EAP-FAST, a Protected Access Credential (PAC) can be configured. This PAC is not a proxy auto-config file. For TTLS, Internal identity selects the protocol for user authentication inside the tunnel, not the username.
• If the selected Enterprise method uses a username and password, enter the Wi-Fi username under Authentication > User and the Wi-Fi password under Password. Assigning the policy to a user does not replace these entries. According to Sophos, Require password on each connect means that the password is sent on every authentication. Do not infer a password prompt, a particular storage method, or plaintext password transmission from this. Do not add a password to every certificate-based method indiscriminately.

Outer identity is a placeholder identity that starts EAP authentication without exposing the actual user credentials. It is transmitted in plaintext. Do not use the actual username or sensitive information. If the RADIUS service needs realm-based routing, the placeholder identity must include the realm agreed with the operator. Without this routing, a simple identity such as anonymous may suffice. The EAP and TLS 1.3 conditions below still apply.

Important for Enterprise Wi-Fi: For Identity certificate, Sophos Mobile requires a Client certificate configuration in the same policy first; for Trusted certificates, a Root certificate configuration must already exist. The Wi-Fi payload also has its own Proxy field for manual settings or PAC; it is not the same as Global HTTP proxy. The client certificate is available to other configurations within the same policy, not to other policies; upload it again there. At the platform level, Apple describes associating a SCEP identity with a service in the same configuration profile, although Apple’s specific Wi-Fi EAP-TLS example uses an AD certificate. This does not establish that Sophos Mobile offers a SCEP identity in its Wi-Fi Identity certificate field or delivers such a binding: Sophos Wi-Fi help instead names the Client certificate configuration as a prerequisite. Do not make SCEP a dependency for initial assignment or production Wi-Fi. Consider such an approach operationally only after proving the actual binding in your own tenant and on the managed pilot Mac, and completing successful EAP/RADIUS authentication; if neither selection nor a delivered binding can be demonstrated, stop using this approach. For EAP-TTLS/PEAP/EAP-FAST, set Outer identity without sensitive user data; Sophos says it is required for TLS 1.3. Set the TLS minimum and maximum together or leave both empty.

VPN: agree on the provider, authentication, and proxy

Connection name is the connection name the user sees on the Mac, not the policy name. The Sophos field list gives Cisco AnyConnect, Cisco Legacy AnyConnect, IPsec (Cisco), F5, Check Point, and Custom SSL/TLS as options under Connection type. Custom SSL/TLS is intended for providers whose App Store app supplies the VPN connection. This list does not establish support for every provider/macOS combination. The required app must already be installed; confirm its actual reverse-DNS identifier with the provider.

Use the following options only where the selected connection type and provider offer and require them. If the provider specifies connection properties, use Add under Third-party settings to enter each Key and Value. Do not copy properties from a different VPN. Group is a group that may be needed for VPN authentication, not a device group for policy assignment.

Agree on user and device authentication separately with the VPN operator:

• Under User authentication, choose Password or Certificate. The corresponding Password field contains the VPN password, while Certificate contains the certificate for VPN user authentication.
• With Device authentication = Keys (Shared Secret)/Group name, the fields Group name, Keys (Shared Secret), Use hybrid authentication, and Request password appear. Enter the authentication details supplied by the operator in Group name and Keys (Shared Secret). Select Use hybrid authentication and Request password only according to the operator’s requirements, not as a general connectivity fix.
• With Device authentication = Certificate, Certificate and Including user PIN appear. Select the required device certificate from the Certificate list. Including user PIN includes the user’s PIN in device authentication. The source specifies neither when the PIN is requested nor how it is stored.

Protect VPN passwords and shared secrets like other credentials. The certificate fields still do not establish a SCEP binding path; verify the actual identity and authentication in the intended user/device context.

Under the VPN-specific Proxy, No proxy means that no proxy is configured for this connection. With Manually, Server and port, Authentication, and Password appear. Enter the proxy address and port and, if required, the proxy username and password. Here too, Authentication is the username field. With Automatic, Proxy server URL appears for the URL of the server containing the proxy settings. This is a setting for this VPN connection, not a change to Global HTTP proxy.

Provider type distinguishes App proxy, a VPN tunnel at the application layer, from Packet tunnel, a VPN tunnel at the network layer. Agree on the appropriate option with the provider. Do not infer a split or full tunnel from this; traffic planning and pilot DNS/route checks remain necessary.

SCEP: check endpoints, identity, and keys

URL contains the CA server’s web address. %_SCEPPROXYURL_% refers to the server URL on the SCEP tab of Sophos setup. Challenge is the web address used to obtain a challenge password from the SCEP server, not the password itself. %_CACHALLENGE_% refers to the challenge URL on the same tab. CA name must be a name the CA understands; for example, it may distinguish different CA instances. Agree on the appropriate value with the PKI team; do not assume a universal name or that an entry is mandatory.

For an additional Subject Alternative Name, first select the type under Type of Subject Alternative Name, then enter the value under Value of Subject Alternative Name. Sophos describes RFC 822 name as a valid email address, DNS name as the CA server’s DNS name, and Uniform resource identifier as the CA server’s fully qualified URL. Do not silently replace these CA-server descriptions with general SAN assumptions. Agree on the type and value with the PKI team for the intended certificate use; they do not prove Wi-Fi/VPN identity binding. If an AD user identity is used, AD user logon name refers to the User logon name stored in AD, that is, the User Principal Name (UPN). SAN and AD details are not universal prerequisites for every Mac certificate.

Retries sets the number of retries when the SCEP server responds with pending. Retry delay is the interval between these retries in seconds. This is not a renewal interval or a guarantee that issuance succeeds after that wait. Key size is the size of the public key in the issued certificate and must match the size configured on the SCEP server. The SCEP configuration also has Allow export from keychain, which lets users export the certificate’s private key from the keychain. As with an uploaded client certificate, enable it only for an explicitly approved need.

SCEP and keys: The endpoint variables refer to the SCEP settings described above. After placeholder substitution, the Subject value must be a valid X.500 name: CN=%_USERNAME_% identifies a user, while CN=%_DEVPROP(SerialNumber)_% identifies a Mac. Do not infer an appropriate device identity from the choice of a user policy. Check CA trust, certificate lifetime, key export, expiration date, and the reissuance procedure before anything first depends on them; root certificates do not replace a client certificate. Add a separate Root certificate configuration for each additional root.

Other device payloads: AirPrint adds the printer IP and Resource path (for example, ipp/print) to the AirPrint list. Directory service joins the Mac to an AD domain when the policy is assigned; the join account needs permission to add computers, and the OU must be correct. Warning: Changing UID, User GID, or Group GID mappings can prevent users from accessing files created earlier. Do not change mappings as a network test; plan AD joining and its reversal separately with the AD and Mac owners.

Directory service: define accounts, home directories, and permissions

Under General settings, agree on the AD join details with the AD owners:

• Domain host name contains the DNS host name of the AD domain the Mac will join. Do not enter a DNS server address or the domain controller specified separately under Preferred DC server here.
• AD administrator name and Password contain the name and password of the account used to connect to the AD server. This join account must have permission to add devices to the AD database. Do not put the password in tickets or public storage.
• Organizational unit specifies the organizational unit (OU) in AD where the joining computer is added. Agree on the approved OU value with the AD owners; this field does not determine user or group assignment or the home directory.

Before joining AD, decide with the AD and Mac owners whether a local home directory with a mobile account or a network-only home directory is needed. If Create mobile account is selected, macOS creates the account at the first login with a connection to the AD server; afterward, login with AD credentials is possible even without a connection to that server. With Require confirmation before creating a mobile account, the user decides whether the mobile account is created—its creation is then not guaranteed. Mobile accounts require Force local home folder: the user profile resides on the startup volume. If this option is disabled, network-only home directories are used. Do not therefore enable mobile accounts indiscriminately for every Mac. If Use UNC path from Active Directory is used, macOS mounts the home directory specified in the AD user account; agree on the appropriate mount protocol under Network protocol with the responsible owners and test access in the pilot.

Default user shell sets the user’s command-line shell. According to Sophos, an empty field uses /bin/bash. This is a documented field default, not an unspecified macOS default; agree on the intended shell with the Mac owners.

Under Mapping, AD attributes are mapped to the following macOS identifiers:

• UID attribute maps an AD attribute to the unique user ID in macOS.
• User GID attribute maps an AD attribute to the primary group ID of a macOS user account.
• Group GID attribute maps an AD attribute to the group ID of a macOS group account. This mapping does not grant local administrator privileges; Domain administrator groups controls those.

Before assignment, reconcile the existing and approved mappings with the AD and Mac owners. Do not assume a universal AD attribute or that leaving these mappings blank is safe. The file-access risk described above still applies to later changes.

Under Administrative, obtain approval for the following decisions before assignment:

• Preferred DC server specifies the AD domain controller that macOS contacts first. If the field is left empty, macOS selects the controller based on AD site information and the responsiveness of the controllers. Agree on the choice with the AD team; an entry does not bind the Mac exclusively to that controller.
• Restrict DDNS limits the network interfaces for which macOS uses Dynamic DNS. By default, macOS uses DDNS for all network interfaces. To restrict this, enter the BSD names of the intended interfaces and press Enter after each entry. Sophos uses en0 as an example of a built-in Ethernet port; do not assume this identifies the appropriate interface on every Mac. Identify the actual interfaces on the pilot Mac and agree on the intended DNS registrations with the AD/DNS team. This setting restricts DDNS; it does not disable any interface or VPN tunnel.
• Computer-account password rotation: Password trust interval in days applies to the AD computer account, not the user password. An empty field means an automatic change every 14 days; 0 prevents automatic changes. Agree on the interval with the AD operations team; do not set 0 as a quick connectivity fix.
• LDAP protection: Packet signing / Packet encryption share a common description: Allow leaves it to macOS whether LDAP connections are signed and/or encrypted; Disable turns both off; Require always requires signing and encryption; SSL/TLS always uses LDAP over SSL/TLS. Do not infer that every value is available in both fields: check the actual choices in the tenant and agree on the required protection with the AD team. Do not lower protection to achieve a successful login.
• Login scope: Multi-domain authentication allows users from all domains in the AD forest to log in. This expands the login scope; it is not the application of the Self Service Portal user policy described above. With Namespace = Forest, users with the same name can exist in different domains; login uses DOMAIN\name. With Domain, namespace support is disabled and login names must be unique. Record permitted domains and accounts in advance; choosing a naming scheme does not replace approval of the login scope.
• Local administrator privileges: Members of the AD groups entered under Domain administrator groups receive administrator privileges on the Mac. These are distinct from the join account’s permission to add a computer. Enter only approved groups as DOMAIN\group and observe case sensitivity. For the pilot, record which accounts should remain standard users and which should receive local administrator privileges.

Assign the pilot and verify the effect

1. Define the pilot first: Check the inventory of specifically designated Macs and affected users, group membership, existing policy types and assignments, and working alternative access. For an existing policy, identify every assigned device and group; if it is assigned outside the pilot or its reach is unclear, do not edit it. Before replacing an existing macOS device or user policy, compare all payloads and dependencies and prepare a same-type recovery path for exactly those target devices. Use a group assignment only if membership and future additions are controlled; otherwise choose individual devices.
2. In Policies > macOS, use Create to make a new, isolated test policy of the appropriate type; use a copy only as a separate new policy with no inherited assignments. Before touching its first payload, verify that the test policy is not assigned to any device or group outside the approved pilot. Leave the broadly assigned production policy unchanged. Set its name, description, and organization name; with Add configuration > Root certificate, add the root configuration first for Enterprise Wi-Fi. Select Upload a file, choose the prepared public X.509 root certificate in PEM or DER encoding, and click Open. After uploading, save the root configuration with Apply. For certificate authentication, then add Client certificate in the same policy. In this Client certificate configuration, select Upload a file under File and choose the prepared PKCS #12 file (.pfx). Enable Allow export from keychain only if private-key export is explicitly required. Then configure Wi-Fi. Add VPN/proxy configurations only after meeting their own dependencies. Configure SCEP separately if needed: the general Sophos policy-creation instructions mention a policy-level SCEP renewal interval when SCEP is added, but the macOS SCEP field lists contain no such configuration field. Check in the tenant whether the policy interval is actually available for the selected macOS policy type; agree on expiration and reissuance with the PKI team. Do not treat SCEP as a source for the Wi-Fi Identity certificate field without separate proof. Finally, save the policy with Save on Edit policy; record the pilot scope, payloads, and original state for recovery.
3. Select the blue triangle of the isolated test policy and Assign; under Select devices, select only the inventoried pilot Macs or the previously checked and limited device group, then Finish. Check the selected targets against the inventory again before finishing; afterward, verify actual assignments and stop if the target group is unexpected. The selection at this step does not protect against changes to an already broadly assigned policy. This macOS path has no Now/Date scheduler for assignment.
4. On the pilot Mac, check assigned profiles under System Settings / System Preferences > Profiles in the correct context. A device-policy change takes effect at the next device sync; a user-policy change at the affected user’s next login. Changing macOS policies does not require an iOS-style manual Update devices step. Record assignment/task status and the local profile display, but do not treat either as a functional test.
5. Test the effect, not just the profile status: With the intended user, verify the Wi-Fi SSID and connection, and reconcile the expected server trust chain and client identity used for Enterprise EAP with the RADIUS/PKI team. Actively establish the VPN and test DNS/routes, reachable and unreachable destinations against the split-/full-tunnel plan; for proxy/PAC, test actual HTTP(S) access and the authentication path. Check certificates by fingerprint, validity, and intended use in the appropriate keychain. Test a second user as well if device-wide or AD-wide effects matter. Test AirPrint printing and AD login only if those payloads are actually being introduced. For Directory service, test the first online login with an approved AD account and access to the selected local or network home directory; if UNC is used, also verify the expected mount. If a mobile account is intended, verify its actual creation, including any required user confirmation, and then log in again without a connection to the AD server. Preserve independent local access throughout. With the AD/DNS team, check the domain controller actually contacted and the actual DDNS registrations against the agreed controller selection and interface scope. If the controller or a DNS entry is unexpected, stop the rollout and investigate the cause with these owners. Also check the expected standard-user/administrator privileges and, where the login boundary requires it, use a test account authorized for this purpose outside the permitted domain/account scope to verify that login is denied. With the AD team, verify the agreed LDAP protection on the actual connection and check the effective computer-account rotation interval; verify a password change due later separately rather than treating it as passed on the basis of the first login. If home-directory access, login scope, protection, or privileges differ from expectations, stop the rollout and involve the AD and Mac owners.
6. Allow another pilot wave only after the connection, a subsequent login, and management sync have succeeded. Plan certificate rotation with an overlap window: first verify new trust and identity, then remove the old CA or authentication method. Choosing a firewall TLS-inspection CA and configuring general Apple network profiles are outside this macOS Mobile policy decision.

Recovery if connectivity is lost or the wrong targets are affected

1. Stop the rollout and record all accounts, devices, groups, and profile versions actually affected; use independent access to compare the current profile with the last working combination. Before any correction, recheck all assignments of both the test policy and the recovery policy. Do not immediately delete the only connection or CA through which Sophos Mobile can still reach the Mac.
2. On macOS, do not assume the generic Uninstall policy action is available: according to Sophos admin help, it is available only for Android device, Knox container, and iOS device policies. Only if the test policy is demonstrably assigned exclusively to the pilot, correct its payloads and wait for device sync or user login. Otherwise, do not change a policy assigned outside the pilot: narrow its scope with the responsible owners first and use independent access. Alternatively, assign a prepared, working policy of the same type only to the affected pilot Macs; first check that policy’s assignments and payloads too, do not edit a shared production policy for recovery, and do not trigger a global group or Unassign action. When replacing a previously assigned policy, check its dependencies and the effective user/device context. Removing a user policy locally is not a lasting recovery method: it is reassigned at the next login. Do not remove the enrollment profile as a rollback; doing so deregisters the Mac and requires administrator privileges.
3. Before withdrawing an old root CA, check all dependent Wi-Fi/VPN and SCEP/client certificates and the working alternative path; if AD assignment or UID mappings changed, do not risk file permissions through blind profile switching. Demonstrate restored network connectivity, login, certificate chain, and Sophos Mobile sync on the same pilot Mac. If management access is still unavailable, involve local Mac/network/PKI support with the documented before-and-after values.

Validation scope: No macOS/tenant combination has been lab-verified here. This bounded documentary guidance does not require a blanket tenant/lab test before publication. Before environment-specific production rollout or any claim of working connectivity, verify edition/license, macOS version, policy scope and Apple Business user assignment, device sync and user login, PKI trust, Enterprise Wi-Fi EAP, and the client identity actually used on an authorized pilot Mac. For SCEP as a Wi-Fi identity, demonstrate in your own tenant whether the issued identity can be selected in the Sophos Identity certificate field or is otherwise actually bound in the delivered Wi-Fi profile; also verify the identity/fingerprint in the correct device/user keychain and successful EAP/RADIUS authentication with that exact certificate on the managed pilot Mac. Certificate issuance or profile installation alone is not enough. For SCEP as a VPN identity, too, demonstrate selection or delivered binding, the correct keychain/user context, and successful VPN authentication using the expected certificate on the pilot Mac; Sophos VPN help lists certificate fields but no SCEP binding path. SCEP-to-Wi-Fi/VPN binding remains unresolved and is not an operational path without a successful authorized pilot. Test the VPN app/provider/authentication, certificate rotation, independent access, policy replacement, and recovery on the device before production use.