A user signs in on an Android handset, enrollment stalls part way through, and the handset becomes the suspect because it is the only part you can hold. Android Enterprise enrollment not working is nearly always tenant configuration, and the obvious approach of reimaging or swapping the device fixes nothing. There are six causes worth checking, in a useful order, and Microsoft documents each one in a different article. This post collects them with the Learn page behind each.
Enrollment failures rarely announce which layer they are in. They arrive as a Company Portal screen that stops, a device that completes and then shows no apps, or a handset that quietly ends up in a management mode you retired two years ago. The symptom-first route through the wider platform is Intune troubleshooting, routed by symptom. Every Microsoft fact below was verified against Microsoft Learn on 14 October 2026, with article dates given where they matter.
Why Android Enterprise enrollment not working is rarely the handset
Four things have to be right before the device is involved at all: the tenant binding to managed Google Play, an enrollment profile for the management mode you intend to use, a device platform restriction that permits that mode, and the licence and device count on the user account. The handset contributes two conditions only. It must support Android Enterprise and pass Play Protect certification, and Android Enterprise must be available in the country or region it is in. Microsoft lists both as prerequisites on the personally owned work profile setup page, last updated 8 July 2026. Everything else below is something that was configured, usually by you.
Check the managed Google Play binding first
The binding is one Microsoft Entra account signed into Google, created once per tenant from Devices, then Enrollment, then the Android tab. The managed Google Play connection article, last updated 9 April 2026, sets three prerequisites that are easy to miss. The account needs the Intune Administrator role, or a custom role carrying organization read and update permissions. It must have a mailbox, because Google validates the address during setup. And portal.azure.com, play.google.com and enterprise.google.com all have to sit in the same browser security zone, which is the usual explanation for a setup wizard that dies silently on a locked-down admin workstation.
If Google sign-in does not offer the Microsoft option at all, Microsoft points at a missing MX record on the domain used for Exchange Online. Since August 2024 the binding can use a Microsoft Entra account rather than an enterprise Gmail address, and tenants still on a Gmail account can move to a managed Google domain through Managed Google Play, then Upgrade.
Google recommends at least two owners per enterprise. Most tenants have one, belonging to whoever set Intune up, and that is a real single point of failure. The only remediation Microsoft documents for a broken binding is Disconnect, and the same article states plainly that disconnecting disables Android Enterprise device management for the tenant and unenrols every Android Enterprise device. It is not a reconnect button. Treat the binding the way you treat Apple Business Manager tokens: a named asset with an owner, a renewal date and a recovery plan.
The enrollment profile, and the restriction that builds a dead end
Each corporate-owned mode needs its own enrollment profile, and the personally owned work profile needs one too. The restriction underneath it is where the interesting failure lives. Microsoft documents that if work profile enrollment is blocked at the platform level, devices fall back to device administrator management unless device administrator is also blocked. Device administrator is deprecated and no longer available for devices with access to Google Mobile Services, per the Android device enrollment guide, last updated 16 June 2026. So a restriction that blocks work profile and leaves device administrator allowed sends the device down a route that cannot complete, and nothing in the portal says that is what happened.
Two more details from the same setup page. Blocking Personally owned is not a reliable control: it does not apply to AMAPI devices, and Microsoft describes it as unreliable for Android 12 and later Custom DPC devices. And do not rename an enrollment profile once it is assigned to users or groups, because Microsoft states this can prevent future enrollments. That one has no error message attached to it at all. The broader behaviour of restrictions, including which enrolments they actually govern, is in which enrolments a restriction actually governs.
The per-user device limit deserves a separate warning. The device limit restrictions article at /intune/device-enrollment/create-device-limit-restrictions, last updated 5 May 2026, says only to select the maximum number of devices a user can enroll, and that a tenant can hold up to 25 device limit restriction policies. It does not publish a numeric default, despite a good deal of third-party writing that quotes one. Read the value in your own portal rather than trusting a number from a blog, including this one. The same article notes that a device counts toward the limit when its enrollment type is not in shared mode.
Which account signs in, and on which profile
Microsoft states that enrollment must be done by the primary user account and that secondary user accounts are not supported. On a shared handset, or a device where someone has set up a second Android user, that is a complete blocker and it presents exactly like a credential problem. Android 15 private space is a related trap for the same underlying reason: the work profile is an operating system partition and it has to be created from the primary profile.
The supported starting points are a productivity app such as Teams or Outlook, which Microsoft now recommends first, the Company Portal app, or aka.ms/enrollmyandroid. Enrollment installs Microsoft Intune, Company Portal, Android Device Policy and Microsoft Authenticator, the third of those hidden from the user. If the requirement is really protecting organisational data rather than managing the handset, app protection without enrollment removes this entire surface, and it is a legitimate design rather than a fallback.
Web enrollment cannot be turned back off
On the same enrollment profile there is an option to use web enrollment for all users enrolling into Android personally owned work profile management. Microsoft is unambiguous about two things: it applies at tenant level, and it cannot be reversed. Microsoft also says to leave it unselected if passkeys are your only authentication method, and to use the Company Portal app-based route instead. Web enrollment additionally requires Chrome, Edge or the Samsung browser.
Put those together and a passkey-only tenant that switches web enrollment on has made a permanent change that breaks enrollment for its own users, with no documented way back. That is the most expensive item on this page, and it takes one checkbox.
The corporate-owned modes need a wiped device
Dedicated devices, previously COSU, fully managed, previously COBO, and corporate owned work profile, previously COPE, all require a factory reset before enrollment. The enrollment guide lists the reset as a requirement for each of the three, and fully managed and corporate-owned personal profile also have to be enabled in the Intune admin centre first. Attempting any of them on a handset already in use is not a configuration problem to debug, it is a mode the device cannot enter.
The methods available are QR code, Google Zero Touch, Knox Mobile Enrollment, near field communication and token entry, per the corporate methods reference at /intune/device-enrollment/android/ref-corporate-methods, last updated 2 October 2026. Two constraints on that page are easy to trip over: the QR reader is preinstalled only on Android 9.0 and later, and NFC and token entry are not supported on corporate-owned work profile devices running Android 11.0. Zero Touch also requires hardware bought from an authorised reseller, which is a procurement decision rather than a portal setting. For non-GMS hardware the Android Open Source Project path exists, needs no managed Google Play connection, and carries limited OEM support. Dedicated devices usually end up as kiosks, and kiosk configuration has its own failure set in Intune kiosk mode not working.
The failure modes
These behaviours get raised as Android Enterprise enrollment not working when they are either documented as expected or caused somewhere else entirely. Each comes from the Microsoft troubleshooting article at /troubleshoot/mem/intune/device-enrollment/configure-android-enterprise-devices-intune, last updated 30 March 2026, unless noted.
| What you see | What it actually means |
|---|---|
| Enrollment completes but managed Google Play apps never appear under Discovered Apps | Expected behaviour. Managed Google Play apps do not report there, so this is not evidence of a broken enrollment. |
| Apps you never approved still show under Mobile Apps | Expected behaviour, and not a sync fault. |
| Managed Google Play Last Sync is hours or days old | Expected. That sync runs only when someone presses Sync, so a stale timestamp says nothing about device health. |
| Wipe is unavailable on a work profile device | Expected. Retire removes the work profile and its contents, and is the equivalent action for this management mode. |
| Initiating Reset passcode failed | The user never entered their passcode at the Secure your Work Profile prompt, so the reset token Intune needs was never activated. |
| Apps you did not deploy appear inside the work profile | The device OEM can enable system apps when the work profile is created. Intune does not control it. |
| The Company Portal log folder under Internal storage does not exist | Expected. That path exists only for the device administrator scenario. Use Menu, then Help, then Email Support, then Send Email and Upload logs. |
| A third-party keyboard such as SwiftKey is blocked on a Samsung device | Samsung enforces this from Android 8.0. Microsoft documents no resolution. |
| The guided move off device administrator never offers Resolve | The device needs Android Company Portal 5.0.4720.0 or later, per the migration article at /intune/device-enrollment/android/migrate-device-admin-to-work-profile, last updated 9 April 2026. |
What I would do differently
My tenant is a lab with no enrolled Android devices. I have not run any of this in production, so what follows is read off Microsoft documentation on 14 October 2026 and labelled as judgement rather than experience.
Give the managed Google Play binding two owners on the day you create it. It is the one dependency every Android device in the tenant shares, and the only repair Microsoft documents unenrols all of them.
Block device administrator explicitly rather than relying on it being deprecated. An implicit fallback fails without an error. An explicit block at least produces a refusal the user can report, and a refusal you can find.
Decide web enrollment before you need it. If any part of the workforce authenticates with passkeys only, leave it off, because there is no second decision available.
Stop quoting a device limit you have not read in your own portal. The documentation does not publish a default, which means every number circulating for it came from somewhere other than Microsoft.
Then ask whether the device needs managing at all. A fair share of Android estates exist to deliver Outlook and Teams safely, and app protection policies do that without a Google binding, an enrollment profile or a factory reset.
Last verified: 14 October 2026
