Android Enterprise: Device policy for fully managed corporate devices

In brief: The Sophos Android Enterprise device policy applies to devices in Android Enterprise full device mode. This guide covers the policy for fully managed corporate devices, not the separate work profile policy for devices in Android Enterprise work profile mode (for example, BYOD; management mode should not be confused with device ownership). Settings with the same name do not necessarily have the same effect in both modes. The options described here are decision aids, not a default profile tested in a tenant.

Before changing a policy

Check that the devices are actually enrolled in full-device mode, that the required Sophos Mobile license is available in the tenant, which Android version and device model are affected, and which policy is actually assigned to the test device. Document the planned changes, starting state, backup, and recovery path. First observe on a representative corporate device whether the intended setting takes effect and can be reversed; only then approve a broader rollout. Neither creating nor assigning a policy proves that it has taken effect on the device.

Prepare and assign the pilot policy

In Sophos Mobile Admin, go to Policies > Android > Create and select Android Enterprise device policy, or edit the approved test policy. When creating a policy, enter a name and description on Edit policy.

Restrictions is also an available configuration and is added automatically by Sophos Mobile; open its name to edit it. Under Add configuration, add App Control, App permissions, App Protection or Password policies as needed, then open the configuration’s name. For Password policies, then select the permitted password type under Password type. If you want to set up a mail account, add the configuration under Add configuration > Email account and open its name to edit it too.

Then save the policy with Save. Do not experiment with a policy shared by production devices: a change affects its existing assignments, not just the test device currently being viewed.

To assign it to specific devices, under Policies > Android open the blue triangle next to the saved policy > Assign. Under Select devices, select the approved test device; for a test group, use Select device groups and check which devices it actually contains. Complete the assignment with Finish. The device group here determines the target devices; the app group below determines the apps within a configuration.

Android Enterprise policies remain assigned permanently and synchronize whenever the device connects to Sophos Mobile. Sophos describes their assignment as taking effect immediately; this does not promise immediate delivery to an offline device. Changes do not require the Update devices path used for legacy Android device policies. To reverse a change, restore and save the documented, approved previous configuration, or use the same Assign path to assign a replacement policy tested beforehand. Uninstall policy is not a recovery path for this Android Enterprise policy type. After the device connects, check the actual assignment and each app’s behavior again; saving a reversal does not prove rollback.

Apps and permissions

App groups for launch blocking and password protection

App Control and App Protection each use the app list selected under App group. For either, create an Android app group under App groups > Android > Create app group. Give it a distinct name and open Add app > App list. Select an app from those currently installed on managed devices, add it with Add, and repeat for further members; finish with Save. Before selecting the group in the policy, compare its saved members with the apps actually intended. For a manufacturer app without a store listing, this installed-app list is the documented selection path; do not assume every OEM app has a Google Play link.

When adding an app manually through Custom, App name is the unique name and Identifier is the internal app identifier. For a Google Play app, open its store page under Link > Obtain link; copy the link and use Get data to populate App name and Identifier. The Android package name follows id= in the Google Play URL. For apps from Managed Google Play, Sophos requires the string app: before the package name in the Identifier. Do not apply this prefix to all Android or OEM apps indiscriminately. Before the pilot, compare the display name, identifier and saved group membership again: a similarly named app does not prove that the correct member was selected.

App Control: block launching, not uninstall

Under App Control > App group, select the group of apps users must not launch. This includes manufacturer-preinstalled apps that cannot be uninstalled and is not uninstallation. For operationally required apps, first establish their dependencies and a usable emergency access path on the pilot device.

After assigning the policy to the intended device and connecting it to Sophos Mobile, try launching a listed app directly on the pilot device: it should be blocked. For comparison, open an unlisted app that worked before and is not otherwise blocked. For an affected OEM app, also check that it remains installed; a missing icon alone proves neither uninstallation nor the correct block. To test reversal, remove the test member from the group and save the group, or restore the App Control configuration to the approved starting state. After synchronization, repeat the same launch attempt. If behavior differs from expectations or the block remains, do not assign further devices: check the identifier, group membership, effective policy and device connection with the Mobile administrator. This direct launch test does not establish that already-running processes are terminated or that all background and indirect access is blocked.

App permissions: set permissions for specific functions

App permissions controls only runtime permissions, not every approval an app requests. Under Default response for runtime permission requests, Prompt asks users to grant permission; Auto-accept grants and Auto-deny denies the requested runtime permissions automatically. Both automatic options prevent users from subsequently editing those permissions. Prompts for battery optimization or accessibility services may still appear.

Under App-specific runtime permissions > Add, select the app and decide for each required permission: Selectable lets users edit it, Granted grants it and Denied denies it. Prescribe only the permissions required for the specific function. The default response and app-specific options are documented, but their priority when settings conflict is not; do not create such conflicts for the pilot. The field name Default response also does not establish which option is selected out of the box.

