Android work profiles: Check policy effects and BYOD boundaries

The Android Enterprise work profile policy in Sophos Mobile applies to devices in Android Enterprise work profile management mode. It includes password, restrictions, app, Google Play, and email configurations, among others. The policy is relevant to BYOD, but its name does not guarantee that every setting affects only the work profile. This draft describes documented effects; it is not an approved policy template and provides no recommended thresholds.

BYOD stop: Do not assign a sign-in-attempt wipe threshold in production or allow contacts and data to flow between work and personal areas without privacy and data-loss approval. Check backups and recovery paths beforehand, explicitly accept the remaining risk to personal data, and test the effects on the affected Android versions and devices. Sophos documentation guarantees neither rollback nor preservation of personal data.

Key distinction: Device lock (Android 11 and earlier): an available and configured failed-attempt threshold can wipe the entire device. Work-profile lock: an available and configured failed-attempt threshold deletes the work profile. Administrative wipe actions are a separate, console-dependent context—not a consequence of these failed-attempt thresholds.

Device and work-profile locks: What gets deleted, and when?

Password policies – Device: These settings affect the screen lock for the entire device. For Android 12+, Sophos describes Low/Medium/High complexity, but no Maximum sign-in attempts field there. Before relying on this device lock, consult SMCAND-3170. The older Password policy - Device does not prompt for a device password on work-profile devices running Android 12 or later if no device password has been set. Sophos lists the replacement configuration for Android 12, introduced with Sophos Fusion Mobile release 2024.24, and the installed Sophos Mobile Control version 9.7.10339 as prerequisites. This does not establish confirmed compatibility with all later client versions. Before approval, verify the appropriate configuration and client version, as well as the actual password prompt and lock behavior, on the test device; the saved policy alone does not demonstrate them. On Android 11 and earlier, Sophos shows this field only for Simple password, PIN or password, Alphanumeric password, and Complex password, not for Pattern, PIN or password: after the configured number of incorrect sign-ins, the device is wiped—not just the profile. Do not recommend a failed-attempt value as a default for personal devices; first clarify personal backups, potential data loss, exact OS/device effects, and consent.

Separate the device-lock settings by Android version:

• Android 12+: Minimum password complexity has fixed rules: No requirements imposes no password restrictions; Low allows a pattern or PIN. Medium allows a PIN with at least four digits or an alphabetic or alphanumeric password with at least four characters. High allows a PIN with at least eight digits or an alphabetic or alphanumeric password with at least six characters. Only Medium and High exclude PINs with repeated or ordered sequences, such as 4444, 1234, 4321, or 2468. These levels are not freely configurable legacy character-count fields.
• Android 11 and earlier: Under Password type, Pattern, PIN or password requires a screen lock using a pattern, PIN, or password without additional restrictions. Simple password requires at least one letter; digits are allowed. PIN or password allows a PIN or password; Alphanumeric password and Complex password require both letters and digits.
• The shared fields appear only for the last four types: Minimum password length sets the minimum number of characters. Maximum idle time before password prompt locks the unused device after the configured time; the password unlocks it again. The device may enforce a shorter time. Maximum password age in days requires a change at the specified interval of 0 to 730 days; 0 means no change is required. Password history sets how many previously used passwords Sophos Mobile stores; these cannot be reused when setting a new password. The destructive Maximum sign-in attempts threshold described above is also shown only for these four types.
• Only Complex password shows six additional, separate minimum-count fields: Minimum number of letters, Minimum number of lowercase letters, Minimum number of uppercase letters, Minimum number of non-alphabetic characters, Minimum number of digits, and Minimum number of special characters. These set the respective minimum counts of letters, lowercase letters, uppercase letters, non-alphabetic characters, digits, and special characters.

Password policies – Work profile: The unlock password belongs to the work profile. Maximum sign-in attempts is shown for Simple password, PIN or password, Alphanumeric password, and Complex password, not for Pattern, PIN or password or Weak biometric recognition. After the configured number of incorrect sign-ins, the work profile is deleted, including its apps and data. The actual availability of individual settings also depends on the device and Android version; Sophos points to the labels in Mobile Admin. Plan for work-data recovery and re-enrollment in advance; this is neither a device reset nor a lock without consequences.

For the work-profile lock, Password type offers six options:

