Sophos Mobile: Plan macOS security and privacy policies

Scope: This article covers Sophos Mobile for managed Macs, not Sophos Endpoint protection policies or a local macOS installation. A macOS device policy applies to all users of the Mac; a macOS user policy applies to the local user who enrolled the Mac with Sophos Mobile and to network users known to Sophos Mobile through the external LDAP directory for the Self Service Portal—not automatically to every local user. The same configuration name in both policy types does not establish that their assignment and effects are identical. Keep the security and privacy decisions here separate from Wi-Fi/VPN/certificates, directory integration, and the dedicated update rollout. The Sophos Endpoint MDM profile for Full Disk Access and System/Network Extensions is not a substitute for these Mobile policies; its rollout is covered in Deploy Sophos Endpoint on macOS via MDM.

Before making changes: establish scope and a recovery path

Sophos Mobile distinguishes four macOS policy families: device, user, and declarative policies configured in Sophos Mobile, and imported policies based on Apple configuration profiles. An imported .mobileconfig profile may come from Sophos Fusion for Endpoint, Apple Configurator, or a trusted third party. It is not equivalent to a native Sophos Mobile configuration: check its device or user channel and potential overlaps against its actual payloads; do not assume that the conflict rule below applies to every imported profile.

Before importing, establish the profile’s origin, approved file version, included certificates and secrets, suitability for macOS, and the required import and assignment permissions in your tenant. Encrypted configuration profiles cannot be imported. Start at Policies > macOS > Create > Import policy: enter a name and description, select the reviewed .mobileconfig under Upload a file, and select Save. This creates only the policy entry; it does not install the profile on the Mac. Separate assignment, conflict checks, and pilot verification are covered in Import Apple configuration profiles into Sophos Mobile; for Endpoint, use the Endpoint MDM guide linked above.

1. In your Sophos Mobile tenant, identify Policies > macOS and the device or user policy actually assigned. The enrollment policy is itself a device policy. In addition, a Mac can be assigned one device policy, one declarative policy, and one user policy. Record these separately. A declarative macOS policy is a type of device policy that uses Apple’s Declarative Device Management (DDM). Document the device, enrollment user, known network users, macOS version, management mode, and current policy assignments. Check option names and availability against the labels in your own console: some restrictions depend on device type and operating system version.

   What DDM changes in operation: With classic MDM, Sophos Mobile controls individual settings and periodically polls the device’s status. With DDM, you specify a desired state; the Mac itself is responsible for reaching and maintaining that state and reports changes asynchronously, without waiting for the next periodic status poll. These ongoing status reports do not mean that a newly assigned or changed policy is installed immediately or that an update has already completed. For policy changes, the distinction between device sync and user sign-in described below still applies.

2. For each change, record whether it should affect all users or only the enrollment user and known network users. Before editing any already-assigned policy, inventory every assignment of that exact policy: capture all target Macs, groups, affected managed users, and indirect assignments; document the actual scope and approver. A pilot Mac does not isolate a change to a policy shared with other devices: change only a separate policy assigned exclusively to the pilot, or obtain explicit approval for the impact on all existing assignments. Until the full assignment inventory is known, do not select Apply or Save. According to Sophos, the more restrictive setting generally wins in a conflict; exception: software update and app settings in a declarative policy take precedence over the corresponding settings in device or user policies. Preserve a baseline of the affected settings without obsolete keys and identify the responsible approver. Choose a pilot Mac with one test user and, where relevant, a second user. Do not assign a policy indiscriminately to the entire fleet.

3. Assess the impact in advance: remote access and file sharing, camera/FaceTime, printers, app installation, iCloud data flows, credentials, and required browsers and third-party filters. Before enforcing passwords, arrange user communications, support, and an independent recovery path for lockouts. Do not use “Number of failed attempts until device wipe” as a test value: once the threshold is exceeded, data and settings are removed; at values of six or fewer, the later delay does not apply. Withdrawing a policy does not undo a wipe or lockout that has already occurred; plan data recovery only through previously tested backups and approved device-recovery procedures.

