The enrollment article described what changed in June 2026. This is the build. Android BYOD onboarding now has two workstreams that look like one: pointing new enrollments at the web flow, which mostly builds itself, and migrating the existing fleet onto the Android Management API deliberately, before Microsoft’s calendar-year auto-migration does it for you. The first is almost free. The second is where the judgment lives.
The Prerequisites Nobody Checks
Web enrollment for the personally owned work profile is the service-side default now, and there is refreshingly little to construct for the flow itself: a tenant with managed Google Play connected and a licensed user gets the browser experience without an enrollment profile to build. The real construction work is the boundary around it. The old lever, setting Personally owned to Block in an enrollment restriction, does not apply to devices on the Android Management API and is leaving the admin center, so if your BYOD boundary was that checkbox, you currently have less of a boundary than you think. The durable pattern is group scoped: a default enrollment restriction that blocks Android Enterprise work profile enrollment for everyone, and a higher priority restriction that allows it, assigned to the group you actually intend to onboard. Membership in that group becomes the enrollment decision, which is where it belonged all along.
The other prerequisite hides in the network. Work profile Wi-Fi profiles that authenticate with a username and password drop during migration and stay down until the user signs in again. If any of your BYOD Wi-Fi still rides credentials, move it to certificate authentication before touching the migration policy, not after the tickets arrive.
Migrate on your schedule or on Microsoft’s. The policy is the same either way; the ticket volume is not.
The Migration Policy
Existing devices enrolled through the old Company Portal implementation move via a device configuration policy, Move to Android Management API, assigned like any other profile. Three properties define how you should treat it. It is one way, with no rollback and no unenrollment required. Users keep access to work apps and data throughout, so the migration itself is quiet when the prerequisites are clean. And every device you have not migrated by the time Microsoft’s calendar year 2026 auto-migration reaches your tenant gets migrated anyway, on a schedule you did not pick, with prerequisites you did not verify.
The verification list is short but each item has teeth. Custom configuration policies for the personal work profile ended in April 2025 and do not exist on the other side; anything still depending on one needs a settings catalog equivalent or an honest funeral. Device level blocks on biometrics and trust agents are unsupported under the new API, while the same controls at the work profile level carry over fine. Work profile password requirements stop applying to devices on Android 11 and earlier, which is a quiet compliance gap if your fleet has stragglers. The Google domain allow list moves to the Google Admin console. And two reports you may be watching, Enrollment failures and Incomplete user enrollments, do not cover devices on the new API, so a migration that looks like silence in the old reports is usually just a migration that worked.
Roll it out the way this series rolls out everything: a pilot group of tolerant users first, watch the device list flip to the new management path, confirm Wi-Fi and app protection behavior, then expand in rings. The auto-migration deadline makes procrastination a decision, not a deferral.
What to Tell Users, and What to Verify
New enrollments need one sentence of communication: open the browser, sign in with your work account, and the work profile builds itself, apps included. There is nothing to install first, which after a decade of “install Company Portal from the Play Store” is the entire message. Devices carrying a Company Portal build older than 2604 will route to the legacy app flow on their own; that is expected, not broken. Migrated fleets need a different sentence: some new apps will appear, the Microsoft Intune app becomes where device status lives, and nothing needs to be done about any of it.
Verification closes the loop. Enrollment restrictions blocking by default and allowing by group. Wi-Fi on certificates. The pilot migrated and healthy in the app protection and device compliance views that do cover the new API. The design article’s argument was that enrollment boundaries should be deliberate; the June change removed the option of pretending a checkbox was a boundary, which makes this the rare platform migration that leaves the architecture more honest than it found it.
Intune Deployment Guide · Phase 9: Mobile and BYOD
‹ Previous: [9.3.3] Dedicated Devices: Kiosk, Shared, and Single-Purpose Android
Next: [9.4] iOS Management Reality ›