• Pattern, PIN or password: a pattern, PIN, or password without additional restrictions.
• Simple password: a password with at least one letter; digits are allowed.
• PIN or password: a PIN or password.
• Alphanumeric password and Complex password: a password with letters and digits.
• Weak biometric recognition: weak biometric methods such as facial recognition to unlock the work profile. Sophos compares their security with a three-digit PIN: the English text describes possible unauthorized unlocking in one out of 1000 attempts, while the German text describes approximately 1000 attempts being required. This is a comparison in the documentation, not a guaranteed number of successful attempts or a probability tested on the target device.

Only Simple password, PIN or password, Alphanumeric password, and Complex password show the following fields alongside Maximum sign-in attempts: Minimum password length for the minimum character count; Maximum idle time before password prompt for locking the unused work profile, which is unlocked again with the password (the device may enforce a shorter time); Maximum password age in days for a change after 0 to 730 days (0: no change required); and Password history for the number of stored previous passwords that cannot be reused when setting a new password. Only Complex password adds six separate minimum-count fields: Minimum number of letters, Minimum number of lowercase letters, Minimum number of uppercase letters, Minimum number of non-alphabetic characters, Minimum number of digits, and Minimum number of special characters—for letters, lowercase letters, uppercase letters, non-alphabetic characters, digits, and special characters. These fields affect the work profile, not the device-wide screen lock.

Administrative offboarding:

• Sophos Mobile Admin: A full remote Wipe is not available for work-profile devices. Wipe Android work profile removes the work profile, including its apps and data; afterwards, Mobile Admin shows the device as Unenrolled. If the user has already removed the profile, the device can no longer receive the command.
• Sophos Fusion Admin: According to Sophos, the action called Wipe there removes only the profile on work-profile devices. The Android task-bundle Wipe also has a profile-specific exception. Neither action is a consequence of the device-lock failed-attempt threshold.

Before destructive actions, confirm the console, management mode, task type, and target device with the person responsible for offboarding; the action name does not guarantee preservation of personal data.

Fully managed Android Enterprise device management is a different mode: Sophos describes a factory reset on unenrollment in that mode. It is not the BYOD work-profile default.

Separate compliance policy: This device configuration is not a compliance policy. Separately assigned compliance rules can deny email access through Deny email (available only when a connection to the Sophos Mobile EAS proxy is configured) or deploy a task bundle; Sophos warns that incorrectly configured bundles can wipe devices. The general overview of compliance actions describes Lock container for Android Enterprise as locking all apps with six exceptions; its separate statement about disabled apps explicitly applies to fully managed devices. For work-profile devices, by contrast, Sophos describes under Set container access / Auto mode a rule violation with Lock container as locking the work profile, its apps, and its notifications. These descriptions do not establish whether a compliance action locks personal apps on a specific BYOD work-profile device or leaves them usable. Check the effect on personal apps on the specific work-profile device before obtaining consent and enforcing the rule. The failed-attempt deletion consequence above is not a blanket compliance action. Before a BYOD pilot, review the rules, actions, and bundles assigned to the device group separately with the responsible parties—do not infer automatic remediation or a safe baseline here.

Restrictions: Trace data flows instead of assuming “work only”

Restrictions is added automatically when a work-profile policy is created and cannot be removed. Before changing a setting, document which direction data flows, who is affected, and how the change will be monitored and reversed.

• Clipboard and web links

  Allow work clipboard in personal apps permits copying from work to personal apps; according to Sophos, copying from personal to work remains possible in all cases. Allow opening web links in personal apps permits opening work links in a personal browser. Both options require a data-flow and privacy decision. This directional work-profile permission is not the older combination of a master clipboard switch and a shared or app-specific clipboard.

• Contacts and calls

  Allow work contact info for personal calls allows the personal phone app to display the caller’s name for incoming calls from work contacts. This permission crosses the work-profile boundary.

• Bluetooth caller display

  Allow work contact info for Bluetooth devices allows connected Bluetooth devices to display the caller’s name for incoming personal calls from work contacts. The setting controls neither Bluetooth connections nor individual Bluetooth profiles; the work-profile documentation reviewed here does not list a master Bluetooth switch or such profile controls.

• Contact search

  Allow searches of work contacts in personal profile allows the personal phone app to include results from work contacts when searching for caller names. Like the two caller-display permissions, this is not a setting confined to the work profile.

• Device lock

  Allow Smart Lock allows users to enable Smart Lock, which automatically unlocks the device in certain situations. The setting affects the device lock and is ignored if a work-profile lock is configured. Allow unlocking device by fingerprint allows device unlocking via the fingerprint sensor; this is separate from profile or app authentication.