4. Obtain privacy approval for filter and account payloads: who processes browser/socket traffic, URL and connection metadata, or contact and calendar data? Which third-party app and data flows have been approved? Keep passwords, tokens, principal/server URLs, and personal test URLs out of screenshots, tickets, and logs, or securely redact them before sharing; do not store secrets in repositories. Servers, ports, and placeholders are tenant- and provider-specific, not reusable sample configurations. Sophos Mobile policy payloads alone establish neither consent for a Data Lake nor particular macOS system permissions for a third-party app.

Device security configuration

Configure the following payloads under macOS device policy only with confirmed device-wide scope and in the approved pilot:

Updates are separate: The macOS software update delay restriction is 0 (offer immediately) or 1–90 days after release. For macOS 27 and later, Sophos also documents Software update settings in a declarative policy. The choice between a target version with a deadline, a specific Background Security Improvement, and general update settings, together with their interaction with classic policies, is covered in Manage macOS updates with Sophos Mobile. Plan update timing, mode, and deployment there with a dedicated pilot, not alongside firewall and privacy changes.

FileVault is separate: Neither the application firewall nor the 19 source payloads covered here configure or confirm FileVault encryption, encryption status, or recovery-key escrow. That is a separate task for the owner of Manage FileVault with Sophos Fusion; do not infer successful encryption or key escrow from firewall or password policy status.

Device-level privacy preferences and web content filtering

Privacy preferences policy control (device policy): Sophos Mobile documents the specific option Allow Sophos Endpoint to scan all files, giving Sophos Endpoint access to data such as Mail, Messages, Safari, Home, Time Machine backups, and certain administrative settings for all Mac users. Users must accept the policy; according to Sophos, this acceptance requirement does not apply to devices managed with Apple Business. In the pilot, check management mode, assignment, user acceptance where required, and actual Endpoint access separately. This single option is not a general PPPC/TCC grant for third-party apps and does not replace app-specific Full Disk Access, System Extension, or Network Extension profiles. The profiles and permissions required for each third-party app belong to the responsible profile/app owner for approval, not to a permissions matrix inferred from these 19 sources.

Web content filter (device policy): Requires a third-party app whose Filter ID is its bundle ID. Configurable fields include Filter name, Server (name, IP address, or URL), optional Organization, User name, Password, Certificate, and provider-specific Third-party settings. Under Filter range, choose between Browser traffic (Safari and other browsers) and Socket traffic (app network traffic). Verify the app license, required system permissions, data recipients, filtering behavior, and failure behavior with the provider and in your tenant beforehand. For filter servers using credentials, use only a tested TLS-protected transport with certificate validation; otherwise, do not deploy credentials until a documented provider/tenant exception with an equivalently secure path has been approved and tested. The Mobile payload is not a built-in Sophos web-filtering engine, nor does it automatically grant macOS Network Extension or privacy permissions.

User policy, data access, and system permissions

Under macOS user policy, select payloads only for the local enrollment user and known network users. According to the respective Sophos pages, Managed domains and Password policies contain the same described fields as their device-policy counterparts, but have a different policy scope. Restrictions are also largely parallel; the user policy specifically no longer includes Allow Time Machine configuration. When policies are assigned in parallel, test the general “more restrictive wins” rule and the documented precedence of declarative software update/app settings with the test user; do not assume any other precedence rule.

