Android fleets are hard to secure because the same management framework has to cover personal phones, company-owned phones and single-purpose devices from many manufacturers, each on its own patch schedule. Android Enterprise solves the structural part with defined management modes (work profile, fully managed and dedicated devices), a Google-hosted Android Management API and zero-touch provisioning, but the security outcome still depends on which mode is chosen, which policies are set and how patch levels are enforced. This guide covers the management modes, provisioning, the main hardening policies, the Android security bulletin and patch level model, Play Integrity, migration away from legacy device admin, and how to protect the management plane itself. It is written for endpoint, mobility and identity teams. Version references were checked against Google's documentation in October 2026, when Android 17 (API level 37) was available and the latest bulletin was October 2026.
Key takeaways
- Mode decides privacy and control. A work profile on a personal device separates work data and keeps the personal side private; fully managed and dedicated modes give the organisation the whole device.
- Legacy device admin is not a security option. Its password and keyguard policies stopped working for apps targeting Android 10 (API level 29), so any remaining device admin deployment needs migration.
- Zero-touch enrolment ties devices to the organisation. Company-owned devices bought through an authorised reseller provision into management on first boot, and again after a factory reset.
- Patch level is the key compliance signal. Android security bulletins publish monthly, but each manufacturer ships them on its own schedule, so enforce a minimum security patch level, not just an OS version.
- Protect the console and its credentials. The EMM console and its service accounts can wipe every enrolled device, including the work profiles on personal phones.
Android Enterprise management modes
Under the Android Management API (AMAPI), the mode is set by the enrolment token's allowPersonalUsage value. Google's provisioning documentation describes four combinations:
| Mode | Ownership | Token setting | Minimum Android | Organisation controls |
|---|---|---|---|---|
| Work profile on a personally owned device (BYOD) | Employee | PERSONAL_USAGE_ALLOWED | 5.1 | Work profile apps, data and policies only; personal profile stays private; removing the work profile removes work data |
| Work profile on a company-owned device (COPE) | Organisation | PERSONAL_USAGE_ALLOWED (company-owned provisioning) | 8.0 | Work profile policies plus certain device-wide and personal usage policies; device-level commands affect the whole device |
| Fully managed device (COBO) | Organisation | PERSONAL_USAGE_DISALLOWED | Depends on provisioning method | Whole device: apps, settings, updates, wipe |
| Dedicated device (kiosk, shared, single use) | Organisation | PERSONAL_USAGE_DISALLOWED_USERLESS | Depends on provisioning method | Whole device, locked to a set of apps, no user account required |
With AMAPI, the Android Device Policy app is installed during enrolment and is the only device policy controller (DPC) that AMAPI supports. Organisations are represented as enterprises, which own policies, enrolment tokens and devices. EMM providers either build on AMAPI or maintain their own custom DPC on the platform's DevicePolicyManager APIs. See the UEM Buyer's Guide for evaluating providers.
Choosing a mode
- BYOD: work profile. It gives the organisation enough control over corporate data while respecting privacy, and the profile can be removed remotely without touching personal data. See the BYOD Policy Template.
- Company-owned, some personal use allowed: COPE. The organisation keeps device-level rights such as factory reset and device-wide update policy, while personal apps stay outside the work profile.
- Company-owned, work only, handling sensitive data: fully managed. Simplest to reason about and the strongest control over apps and settings.
- Frontline, kiosk and shared devices: dedicated mode. See the Kiosk and Shared Device Security Guide.
- Small versus large organisations: a small business can run work profiles on staff phones from a single EMM tenant with little hardware cost. Large organisations should standardise on zero-touch for company-owned devices and limit the number of approved manufacturers and models, which keeps patch tracking manageable.
Provisioning and zero-touch enrolment
| Method | Modes | Minimum Android | Notes |
|---|---|---|---|
| Zero-touch enrolment | Fully managed, dedicated, COPE | 8.0 (Pixel 7.1) | Devices bought from an authorised reseller and assigned in the zero-touch portal provision automatically on first boot |
| QR code | Fully managed, dedicated, COPE | 7.0 | Scanned during setup on a factory-fresh device |
| NFC | Fully managed, dedicated | 6.0 | Not supported for COPE provisioning on Android 11 |
| DPC identifier (afw#setup) | Fully managed, COPE | Not stated | Typed in place of a Google account when QR or NFC is not possible |
| Sign-in URL | Fully managed, COPE, work profile | Not stated | Not suitable for dedicated devices |
| Settings, Android Device Policy app or token link | Work profile on personal devices | 5.1 | User-initiated |
Zero-touch matters for security because the device's link to the organisation survives a reset. A registered device shows a "Your device at work" panel even after a factory reset, and if a user skips enrolment on a device that has a configuration, the device resets itself after first connecting to Google servers, with a one-hour warning. Removing a device needs a deregistration in the portal. The zero-touch portal has its own roles (Owner, Admin, Manager, Assigner, Viewer) and keeps audit logs for up to one year, so it is another privileged console to protect.
Hardening policies that matter
AMAPI policies are JSON documents applied per device or group. The fields below are the main security levers; enum values and availability differ by Android version and mode, so check the AMAPI reference for each.
| Policy area (AMAPI) | What it controls | Recommended baseline |
|---|---|---|
| advancedSecurityOverrides.untrustedAppsPolicy | Installation of apps from unknown sources (replaces the deprecated install_unknown_sources_allowed) | Disallow on company-owned devices and in the work profile |
| advancedSecurityOverrides.googlePlayProtectVerifyApps | Whether Google Play Protect verification is enforced | Enforce |
| advancedSecurityOverrides.developerSettings | Developer options and safe boot (replaces safeBootDisabled and debuggingFeaturesAllowed) | Disabled except on test devices |
| advancedSecurityOverrides.commonCriteriaMode | Common Criteria Mode, which strengthens some security components | Enable where a certified configuration is required; test first, as disabling it later can remove user-configured Wi-Fi |
| advancedSecurityOverrides.contentProtectionPolicy | Scanning for deceptive apps (Android 15 and later) | Enable |
| advancedSecurityOverrides.mtePolicy | Memory Tagging Extension on supported hardware (reboot required) | Pilot on high-risk users' devices |
| advancedSecurityOverrides.personalAppsThatCanReadWorkNotifications | Personal apps allowed to read work notifications | Leave empty (the default) |
| Password requirements with a policy scope | Separate screen lock rules for device and work profile | Strong device lock; work challenge on BYOD where needed |
| System update type | When OS updates install on company-owned devices | Automatic or a maintenance window, with a short postponement at most |
| Cross-profile policies | Data sharing between work and personal profiles | Block copy and paste and sharing from work to personal |
| USB data access | File transfer over USB | Disallow on company-owned devices |
| Play Store mode and app install type | Allowlist of managed apps, forced and blocked apps | Allowlist mode in the work profile; force install security and VPN apps |
| Compliance and policy enforcement rules | Actions (block, wipe) when a device falls out of compliance | Block access first, wipe the work profile only after a grace period |
For COPE devices, the blockScope setting decides whether a compliance action blocks the whole device or only the work profile. Remember that device deletion and device commands always act on the whole device. See the Mobile Device Security Guide for the policy layer.
Patching: bulletins, patch levels and OS versions
Google publishes the Android Security Bulletin on the first Monday of each month (or the next working day). The October 2026 bulletin, published on 5 October 2026, covered 25 CVEs, seven rated Critical (including elevation of privilege flaws in Bluetooth and NFC components) and 18 High, plus fixes delivered as Google Play system updates for Telephony and Wi-Fi. Each monthly entry carries two security patch level strings, for example 2026-09-01 and 2026-09-05; a device that reports the later string includes all fixes in that bulletin, including component fixes from chip vendors and kernel.
Google also changed how source code reaches the Android Open Source Project: platform fixes are merged into AOSP shortly after the quarterly bulletins (March, June, September and December), and in 2026 AOSP source publishing moved to Q2 and Q4. The practical consequence for enterprises is unchanged: the manufacturer's update is what matters, and manufacturers ship on different schedules.
- Enforce a minimum security patch level: block corporate access when the reported patch level is older than an agreed age (for example 90 days), and warn earlier.
- Buy for support life: check each manufacturer's published update commitment before approving a model; devices that stop receiving bulletins should leave the fleet.
- Use system update policy on company-owned devices: automatic or windowed installation, with postponement used only for testing.
- Track Google Play system updates: some fixes arrive through Play, independent of the manufacturer, so devices need Google Play services and network access to receive them.
See the Patch Management Guide.
Device integrity and app trust: Play Integrity
EMM compliance tells the organisation what the agent reports; Play Integrity lets an app backend check what Google can attest. Its verdicts include:
- appIntegrity: appRecognitionVerdict should be PLAY_RECOGNIZED, meaning the app is unmodified and signed with the certificate Google Play knows.
- accountDetails: appLicensingVerdict of LICENSED confirms the app was installed or updated from Google Play.
- deviceIntegrity: MEETS_BASIC_INTEGRITY, MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY, the last requiring hardware-backed signals and a recent security patch on Android 13 and later.
- Environment signals: appAccessRiskVerdict flags apps that can capture the screen, draw overlays or abuse accessibility; playProtectVerdict reports whether Play Protect is on and has found risky apps.
Google's guidance is that the backend, not the app, makes the decision: verify the token server-side, check the requestHash or nonce to prevent replay, do not cache verdicts, start in non-enforcing mode to learn the verdict distribution, and treat the API as one signal among several. The default quota is 10,000 requests per day. For enterprise apps, combining a STRONG integrity requirement for high-risk actions with EMM compliance gives a check that does not rely only on the management agent. See the Android App Security Guide.
Migrating from legacy device admin
Device admin was the original Android management API. Google deprecated it in favour of Android Enterprise:
| Android version | Change |
|---|---|
| 9 (API 28) | USES_POLICY_DISABLE_CAMERA, USES_POLICY_DISABLE_KEYGUARD_FEATURES, USES_POLICY_EXPIRE_PASSWORD and USES_POLICY_LIMIT_PASSWORD marked deprecated |
| 10 (API 29) | Those four throw a SecurityException for device admin apps targeting API level 29 |
| 11 | USES_POLICY_RESET_PASSWORD deprecated and stops functioning |
Google's migration path is a work profile for personal devices and fully managed mode for company-owned devices. Moving a company-owned device from device admin to fully managed needs a factory reset, so the usual approach is to enrol new devices as fully managed and retire old ones as they leave the fleet. Any device still on device admin has no enforceable password policy and should be treated as unmanaged for access decisions.
Where identity fits
- Managed Google Play accounts and the work profile: work apps and data sit behind enterprise accounts, so leaver processes in the identity provider must also remove the device's work profile or block it.
- Conditional Access: make access to corporate apps depend on a managed, compliant device with a current patch level. See the Conditional Access Guide and the Device Trust and Posture Guide.
- Management plane identities: EMM administrators, zero-touch portal users and the service accounts or API credentials that EMM integrations use to call AMAPI are privileged identities. Require phishing-resistant MFA, scope roles by device group, require approval for bulk wipes and rotate integration credentials. See the Privileged Access Management Guide.
Threats and controls
| Threat | MITRE ATT&CK | Android Enterprise controls |
|---|---|---|
| Phishing users into sideloading apps | T1660 Phishing (Mobile) | untrustedAppsPolicy, Play Store allowlist, Play Protect enforcement. See the Mobile Malware Guide. |
| Exploits of unpatched components | T1404 Exploitation for Privilege Escalation, T1456 Drive-By Compromise | Minimum patch level, system update policy, approved models only |
| Disabling or evading security apps | T1629 Impair Defenses (Mobile) | Force-installed security apps, developer settings disabled, Play Integrity checks |
| Physical access to a locked device | T1461 Lockscreen Bypass | Strong screen lock, USB data access disabled, zero-touch re-enrolment after reset |
| Abuse of the EMM console to wipe or push apps | T1072 Software Deployment Tools | Privileged access controls, approval for bulk actions, audit logging |
Implementation roadmap
- Inventory: list Android devices by ownership, mode, manufacturer, model, OS version and security patch level. Flag any device admin or unmanaged devices that reach corporate data.
- Set up the enterprise: bind the organisation to the EMM, set up managed Google Play, open the zero-touch portal with an authorised reseller and assign a default configuration.
- Define baseline policies per mode: BYOD work profile, COPE, fully managed and dedicated, each with the hardening fields above. Version them.
- Pilot: deploy to IT and a small business group on each approved model and OS version. Run Play Integrity in non-enforcing mode and compliance rules in report or block-only mode.
- Roll out in rings: expand by department, then switch compliance actions to blocking access, then to work profile wipe after a grace period.
- Migrate legacy devices: work profile for BYOD; fully managed at refresh for company-owned device admin devices.
- Harden the management plane: scoped roles, approval for bulk actions, separate break-glass access, alerts on new admins and new API credentials.
- Roll back safely: keep the previous policy version per group, so a faulty policy can be reverted for one ring; never test new compliance wipe rules on the whole fleet.
Detection and measurement
Collect EMM audit logs (admin sign-ins, policy edits, wipe and reset commands, enrolment token creation), zero-touch portal audit logs, device status reports for patch level and compliance, Play Integrity verdict failures from app backends, and identity provider sign-ins from Android devices that are not managed.
| Metric | Target |
|---|---|
| Corporate data access from devices in a supported management mode | 100% |
| Devices with a security patch level under 90 days old | Over 90% |
| Company-owned devices enrolled through zero-touch | Over 90% of new purchases |
| Devices still on device admin | Zero |
| Devices with unknown sources or developer options enabled | Zero outside test groups |
| Bulk wipe or policy actions without second approval | Zero |
Common failure patterns
- Measuring OS version instead of patch level: two devices on the same Android version can be many months apart in fixes. Patch level is the signal that matters.
- Approving models without support commitments: cheap devices that stop receiving bulletins after a short time leave a growing unpatchable population.
- Leaving device admin in place: its password policies no longer work on modern targets, so the console shows devices as managed when they are not.
- Allowing personal apps to reach work data: permissive cross-profile settings or notification listeners leak data out of the work profile.
- A single admin can wipe the fleet: in the Stryker Intune wiper attack a hijacked administrator identity used the legitimate management service to erase tens of thousands of devices, including staff-enrolled personal devices. The same risk applies to any EMM console.
- Enforcing Play Integrity in the app only: client-side checks can be bypassed; verdicts must be verified on the server.
Framework mapping
| Framework | Reference | Android Enterprise controls |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-19 Access Control for Mobile Devices | Management modes, Conditional Access, cross-profile policies |
| NIST SP 800-53 Rev. 5 | CM-6 Configuration Settings, CM-7 Least Functionality | AMAPI policies, advanced security overrides |
| NIST SP 800-53 Rev. 5 | SI-2 Flaw Remediation | Minimum patch level, system update policy |
| NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity | Play Integrity, Play Protect, verified apps |
| NIST SP 800-53 Rev. 5 | CM-8 System Component Inventory | Zero-touch portal and EMM inventory |
| NIST CSF 2.0 | ID.AM-01, PR.PS-01, PR.PS-02, DE.CM-09 | Inventory, baseline, updates, monitoring |
| CIS Controls v8.1 | Controls 1, 4 and 7 | Asset inventory, secure configuration, vulnerability management |
| ISO/IEC 27001:2022 | A.8.1 User endpoint devices | Mobile device policy and enforcement |
NIST SP 800-124 Rev. 2 provides the lifecycle guidance for managing organisation-provided and personally owned mobile devices.
Practitioner checklist
- Assign every Android device to a management mode that fits its ownership; remove device admin.
- Buy company-owned devices through an authorised zero-touch reseller and set a default configuration.
- Apply untrustedAppsPolicy, Play Protect enforcement and disabled developer settings to company-owned devices and work profiles.
- Block work-to-personal data sharing with cross-profile policies and leave personal notification access empty.
- Enforce a minimum security patch level in compliance rules and Conditional Access.
- Approve only models with a published update commitment, and retire devices that fall out of support.
- Verify Play Integrity verdicts server-side for sensitive enterprise apps.
- Protect EMM, zero-touch portal and AMAPI credentials as privileged identities, with approval for bulk wipes.
- Review the six metrics above monthly.
Standards and references
- Google: Android Management API introduction
- Google: Android Management API, Provision a device
- Google: Zero-touch enrollment for IT admins
- Google: Device admin deprecation
- Android: Android Security Bulletins
- Android Developers: Play Integrity API overview
- NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
Related NHI Mgmt Group resources: Mobile Device Security Guide · iOS and iPadOS Enterprise Security Guide · Mobile Threat Defense Buyer's Guide · OWASP Mobile Top 10 Guide · UEM Buyer's Guide