Demystifying Android Web-Based Enrollment: The Conditional Access, Broker, and Defender Core "Gotchas"

Credits: Google

Microsoft’s shift to the modern Google Android Management API (AMAPI) brings a highly anticipated, low-friction onboarding experience to Android Enterprise Personally-Owned Work Profiles: Web-Based Enrollment. This mirrors the web-first workflow we’ve seen on iOS for a while, completely removing the traditional requirement for end-users to pre-download the heavy Intune Company Portal application from the public Play Store. However, moving to a modern, browser-driven enrollment framework completely changes how security tokens are passed under the hood. So if you are planning to deploy Android Web-Based Enrolment while maintaining a strict Zero-Trust tenant, you will almost certainly run into infinite authentication loops, hidden app blocks, and broken single sign-on (SSO).

In this blog post, I’ll break down the architectural reality of Android container sandboxing, uncover the hidden identity dependencies, and detail the exact Conditional Access exclusions you need to make this deployment a success.

The Architectural Shift: Automated Container Brokering

On iOS, the operating system can handle cross-app SSO globally across the device. Android handles BYOD entirely differently by enforcing a strict cryptographic wall between the Personal side of the phone and the Work Profile container. Apps living on the personal side cannot see, read, or communicate with data or tokens inside the work profile. Because the legacy Company Portal app is no longer used as part of the enrolment process in the web enrolment, you lose the traditional global device management broker. Under the modern AMAPI framework, Microsoft resolves this by automatically provisioning Microsoft Authenticator directly inside the Work Profile container during the initial web handshake. This means a "dual-authenticator" model where the user had to manage a personal-side app copy is not required. This single, automated work-container instance of Authenticator acts as the native secure local identity broker.

The Conditional Access deadlock

When configuring a Zero-Trust tenant, the golden rule is creating a Conditional Access (CA) policy that blocks access to corporate data unless the device is a Compliant Device. When a user initiates Android Web-Based Enrollment, the browser builds the Work Profile container on the fly. However, when the user launches Outlook or Teams for the first time inside that new container, the application spins up an embedded WebKit web view to authenticate against Microsoft Entra ID. Now because the app is opening for the first time, it hasn't bootstrapped its relationship with the Work Profile's Authenticator broker yet. The authentication request reaches Entra ID with an empty DeviceId claim. Conditional Access evaluates the connection, flags it as "unmanaged," blocks the login, and tells the user to enrol, sending the user back to Outlook kicking off an infinite loop. 

If you are also deploying Microsoft Defender for Endpoint for Always-On mobile web protection, then it is highly likely that your Intune compliance policy likely dictates that a device cannot be marked "Compliant" until Defender scans the device and reports a clean risk score. When the Defender app launches to run that initial scan, it attempts to authenticate to its cloud backend to validate its license. If your CA policy is active on Defender, it blocks that background login because the device isn't compliant yet. This creates a secondary deadlock where Defender can't scan, resulting in the device never becoming compliant. 

To break this authentication loop, organizations must allow the initial enrolment, hardware registration, and endpoint security traffic to bypass the Conditional Access compliance checks. The standard fix is simple: go to your CA policy, look under Target Resources > Cloud Apps, and add your management infrastructure to the Exclude tab. In addition to Intune enrollment apps, Defender apps need to be excluded as well & I have covered this in my earlier blog post that you can refer to on how to exclude the required apps from the conditional access policy.

Enabling the Web Enrolment for Personally owned devices with Work Profile (BYO) in Intune

1. In the Intune Admin Center, navigate to Devices > Android > Enrollment.

2. Select Personally-owned devices with a work profile.

3. Toggle "Use web enrollment for all users enrolling into Android personally owned work profile management" to Yes and click Save.

Make a note of the disclaimer stating that once you opt in to web-based enrollment, all future personal work profile enrollments for all users will become web enrollments. Also, if you are using 3rd party credential provider apps, then you must create app configuration policies to support autofill and passkeys. Microsoft Authenticator is allowed automatically and just needs to be pushed as a required app.

On a side note, just like Outlook, Microsoft Edge for Android is multi-identity by default. While the local MSAL broker means Edge doesn't need configuration policies to pass your initial sign-in, it is recommended to enforce strict data boundaries and ensure the App Protection Policies aren't bypassed in form of end user being able to add personal accounts. Therefore, consider pushing an App Configuration Policy containing the Allowed Accounts token mapped to {{userprincipalname}} for Edge.

For rest of the configuration involving Defender for Mobile for Android onboarding, you can head over to my previous blog post that covers the process in detail.

End User Experience

When the end user tries to access corporate data through let's say Outlook, the CA policy is going to enforce the check for compliant status on the device. At this stage, if the device is un-managed, the end user will be directed to the enrolment portal via their mobile browser. The user must signs in, satisfy the authentication in order to get a token in order to allow the operating system build the Work Profile seamlessly.

     

              

The user must open the Authenticator app in the work container to register the device, allow the issuing of certificate which will inadvertently populate the deviceid property in Entra ID. Once this is complete and when the user opens Outlook from the work container, thanks to the shared Microsoft Authentication Library (MSAL), the apps query the authenticated local broker, instantly auto-populate the user's ID, verify compliance, and grant access with zero user friction.

Final thoughts

Shifting from the legacy Company Portal app model to AMAPI-driven Web-Based Enrollment marks a significant modernization milestone for Android BYOD management bringing in alignment and some what at par with iOS. Personally for me the real value addition is a unified, cloud-first framework that automates identity broker deployment directly inside an isolated container. Navigating the upfront Conditional Access traps, missing service principals, and Defender deadlocks is undeniable heavy lifting—but the result is an ironclad, enterprise-grade enrollment engine built for modern compliance.

Until next time..