• Location

  Allow location services governs sharing the device’s location with work-profile apps and services. If disabled, Sophos says location services are turned off; users cannot turn them back on themselves, and Sophos Mobile cannot locate the device. Test effects on personal apps and reversibility on the specific device rather than making a blanket claim.

• Screenshots

  Allow screen capture allows users to take screenshots of apps installed in the work profile. Do not infer anything about screenshots of personal apps from this.

• Certificates

  Allow user to configure credentials allows users to install or remove certificates in the work profile. This is not a password manager setting and does not replace certificate deployment.

• Accounts

  Allow managing accounts allows users to add or remove accounts in the work profile; this is not the provisioning of an Exchange account through the policy. Separate older fields for multi-user operation, adding email accounts with an exception for policy-created accounts, removing the Google account, and automatic versus manual synchronization are not individually listed in the work-profile catalog reviewed here. Do not carry over their exceptions or device-wide effects.

• VPN

  Allow VPN allows users to use VPN connections for apps in the work profile. Do not infer permission or blocking for all device traffic from this; check the VPN configuration separately.

• Camera

  Allow camera allows apps in the work profile to access the camera; runtime permissions remain a separate item to check. The work-profile catalog reviewed here contains neither a separate lock-screen camera field nor its older dependency on the master camera switch. Do not infer device-wide camera or lock-screen blocking from this.

• App installation

  If Allow installing apps from unknown sources is disabled, users can install apps in the work profile only from Google Play, not from unknown sources or via Android Debug Bridge (ADB). This is not App Control’s launch blocking and does not establish a complete USB/ADB block. Allow debugging allows users to enable debugging functions in the Android developer options; the older Sony linkage to all developer options starting with Enterprise API Level 9 is not described here.

• Vendor-specific system apps

  Enable vendor-specific system apps makes such apps, for example Samsung Calendar, available in the work profile. This does not establish app deployment or equivalence with older vendor features. The older Knox settings prerequisite, activation lock, S Beam, S Voice, and “Share via” are not documented as corresponding fields in this work-profile catalog.

• App removal

  If Allow app uninstall is turned off, even administrators cannot uninstall work-profile apps through Sophos Mobile.

• App management

  If Allow managing apps is disabled, users cannot uninstall, disable, or stop work-profile apps, clear either app caches or app data, or clear the Open by default setting. The separate Allow app uninstall setting has the additional limitation for administrators mentioned above; do not extend this to all app management actions.

• Managed Wi-Fi

  Allow sharing of managed Wi-Fi connections applies only from Android 13 onward. If disabled, users cannot share Wi-Fi connections configured by Sophos Mobile with other devices. Review VPN, Wi-Fi, and certificate configurations separately.

• Google security scans

  Allow disabling Google security scans allows users to turn off Scan device for security threats under Settings > Google > Security > Google Play Protect. This describes the permission, not a recommendation to disable scanning.

• Support messages

  Short message is a company support message displayed when a function is disabled; it may be truncated if it exceeds 200 characters. Long message supplements it through More details and also appears on the Android Device administrator page for Sophos Mobile Control.

Allow Android Beam permits sharing content via Android Beam, which is available only in Android 9 and earlier. The setting does not apply to Quick Share or other sharing technologies and is not a general permission or block on data sharing. The older launch switch for Samsung S Beam is a different field; neither it nor Android Beam establishes control over Quick Share. Therefore, do not treat Android Beam as a modern mandatory control.

These field meanings come from the documented work-profile catalog reviewed here. This does not mean that older fields not listed are unavailable on every OS, vendor device, or tenant; actual availability must still be checked separately.

Other settings and their limits

Before assigning a policy, ask in each case: What affects only the work profile, and what must be deployed or checked separately?