For a non-destructive check, choose a test app and an action known to require a particular runtime permission. After assignment and synchronization, check whether a user prompt appears, whether the function is actually allowed or denied, and whether the user can change the permission. Also record existing grants so that the absence of a prompt is not treated as success on its own. A remaining battery optimization or accessibility prompt is not evidence that the runtime setting failed. After restoring the previous configuration or assigning the tested replacement policy and reconnecting, check the same function and editability again. If results differ from expectations, first establish the app, requested permission type and effective settings rather than applying Auto-accept across the board.

App Protection: shared password and grace period

Under App Protection > App group, select the group of apps to protect. Users set one shared password for all protected apps when first opening a protected app. Password complexity defines requirements such as minimum length and required letters or digits; select these separately from the device screen lock. Grace period in minutes is the grace period after a protected app is closed: during this interval, another protected app can also be opened without entering the password. Allow fingerprint authentication permits fingerprint authentication instead of password entry.

Access through other apps such as Google Assistant or Android system functions, and multi-window modes such as Split Screen, Floating Windows or Tiny Windows, can bypass the password prompt. Do not use App Protection as a device lock or a comprehensive guarantee for confidential app content. Manual locking does not remove these documented Android limitations either.

On the authorized pilot device, after assignment and synchronization, go from the Sophos Mobile Control > App Protection home screen to Password-protected apps and compare the displayed apps with the selected app group. Test with two selected apps and an unselected control app: on the first protected launch, create the shared password, close one protected app, and open the other both within and after the configured grace period. This checks the cross-app grace period rather than merely reopening the same app. If fingerprint authentication is allowed, test that access separately too. After locking the device and after App Protection > Lock protected apps, reopen the protected apps and check the password or permitted fingerprint prompt. Lock protected apps locks all protected apps at once, for example before handing over the device; the control app is not part of this password protection. Account separately for the described access through other apps/system functions and multi-window modes rather than claiming a complete lock.

To reverse the change, modify and save the app group or App Protection configuration according to the documented starting state, or assign the tested replacement policy. After the next connection, check both Password-protected apps and the actual opening of the test apps again. If unexpected apps remain protected or expected protection is missing, stop further assignment and check group membership, the policy and synchronization. All these checks are planned pilot tests, not device tests performed here.

Forgotten app password: First check that the Sophos Central Self Service Portal is available to the assigned user and that the action is permitted for them. Under Mobile, select the correct device and run Actions > Reset App Protection password > Reset. The next time a protected app is opened, the user sets a new shared password; verify this step on the intended device. This is not a reset of the device screen-lock password, a wipe or a factory reset.

Gmail and Google Play

The Email account configuration can add an Exchange Online or Exchange Server account to Gmail. For %_USERNAME_% and %_EMAILADDRESS_%, the assigned user’s Exchange Login and Email Address must be populated in Sophos Fusion. To edit these details, open the assigned user’s name under My Environment > Users & Groups > Users and update the user details. A policy using these placeholders cannot be assigned to a device without an assigned user.

Account name is the account’s name, while User sets the sign-in name. Email address is the account’s email address, and Sender is its sender name. If %_EMAILADDRESS_% is entered in either of these last two fields, the server replaces the placeholder with the actual email address. Default email signature sets the default email signature.

If an older managed Gmail configuration is still present, Gmail ignores Email account—even if the older configuration is empty; it is no longer offered in newer versions.

For Exchange Online, Sophos specifies outlook.office365.com only for the worldwide Microsoft 365 cloud; check the appropriate cloud endpoint for other clouds. Exchange Server requires the server URL; if a Sophos Mobile EAS proxy is used, enter its URL instead. The username is usually %_EMAILADDRESS_% for Exchange Online and %_USERNAME_% for Exchange Server; add a required domain prefix only if it is not already included in the Exchange Login field in Fusion. In this case, enter <domain>\%_USERNAME_% under User and replace <domain> with the domain required for your Exchange Server sign-in.

Under Authentication, Basic authentication uses a username and password. The separate Modern authentication option uses modern authentication (OAuth 2.0). Basic and modern authentication uses modern or Basic authentication according to what Exchange supports. For modern Gmail authentication (OAuth 2.0), Google Chrome must be installed on the device; the offered Basic and mixed options do not guarantee compatibility with your Exchange service. SSL/TLS secures the Exchange connection using SSL or TLS, depending on what the server supports; Sophos recommends this option. Allow all certificates broadens certificate acceptance and requires a deliberate trust decision.

