“Android in Intune” is not one thing. It is four distinct management modes, each with its own enrollment flow, its own app delivery surface, and its own wipe semantics. Pick the wrong one for a device-ownership scenario and you either over-manage a personal phone (and lose the privacy argument with your workforce) or under-manage a shared kiosk (and watch it walk out the door logged into a browser). This guide builds all four modes end to end – personally-owned work profile, fully managed, dedicated/kiosk, and corporate-owned work profile (COPE) – and wires up the Managed Google Play connection, app config, OEMConfig, and Conditional Access that make them production-grade.
Scope note: this is about Android Enterprise, the modern Google-backed management stack. Legacy Device Administrator (DA) enrollment is deprecated by Google, blocked on Android 16 by default, and you should be actively migrating off it. Nothing here uses DA.
1. The four modes, and choosing per ownership scenario
Android Enterprise splits cleanly along two axes: who owns the device, and whether there is a single primary user. Internalize this table before you touch the portal – the mode dictates everything downstream.
| Mode | Ownership | Primary user | What’s managed | Wipe scope |
|---|---|---|---|---|
| Work profile (personally-owned) | User (BYOD) | Yes | Only the work container | Work profile only – personal data untouched |
| Fully managed (COBO) | Corporate | Yes | Entire device | Whole device |
| Corporate-owned work profile (COPE) | Corporate | Yes | Whole device + a separable work container | Work profile or whole device |
| Dedicated (COSU) | Corporate | No (shared / no user) | Entire device, locked to task(s) | Whole device |
The acronyms are Google’s: COBO (company-owned, business only), COPE (company-owned, personally enabled), COSU (company-owned, single use). The decision tree is short:
- Personal phone, employee resists enrollment -> work profile. You manage a container; the OS, camera roll, and personal apps are invisible to you.
- Corporate phone, one assigned employee, no personal use expected -> fully managed.
- Corporate phone, one assigned employee, you want to allow sanctioned personal use -> COPE. It is fully managed at the device layer with a privacy-respecting work profile on top.
- Shared device, kiosk, frontline, no per-user identity -> dedicated.
A common mistake is reaching for COPE because “corporate phone” feels like it should have a work profile. If users will never put personal apps on it, fully managed is simpler and gives you full restriction control without the container boundary getting in the way. Reserve COPE for the genuine “company phone you may also use personally” case.
2. Connect Managed Google Play and the enrollment-token model
Every Android Enterprise mode rides on Managed Google Play (MGP). This is the one-time tenant bind that creates the Enterprise.
Go to Intune admin center -> Devices -> Enrollment -> Android -> Managed Google Play, tick the agreement, and click Launch Google to connect now. Sign in with an account that will become the MGP “organization” owner.
Use a tenant service account (e.g.
androidenterprise@kv.onmicrosoft.com), not a personal Gmail and not a leaver’s account. The binding is owned by that identity; if it’s a person who departs, recovering the connection is painful. The account does not need a license.
Once bound, the app sync between Intune and MGP runs automatically (you can force it from Apps -> Android -> Sync). Every Android Enterprise app you approve in MGP flows into Intune as an app object you can assign.
The enrollment plumbing differs by mode:
- Work profile and COPE / fully managed (account-driven personal flows) can use the Authenticator/Company Portal app to drive enrollment with the user’s Entra credentials.
- Fully managed, dedicated, and corporate-owned work profile are corporate-owned and use an enrollment token plus an enrollment profile that you create per scenario. The token is materialized as a QR code, an alphanumeric
afw#setuphash, an NFC bump, or a zero-touch / Knox Mobile Enrollment assignment.
Create the corporate enrollment profiles under Devices -> Enrollment -> Android -> Corporate-owned devices. You build a separate profile object for fully managed / COPE (one wizard, you pick the management mode) and for dedicated devices. Each profile yields a token and QR you apply at the device’s out-of-box setup.
Enrollment token surfaces (factory-reset device, OOBE):
- Tap the start screen 6-7 times -> camera opens -> scan the profile QR
- Or type "afw#setup" at the Google sign-in -> install Android Device Policy -> scan QR
- Or NFC bump from a pre-provisioned device
- Or zero-touch (Google) / Samsung Knox Mobile Enrollment auto-assigns the profile
3. Personally-owned work profile: enrollment, app sync, data separation
This is the BYOD mode. The device gets a work profile – a cryptographically separated container with its own apps, its own copy of Play, and a badge overlay on work app icons. You see nothing outside the container.
There is no enrollment token here. The user installs Intune Company Portal from Play, signs in with their Entra credentials, and taps through Set up work profile. Conditional Access can require this. To allow it, confirm enrollment is not blocked: Devices -> Enrollment -> Enrollment device platform restrictions -> Android Enterprise (work profile) must permit personally-owned devices.
Apps reach the container only through Managed Google Play assignment. In Apps -> Android -> Add -> Managed Google Play app, approve the app, then assign it. For required apps choose Available with or without enrollment or Required as appropriate; the app installs into the work side only.
The data-separation controls live in a work profile device restriction profile (Devices -> Configuration -> Create -> Android Enterprise -> Personally-owned work profile -> Device restrictions):
- Copy and paste between work and personal profiles -> Block
- Data sharing between work and personal profiles -> Apps in work profile can handle sharing request from personal profile (or block outright)
- Contact sharing via Bluetooth -> Block (stops work contacts leaking to a personal car kit)
- Screen capture -> Block
Because the device is personal, your restriction surface is deliberately small – you cannot set a device-wide passcode policy, only a work profile password complexity. That is the privacy contract: you secure the container, the user owns the phone.
4. Fully managed and corporate-owned work profile (COPE) enrollment
Both are corporate-owned and start from a factory-reset device driven by an enrollment token.
Fully managed (COBO): create the corporate-owned enrollment profile and choose Fully managed as the management mode. On the reset device, run any token surface from section 2. The whole device enrolls as the work device – no personal container, full restriction authority.
Fully managed enrollment, condensed:
1. Factory reset (or first power-on of a new device)
2. Connect Wi-Fi, then trigger the token (QR / afw#setup)
3. Android Device Policy installs, applies the profile
4. Device appears in Intune as "Corporate, Android (fully managed)"
Corporate-owned work profile (COPE): create the corporate-owned enrollment profile and choose Corporate-owned work profile. Same token flow on the reset device; the difference is that after device-level provisioning, a work profile is created on top. You manage device-wide settings (passcode, factory-reset protection, system update policy) and a separate work container with its own app restrictions.
The COPE nuance that bites teams: you author two restriction profiles, one targeting the device scope and one targeting the work profile scope, because the platform separates them. Set personal-side limits (e.g. block adding personal accounts, or cap which personal apps are allowed) in the Fully managed, dedicated, and corporate-owned work profile device restriction template, and work-container relocation controls in the work-profile portion. Don’t expect a single profile to govern both halves.
Mark devices as corporate during/after enrollment so wipe and inventory semantics are correct. Token-enrolled devices are corporate by default; if you ever side-load a personal enrollment you can flip ownership under Devices -> All devices -> select -> Properties -> Device ownership -> Corporate.
5. Dedicated devices: kiosk, Managed Home Screen, single/multi-app
Dedicated (COSU) devices have no user affinity – no Entra user signs in during enrollment. Think warehouse scanners, digital signage, clinical carts.
Create a dedicated corporate enrollment profile (Devices -> Enrollment -> Android -> Corporate-owned dedicated devices -> Create profile), generate the token/QR, and enroll the reset devices with it. Then build a device configuration profile of type Device restrictions for the Dedicated template, where the Device experience page controls the kiosk:
- Kiosk mode = Single app -> the device boots straight into one app and is locked there. Ideal for a single-purpose scanner. Pick the app (it must already be assigned via MGP).
- Kiosk mode = Multi-app -> the device shows the Managed Home Screen (MHS), a Microsoft-built launcher, with a curated grid of allowed apps.
For multi-app, deploy and assign the Managed Home Screen app from Managed Google Play, then drive its behavior with an app configuration policy targeting that app. Useful MHS keys:
{
"kioskModeManagedHomeScreenSignInEnabled": true,
"kioskModeManagedSettingsEntryEnabled": "true_with_settings",
"kioskModeWifiAllowedConfigureNetworks": "true_with_password",
"kioskModeBluetoothConfiguration": "true",
"kioskModeFlashlightConfiguration": "true",
"kioskModeExitCode": "1234",
"kioskModeScreenSaverImageUrl": "https://cdn.kv.example/signage/idle.png"
}
The exit code is your support back door. Without
kioskModeExitCode, a field tech cannot break out of MHS to triage a device, and your only recovery is a remote wipe. Set it, store it in your PAM vault, and rotate it if it leaks.
The dedicated device restriction profile is where you lock the rest down: disable the status bar, block volume changes, force a Wi-Fi network, and set screen timeout. With Single-app + a barcode scanner app, the device is effectively appliance-grade.
6. App deployment via Managed Google Play and app config policies
All four modes share the same app pipeline: approve in MGP -> assign in Intune -> configure with an app configuration policy.
Three app categories flow through MGP:
- Store apps – public Play apps you approve.
- Web links – a URL packaged as a web app icon (handy for kiosks pointing at an internal portal).
- Private apps – your line-of-business APKs published privately to your Enterprise (or a managed Google Play store listing), visible only to your tenant.
Once assigned, push settings into the app with Apps -> App configuration policies -> Add -> Managed devices. Use this to silently configure apps so users never see a setup screen. The canonical example is Microsoft Outlook auto-config:
{
"com.microsoft.outlook.EmailProfile.AccountType": "ModernAuth",
"com.microsoft.outlook.EmailProfile.EmailAddress": "{{mail}}",
"com.microsoft.outlook.EmailProfile.EmailUPN": "{{userprincipalname}}",
"com.microsoft.outlook.Mail.FocusedInbox": "false",
"com.microsoft.outlook.Mail.BlockExternalImagesEnabled": "true"
}
The {{mail}} and {{userprincipalname}} tokens are Intune-substituted at delivery, so one policy provisions the right mailbox for every user. App config keys are vendor-defined – read them from the Managed configurations the app publishes; Intune surfaces them in the Use configuration designer view, which is safer than hand-writing JSON because it validates against the app’s schema.
7. Device restriction profiles and OEMConfig
The built-in Android Enterprise restriction profiles cover the AOSP and Google management surface. They do not cover vendor-specific hardware: Samsung Knox toggles, Zebra MX scanner settings, the second SIM on a Honeywell device. That gap is filled by OEMConfig.
OEMConfig is an industry standard where the OEM ships a configuration app (e.g. Knox Service Plugin, Zebra OEMConfig) to Managed Google Play. You assign that app, then create an app configuration policy against it – the OEM’s proprietary settings appear as schema-driven keys. This is the supported path; do not chase deprecated vendor SDKs.
OEMConfig flow (Samsung example):
1. Approve "Knox Service Plugin (KSP)" in Managed Google Play
2. Assign KSP as Required to the device group
3. Apps -> App configuration policies -> Add (Managed devices) -> target KSP
4. Configure Knox-only settings (e.g. disable USB host storage,
enforce DeX restrictions, set Knox license)
5. KSP applies them via the Knox API on the device
OEMConfig changes can be silent until the OEM agent next polls. After assigning, give it a beat and confirm on a pilot device before broad rollout – a mis-set Knox key (e.g. disabling all USB) is annoying to back out of on locked-down hardware.
8. Compliance, Conditional Access, and wipe semantics
A compliance policy for Android Enterprise (Devices -> Compliance -> Create -> Android Enterprise -> pick the management type) sets the bar: minimum OS, no rooted/compromised device (Play Integrity / SafetyNet attestation), required threat level if you run Microsoft Defender for Endpoint on the device, and required encryption/passcode. Mark non-compliant after a grace period so a freshly enrolled device isn’t blocked mid-setup.
Conditional Access then gates real access. The canonical policy requires a compliant device for M365 access from Android:
Conditional Access policy: "Require compliant Android for M365"
Users: All users (exclude break-glass accounts)
Target resources: Office 365
Conditions: Device platforms = Android
Grant: Require device to be marked as compliant
(use OR for app protection policy on BYOD)
For BYOD/work-profile devices you typically pair “require app protection policy” with compliance so personal phones satisfy access via the container rather than full device compliance.
The most important operational distinction is what you can wipe, and it is mode-dependent:
| Action | Work profile | Fully managed | COPE | Dedicated |
|---|---|---|---|---|
| Retire (remove work data) | Removes the work profile, leaves personal data | Factory resets (no personal data exists) | Removes the work profile, device stays managed/usable | Factory resets |
| Wipe (factory reset) | N/A – you don’t own the device | Full factory reset | Full factory reset | Full factory reset |
This is the payoff of choosing the right mode: on a personal phone, Retire surgically deletes only corporate data and the employee keeps their photos and apps. On a corporate device, Wipe is a clean factory reset. COPE gives you both options – pull just the work profile when an employee leaves but the device is reassigned, or full-wipe a lost unit.
# Retire (remove corporate data) a device via Microsoft Graph PowerShell.
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.PrivilegedOperations.All"
$device = Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'KV-WAREHOUSE-07'"
Invoke-MgRetireDeviceManagementManagedDevice -ManagedDeviceId $device.Id # remove work data
# Full factory wipe (corporate-owned devices)
Invoke-MgWipeDeviceManagementManagedDevice -ManagedDeviceId $device.Id
Enterprise scenario
A logistics company ran 4,000 handheld scanners across distribution centers, all on legacy Device Administrator enrollment. Google’s deprecation timeline forced the issue: DA enrollment was already failing on new Android 15/16 hardware they were buying for a DC expansion, so the fleet was split between an unmanageable old mode and devices that wouldn’t enroll at all.
The constraint that shaped the design: scanners are shared across three shifts with no per-worker login, they must boot directly into a single warehouse-management app, and operators must not be able to reach a browser, settings, or any other app. They also use Zebra hardware whose scanner trigger and battery-swap “hot swap” behavior is configured through Zebra’s MX layer, which the generic Intune profile doesn’t expose.
They moved to dedicated (COSU) enrollment in single-app kiosk mode, provisioned by a single QR code printed on a card at each staging bench. The WMS app was published as a private app to their Managed Google Play Enterprise (it was never in the public store). Zebra-specific behavior went through OEMConfig via the Zebra OEMConfig app and an app configuration policy. The migration was a hard cutover per device – factory reset, scan QR, done in about ninety seconds – with no possibility of in-place upgrade from DA, which they had assumed wrongly at first and had to re-plan around.
The single-app kiosk profile that anchored it, expressed as the Graph configuration payload:
{
"@odata.type": "#microsoft.graph.androidDeviceOwnerGeneralDeviceConfiguration",
"displayName": "KV-Scanner-Kiosk-SingleApp",
"kioskModeManagedHomeScreenInfo": null,
"kioskCustomizationStatusBar": "notificationsAndSystemInfoEnabled",
"kioskModeApps": [
{
"@odata.type": "#microsoft.graph.androidDeviceOwnerKioskModeApp",
"package": "com.kv.wms.scanner"
}
],
"factoryResetBlocked": true,
"screenCaptureBlocked": true,
"volumeBlockAdjustment": true
}
The result: enrollment-blocking tickets went to zero on new hardware, a lost scanner was a remote factory wipe instead of a security incident, and the WMS rollout became a Managed Google Play app assignment instead of a manual APK side-load per device. The lesson they passed on internally was the one in section 1 – there is no migration from Device Administrator; the correct move is to design the target mode (dedicated, here) first and cut over, not to try to “convert” the old enrollment.
Verify
Confirm each mode is actually doing what you intended before you scale out a ring.
- MGP binding: Devices -> Enrollment -> Android -> Managed Google Play shows Connected and the organization name. Force an app sync and confirm an approved app lands in Apps -> Android within a minute or two.
- Work profile: on a BYOD test phone, the work apps carry the briefcase badge; a personal app (e.g. personal Gmail) is invisible in Intune device inventory. Copy-paste from a work app to a personal app is blocked.
- Fully managed / COPE: Devices -> All devices shows the device as Corporate with the correct Ownership and management mode. On COPE, both a device-scope and a work-profile-scope restriction profile show Succeeded.
- Dedicated: the scanner boots directly into the kiosk app (single-app) or MHS (multi-app); the status bar, browser, and settings are unreachable except via the exit code.
- App config: open a configured app (e.g. Outlook) on a test device – the mailbox is pre-provisioned with no manual sign-in account setup.
- OEMConfig: confirm a vendor-only setting actually took (e.g. USB host storage disabled on the Samsung/Zebra pilot) on real hardware, not just “policy assigned.”
- Compliance + CA: intentionally make a device non-compliant (e.g. remove the passcode) and confirm M365 access is blocked after the grace period; restore and confirm access returns.
- Wipe semantics: run Retire on a work-profile test device and confirm only the work profile is removed; run Wipe on a spare corporate device and confirm a clean factory reset.