• App Control: In the App group field, select the intended saved Android app group. Its members are the apps that must not be launched. The next section shows how to create the group. This is neither app installation nor a demonstrated block on all personal apps; check group membership and launch behavior on a test device. Before specifically blocking Chrome, check the WebView dependencies of the work apps. In SMCAND-2931, Sophos describes a work-profile scenario on Android 8 and later in which the internal WebView app is disabled by default and is enabled only when Chrome is enabled. Otherwise, dependent apps may stop working. This reported issue does not establish behavior on every current device or every later Android version; test the affected apps on the intended test device.
• App permissions: Only runtime permissions for work apps can be controlled. Under Default response for runtime permission requests, Prompt requests user approval, Auto-accept grants permissions automatically within platform limits, and Auto-deny denies them automatically. Auto-accept/Auto-deny prevents users from changing the permissions later. Under App-specific runtime permissions, use Add to select an app and configure each permission individually: Selectable lets users change the permission, Granted grants it, and Denied denies it. The following applies to both granting options: from Android 12 onward, management cannot grant location, camera, microphone, body sensors, or physical activity permissions on a user’s behalf, but it can deny them. Accessibility and battery optimization may still prompt users. Check defaults and app exceptions for each OS version.
• App Protection: A shared password for selected work apps is not complete access control: access through other apps or system functions, and in multi-window mode, may bypass this prompt. Users set the shared password when first opening a protected app. Password complexity defines requirements such as minimum length and required characters; do not infer a specific combination from this. Grace period in minutes is the period during which users can open a protected app without a password after closing a protected app. Allow fingerprint authentication allows a fingerprint instead of the password, not as a second required factor. The saved Android app group selected under App group determines the protected apps; reuse the next section to create it and check membership and app identity. The existing Add configuration/Edit/Save steps in the approval section also apply to App Protection. Test the app group, grace period, and alternative access paths before use. If Sony Small Apps are included in testing, do not promise that Sophos Mobile Control or App Protection can protect or control these overlay apps; see SMCAND-2927.
• Google Play: Available apps controls access in the Play Store of the work profile: Approved apps from managed Google Play restricts it to apps approved for the organization; Apps from Google Play allows the same apps as on unmanaged devices. Auto update apps offers four options: Over any network updates automatically over Wi-Fi or mobile data; Over Wi-Fi only updates only when connected to Wi-Fi; Don’t update apps automatically turns off automatic updates; and Use device setting lets users configure automatic updates in the Play Store. Approval, deployment, and removal of apps are separate processes.
• Password services: Password managers are restricted only in the work profile. Under Mode, Allow permits only managers from the Android app group selected in App group; Block permits all available managers except those selected. The group must contain the intended password managers; reuse the next section to create it and check membership and identity. Allow system apps is optional and available only with Allow: it additionally permits the device manufacturer’s default password managers, not all system apps. To permit only the manufacturer’s default, select Allow and Allow system apps and do not select a group under App group (leave the field empty, rather than selecting a group with no members). This does not guarantee that a manufacturer-provided manager is present. Check access and recovery before using restrictive lists.
• Email account: Sophos configures an Exchange account in Gmail in the work profile. Managed configuration for the Gmail app is unavailable in recent Sophos Mobile versions because it conflicts with Email account. Existing older managed Gmail configurations take precedence, even if empty. Placeholders require an Exchange login and email address in Sophos Fusion; for Gmail with OAuth, Chrome must be installed in the work profile. Before deployment, check the assigned user’s fields in Sophos Fusion under My Environment > Users & Groups > Users > Summary > Edit: Email Address and Exchange Login, then use Save for authorized changes to editable fields. Although Exchange Login is generally optional, it is required for the placeholders used here. For AD-imported accounts, do not change account data in the generic editor; involve the directory administrators instead. Do not infer a blanket editing restriction for all Entra ID users. After the ADSync Utility changes the Exchange login, compare the Fusion value with the actual Mobile user object before deployment. The historical paths People and Mobile > People and the literal $username come from SMCSRV-15474; they are not the current Fusion user navigation. Validate access on the Mobile side separately rather than inferring it from the Fusion path. $USERNAME and $EMAILADDRESS are managed-app tokens; %_USERNAME_% and %_EMAILADDRESS_% are policy tokens. Do not substitute $username for them. According to SMCSRV-15474, Mobile may retain the old value and consequently transmit incorrect placeholder values. If the values differ, stop deployment and resolve the discrepancy with the responsible parties. Sophos describes weekly reconciliation at tenant-dependent times, not a guaranteed resolution deadline. Reversal is also limited: according to SMCAND-2929, a deployed Exchange account remains in the work profile when the policy is removed. Another Email configuration can replace the existing configuration; according to this reported issue, the account itself can only be removed by removing the entire work profile. The precedence rule for older Gmail configurations noted above must still be observed. This does not authorize profile removal; that remains a separately approved, destructive offboarding case involving the loss of work-profile apps and data. Clarify the cloud endpoint, EAS compatibility, and certificate validation separately with the mail team. Exchange Online does not accept Basic authentication for EAS; the Sophos selections Basic and Allow all certificates are not authorization to use them as workarounds.