Allow unmanaged accounts lets users add or remove other Exchange accounts, but not the account specified in this configuration. With this option enabled, data sharing between other apps and user-added Exchange accounts cannot be prevented. In a pilot, check the existing Gmail configuration, user assignment, authentication, certificate trust, and mail flow; Exchange/EAS proxy migration is a separate topic. Synchronization period limits the mail synchronized to the selected time window; check whether older mail must be available offline. Client certificate selects the certificate for the Exchange connection; confirm its availability and trust separately before relying on certificate-based access.

The Google Play configuration determines which apps users on fully managed devices can access in the Play Store and how automatic app updates are handled:

• Available apps: Approved apps from managed Google Play allows access only to apps approved for the organization in Managed Google Play; Apps from Google Play allows access to all Google Play apps.
• Auto update apps: Over any network updates apps automatically over any network, including Wi-Fi and mobile data; Over Wi-Fi only updates them only over Wi-Fi. Don’t update apps automatically means no automatic app updates. With Use device setting, the device setting applies; users can configure automatic updates themselves in their Play Store app.

Choose Play Store app access and update behavior deliberately for the use case, accounting for update and data-cost implications; a Play Store selection does not replace the separate deployment of managed apps.

Do not confuse screen lock and password managers

Password policies controls the device screen lock. Under Password type, select the permitted type: Pattern, PIN or password requires a screen lock using a pattern, PIN or password without further restrictions. Simple password requires a password lock with at least one letter; digits are also allowed. The other types are PIN or password, Alphanumeric password (letters and digits), and Complex password (a password lock with letters and digits plus additional configurable character minimums).

The last four types display minimum password length, maximum idle time, maximum password age, Maximum sign-in attempts and Password history. The device may impose a shorter idle timeout, and password age ranges from 0 (no required change) to 730 days. Password history prevents a new password from matching the configured number of previously used passwords stored by Sophos Mobile.

Only Complex password displays six additional, separate minimum-count fields: Minimum number of letters for all letters, Minimum number of lowercase letters for lowercase letters, Minimum number of uppercase letters for uppercase letters, Minimum number of non-alphabetic characters for non-alphabetic characters, Minimum number of digits for digits, and Minimum number of special characters for special characters. Non-alphabetic characters and special characters have separate fields; do not combine them into a single minimum.

A configured Maximum sign-in attempts threshold wipes the device after that many incorrect attempts. Before enabling it, require a backup, an approved pilot and an authorized recovery path. If Factory Reset Protection (FRP) is enabled, separately confirm that usable credentials are available for an authorized Google account configured to unlock this particular device under FRP. This policy page does not establish which reset method activates FRP; FRP configuration and reset-method consequences belong to the separate FRP-recovery owner. Withdrawing the policy does not restore wiped data.

Password services, by contrast, controls the use of password managers. Under Mode, Allow permits only the managers in the app group selected under App group; Block blocks those managers and permits others. For a group-based list, select the app group containing the relevant managers under App group. Allow system apps is available only when Mode is Allow. It can optionally permit the device manufacturer’s preinstalled password managers; if no app group is selected, this combination permits only those manufacturer-provided managers. This configuration is not the screen lock and does not describe a wipe after failed unlock attempts. Inventory the password managers needed in a test before blocking them.

Restrictions with asymmetric effects

Under Restrictions, you can restrict functions on fully managed devices. The following topics group operationally important permissions and their limits; they are neither a default profile nor a complete list of restrictions.

Device access and confidential content

Force encryption requires users to encrypt the device. Allow factory reset lets them reset it to factory settings; this is a user permission, not the administrative wipe workflow or a statement about triggering FRP. Allow safe mode permits starting in safe mode, while Allow debugging permits enabling debugging features in Android’s developer options. Allow user to configure credentials lets users install or remove certificates; distinguish this permission from MDM certificate deployment.

Allow Smart Lock permits automatic device unlocking in certain situations. The setting is ignored when a separate work-profile lock is configured. Allow unlocking device by fingerprint permits fingerprint unlocking of the device, not the separate App Protection access. Allow screen capture permits screenshots of the display. Hide sensitive information on lock screen hides sensitive notification content when lock-screen notifications are enabled.

Allow changing the account picture lets users change their user account’s photo.

Allow location services permits sharing the device’s location with apps and services. Turning it off disables location services and prevents users from enabling them again. Sophos Mobile cannot locate the device either.

System apps, installation and app management

In the documented starting state, most manufacturer-preinstalled system apps are disabled. Apps for basic functions such as phone calls, contacts or messages remain accessible; which apps these are depends on the device model. Enable system apps enables all system apps. According to Sophos, once enabled, these system apps cannot be disabled again; do not use this switch as a reversible default test.

If Allow wallpaper change is turned off, users cannot change the wallpaper.