• App Store: Restrict to updates permits updates but not new installations. Forbid app adoption prevents apps not installed through the Store from being adopted into the Apple Account; those apps then cannot be updated through that route. Turn off update notifications suppresses update notices and is not a substitute for an update policy.
• Restrictions / privacy: iCloud switches affect the potential transfer of mail, calendars, contacts, photos, notes, passwords, and files. Switches for camera, Touch ID, Auto Unlock, AirPrint, and remote scripting affect functionality, not automatically the PPPC/TCC permissions of arbitrary apps. Assess operational consequences in advance for Apple Events permitted by Remote Application Scripting, and for Remote Management and file sharing. Do not infer a blanket “Full Disk Access granted” from this list.
• CalDAV / CardDAV (user policy): Account display name, server, port, optional Principal URL, username, and password concern calendars or contacts, respectively. Require SSL/TLS and trusted certificate validation for accounts with credentials; if the service does not support this, do not deploy credentials until a documented exception approved by the provider and tenant owner, with an equivalently secure transport, has been tested. Check the synchronization scope in the pilot.
• Email account (user policy): Configures an Exchange Web Services (EWS) account for mail, contacts, reminders, and calendars. Set Account name as the account name. Do not enter the Sophos Mobile EAS Proxy as the server: Macs do not support its ActiveSync protocol.
  • Exchange Online: For the global Microsoft 365 cloud, use outlook.office365.com as Server name when automatic OAuth host discovery is not used; check the appropriate provider address for other clouds instead of reusing this host. Leave Domain blank. User is usually the email address; %_EMAILADDRESS_% inserts the assigned user’s address.
  • Exchange Server: Enter your own server URL as Server name when automatic OAuth host discovery is not used. Enter the user account’s domain under Domain; %_USERNAME_% in User inserts the assigned user’s Exchange login. Email address can be populated with %_EMAILADDRESS_% from the actual address. Use both placeholders only if Exchange Login and Email Address are maintained for the correct user in Sophos Fusion.
  • Sign-in and transport: If Password is left blank, users enter their password on the device. Enable Turn on OAuth 2.0 for the appropriate Microsoft sign-in. Leave Server name blank when using automatic OAuth host discovery. Enter an OAuth authorization endpoint only if the authentication provider requires it: doing so disables host discovery, and Server name must contain the server URL. Enable SSL/TLS and transmit credentials/tokens only over a tested TLS path with valid certificate verification; test this in the pilot before rollout.
• IMAP/POP: Set account type, display/email address, and separate incoming and outgoing Server, Port, User name, Authentication type, Password, and SSL/TLS fields; select Use same password as for incoming email only if supported by the server arrangement. Placeholders likewise require maintained user data. Confirm the secured TLS path and certificate validation in both directions with a test account before signing in with production credentials, rather than assuming sample ports.
• LDAP: This payload supplies directory data to the macOS Address Book app and is not a domain join. Configurable fields include host, username, password, Use SSL/TLS, and Search settings with a base DN and scope (base only, base and direct children, or all descendants). For binds using credentials, require Use SSL/TLS and certificate validation; if the provider does not support TLS, do not silently enable a plaintext bind. Proceed only after documented provider/tenant approval and testing of an equivalently secure transport. Limit search scope and access rights to the required records.
• Web Clip: Configure Description, URL, Can be removed, Full screen, and Icon. Use an HTTPS link you have verified yourself; the payload also accepts custom URL schemes, which may launch other apps unless checked. According to the documentation, a nonremovable clip can only be deleted after its policy is removed. Icons must be PNG/GIF/JPEG and no larger than 1 MB.

Network reachability, certificate chain, proxy, VPN, and managed root/client certificates are approved separately in a connectivity runbook. System permissions: The Sophos Endpoint option above is a specifically documented Mobile device payload outside the 19 original child-page indices. Additional TCC/PPPC, Full Disk Access, System Extension, and Network Extension permissions are checked separately for each app and its current vendor profile; the 19 sources do not establish a universal PPPC allowlist.

Test in a pilot before expanding

1. On the test Mac, verify the device policy and, where applicable, declarative policy assignment and a recent Sync: according to Sophos, changes to these policies take effect at the next sync. For the user policy, verify assignment and a new sign-in by the enrollment user or known network user: changes to it take effect only at the next sign-in; a check-in alone is insufficient. Document policy status in Sophos Mobile and the locally effective macOS settings separately for each user; assigned does not mean effective.

   On macOS 26, view profiles under Apple menu > System Settings > General > Device Management; scroll down if needed. Compare the expected profiles with the assignments in the appropriate user context. For other macOS versions, including macOS 27, check the applicable menu path instead of assuming the macOS 26 path is correct. The older System Preferences > Profiles is not a universal current path. A visible profile does not replace the functional tests below.