Agree the Email account fields with the mail team beforehand:

Policy placeholders are populated on assignment from the assigned user: %_EMAILADDRESS_% from Email Address and %_USERNAME_% from Exchange Login. Check the account name, signature, and token values before approved deployment; saved fields do not prove a successful sign-in.

Create an Android app group for App Control

An app group is a list of selected apps for policies. The following English UI labels match the documented interface; the procedure was not performed in the target tenant.

1. Under App groups, select the Android platform and click Create app group. On Edit app group, enter a group name of your choice, for example BYOD-Test-Startblockade, and open Add app. The example name is arbitrary and does not designate a recommended blocklist.
2. Under App list, select an app from the list of apps currently installed on managed devices. To enter the app details manually, select Custom instead. This inventory list does not establish visibility into personal apps.
3. For Custom, enter the app’s Google Play URL in the Link field. Obtain link opens Google Play; go to the intended app’s page there and copy its link. After pasting it, use Get data to populate the App name and Identifier fields automatically.
4. App name is a unique name used to identify the app, and Identifier is its internal identifier. For apps from Managed Google Play for Android Enterprise, the package name must be preceded by the prefix app:. Before adding the app, check that the link, name, and identifier belong to the intended app.
5. Use Add to add the selected or manually entered app. Repeat the steps for additional members and save the group with Save.

The saved group can then be selected in the App group field of App Control described above. These steps describe an app list, not app deployment. The documented launch blocking does not establish installation prevention or device-wide blocking. After the policy is saved, the approval and device checks in the next section still apply.

Approve only after testing on a device

Record the management mode, Android version, device/manufacturer behavior, Sophos edition/tenant, target device and group, and separate compliance rules. Before every change, record the existing policy, settings, version, and assignment for the affected test scope; check backups and recovery paths. Observe delivery and effects on a consenting, expendable test device containing personal test data.

A policy for Android Enterprise work profiles is created under Policies > Android > Create using the appropriate policy type. On Edit policy, enter a name and description. Use Add configuration to add the required configurations, then click each configuration’s name to edit its settings. Once all required configurations have been added and edited, save the policy with Save. These UI steps are documented but have not been verified in the target tenant. Only after approval, assign it specifically to a selected test device or test group: under Policies > Android, open the blue triangle next to the policy, select Assign, choose the consenting test device on Select devices or the approved test group through Select device groups, and complete the process with Finish. Before the pilot, check the organization’s already connected Android Enterprise account and enrollment mode under Setup > Google setup > Android Enterprise; if the connection is missing, hand off setup separately. Check the Sophos Mobile Control requirements current for the pilot; do not use the potentially different Intercept X requirements as evidence for App Protection. Android Go is not supported; general Control support is not a promise of App Protection or fingerprint support. Assignment in the console alone does not prove an effect on the device: wait for connection/synchronization and check the policy version and status on the target device, separately for Google API and the MDM agent in Sophos Fusion where applicable. Plan profile removal only as a separate, destructive offboarding case.

Define reversal in advance: A work-profile policy cannot be uninstalled via Uninstall policy; instead, update it using the documented previous settings or assign another policy that has already been tested. Changes to this policy type synchronize the next time the device connects to Sophos Mobile, not through the Update devices path used for older Android device policies. After the connection event, recheck the assignment, version, component status, and actual device behavior. If the device does not connect, a component reports a discrepant status, or the effect persists, do not report the reversal as complete or assign the policy in production. Changing a policy does not retrieve data already copied to the personal area or restore deleted work-profile or device data.

Non-destructive example: For an approved change to clipboard permissions, copy test text from a work app to a personal app; only the previously expected data flow should occur. Then follow the defined update or replacement-policy path and test again with new text after synchronization is confirmed. If behavior differs from expectations or permission remains effective, do not assign the policy in production; consult the privacy and mobile teams. Do not test failed-attempt wipe thresholds on personal devices.

Without demonstrated effects, tested recovery paths, and acceptance of remaining data-loss risks, do not assign or recommend a policy for production. Enrollment/BYOD consent, app deployment, Wi-Fi/VPN/SCEP, Exchange authentication, policy assignment, and destructive offboarding remain separate areas of responsibility.