If Allow installing apps from unknown sources is turned off, users can install apps only from Google Play, not from unknown sources or through Android Debug Bridge (ADB). This is a different restriction from permission to enable debugging features.

Two switches affect app management differently: turning off Allow app uninstall also prevents administrators from uninstalling apps through Sophos Mobile. Test a recovery path for necessary app removals in advance. With Allow managing apps turned off, users cannot uninstall, disable or stop apps. They also cannot clear app caches or app data, or reset the Open by default setting. Account for this restriction when planning support and troubleshooting.

Allow disabling Google security scans lets users turn off Scan device for security threats. Sophos gives the Android help path Settings > Google > Security > Google Play Protect. Check the path on your own device; this permission is not a recommendation to disable scans.

System updates, accounts and time

Set the installation schedule under System update policy. No policy lets users choose the timing. Install automatically installs system updates automatically as soon as they are available. Install within maintenance window uses a daily automatic maintenance window; enter its start and end times. Postpone blocks non-security updates for 30 days, not security updates. Coordinate update timing separately; none of these options is established here as the preselected default.

Allow managing accounts permits adding and removing accounts on the device. Allow managing Google accounts permits this for Google accounts and is available only when Allow managing accounts is enabled. Turning off the parent permission also disables the Google accounts option.

Allow setting date and time lets users set the date and time themselves. Without this permission, the device uses the date and time from the network.

Communication and network settings

With Allow SMS turned off, users cannot send SMS messages. Allow outgoing phone calls permits outgoing calls. This does not establish how incoming messages or calls, emergency calls or carrier exceptions are handled. Allow configuring cell broadcasts permits turning cell-broadcast messages on or off in the messaging app; no particular alert categories are guaranteed here.

Turning off Allow mobile data connection while roaming disables cellular data connections while roaming. Without Allow VPN, users cannot use VPN connections; selecting and deploying a managed VPN client remains a separate topic. Turning off Allow Bluetooth prevents connections to new Bluetooth devices; connections to already paired devices remain possible.

Enable Wi-Fi settings, Enable cellular networks settings and Enable tethering settings respectively permit user changes to Wi-Fi, cellular network, and tethering/mobile hotspot settings. Allow network reset permits resetting network settings to their defaults. This is not the reversal of a cloud policy.

With Allow sharing of managed Wi-Fi connections turned off, users cannot share Wi-Fi connections configured by Sophos Mobile. This setting applies to Android 13 and later. Allow Android Beam, by contrast, applies only to Android 9 and earlier, not to other sharing technologies. Always verify the effect on the Android version actually in use.

Camera, microphone and USB media

Turning off Allow camera or Allow microphone makes the camera or microphone unavailable, respectively. These are device-wide restrictions, not individual responses to app runtime permissions. Allow external media permits connecting external media such as USB storage. Allow transferring files over USB, by contrast, permits file transfer between the device and external USB storage; connection and file transfer are separate permissions.

Support messages and accessibility

Short message is the organization-specific support message users see for disabled functions. Text longer than 200 characters may be truncated. Long message supplements it when users tap More details and also appears on the Android Device administrator page for Sophos Mobile Control.

Under Allowed accessibility services, All available apps permits all accessibility services, while Only system apps permits only those from system apps. An app-group allowlist permits the selected group members and still permits system apps. Validate accessibility requirements separately before restricting them.

Distinguishing this policy from compliance and other policies

The device policy with App Control or App Protection is not a compliance action. Compliance rules, Lock container, and Transfer task bundle have a separate owner; this article does not establish their exceptions, priority, deletion effects, or impact on private BYOD apps. Do not use a device-policy pilot as a compliance-action test. Confirm the applicable compliance action, mode, recovery and potential data loss in the separate compliance procedure before any intervention.

For Kiosk mode, the provisioning path and the required advance check of physical exit, see dedicated Android device preparation; it does not replace a verified exit on your own device. Wi-Fi, VPN and Global HTTP proxy require the separate managed Android connectivity procedure, especially if a change could affect management access. The other management mode uses the work profile policy, not this full-device procedure.

Distinguish three certificate configurations: Root certificate provides the trust anchor, Client certificate imports a PKCS #12 client certificate (.pfx), and SCEP lets the device request a certificate from the CA. The linked connectivity article explains Android-specific availability within the same policy and the distinction between SCEP server trust and EAP server trust. For SCEP, first provide the SCEP server’s CA certificate as a Root certificate in the same policy. The tenant-side prerequisites—a SCEP-capable CA, Fusion access to the issuance and challenge endpoints, the region-specific network path and SCEP renewal interval—belong to the SCEP connectivity and certificate pilot. Test issuance, renewal and recovery separately there; a SCEP configuration alone does not prove that Wi-Fi/VPN certificate assignment works. Merely listing these payloads in a device policy does not replace their respective security and rollout checks.