2. Run checks matched to the change: inbound remote access/file sharing after a firewall change, launching an approved and an unapproved app under Gatekeeper, lock time and password changes with a test account without triggering the wipe threshold, out-of-domain labeling in Mail, App Store behavior, iCloud access, and account synchronization. For the Sophos Endpoint privacy payload, verify required user acceptance or the Apple Business exception and effective access after sync; verify third-party permissions separately. Test filters only with approved test destinations and browser as well as app traffic as appropriate for the selected Filter range; do not copy real personal URLs into test logs. Before using production credentials, test TLS and certificate validation with synthetic test data for CalDAV/CardDAV, EWS, incoming and outgoing IMAP/POP servers, LDAP, and any third-party filter server that uses credentials; if a documented provider/tenant exception is used, test its equivalently secure transport in the pilot as well. Document only redacted results without secrets or URLs.

3. Test user and device payloads on the same Mac with the enrollment user, a known network user if applicable, and an unmanaged user; sign in again as each affected user. Fleet-wide rollout remains blocked until assignment, effective local behavior including privacy consent, secure account transport, and an independent recovery path have been demonstrated on the pilot Mac in your own tenant. Roll out only confirmed values and platform versions in waves; compare policy status, functionality, and support reports after each wave.

Diagnose failures and roll back safely

Removing a policy locally is not a policy rollback: Users cannot remove native device or declarative policies from the Mac. They can remove a user policy, but it is automatically reassigned at the next sign-in; this does not unenroll the Mac. Removing the enrollment policy has a different outcome: when removed with the required administrator privileges, the Mac is unenrolled from Sophos Mobile. This does not undo an individual security setting and must not be used to troubleshoot firewall or privacy issues. Preparation for intentional unenrollment and its consequences for policies, MDM certificates, and managed access are covered in Mac enrollment and unenrollment. Before unenrolling, secure independent network and administrative access and a plan for data and certificates; do not treat the profile view as blanket permission to remove profiles.

• Policy not applied: First compare the device/user, macOS version, management mode, assignment, and exact Restrictions labels. Do not change certificates or networking on speculation. If filtering has no effect, check the third-party app, bundle ID, filter range, and required macOS permissions separately. If account synchronization fails, identify the credentials/placeholders, TLS, server, and protocol involved.
• Special case: macOS 26: If the Policies view for a macOS 26 Mac shows only “Failed to apply the policy” for a User policy, the cause may be an obsolete Allow Time Machine key saved in an older user-Restrictions configuration that is no longer offered. The product update removes the visible switch, not the key from existing policies automatically. Before editing, inventory every direct and indirect assignment of this user policy and all affected Macs/managed users (step 2); changes to a shared policy affect more than the selected pilot Mac. Isolate the pilot with a separately assigned policy, or obtain approval for the entire inventoried scope before Apply/Save; do not proceed if the inventory is incomplete. After approval, open the assigned user policy under Policies > macOS, open Restrictions, then select Apply followed by Save. Beforehand, preserve only the other, still-supported values; afterward, verify policy application and the intended restrictions at the next sign-in of every affected managed user. If Time Machine configuration is required, move it to a device policy only as an explicit decision: this will affect all users. Never write the obsolete key back into a user policy; do not substitute an uncontrolled change of policy type or a network/certificate repair. If the error persists, preserve status and assignment details and escalate to Sophos Support.
• Rollback: If functionality is lost, stop the rollout; for a separately isolated pilot policy, withdraw only its assignment in a controlled way. For changes to a shared policy, account for all inventoried assignments in the rollback and restore only the documented, still-supported Restrictions values in the same policy type, or remove the new payload from scope in a controlled way. Never restore a complete old policy backup or old policy bytes if that would bring back the obsolete User Restrictions key “Allow Time Machine”; do not recreate it manually either. Check device changes at the next sync and user changes at the next sign-in of every affected managed user. For firewall lockouts, use a previously tested alternative local administrative access method. Do not blindly remove the entire device policy, required Endpoint MDM permissions, or the last administrative access method. After each correction, recheck the policy status and restored functionality on the Mac. A password lockout or device wipe that has already occurred is not reversible through policy rollback: use support/recovery procedures and tested backups where appropriate; never trigger a wipe threshold as a “rollback test.”