Unmanaged Devices with Microsoft Intune (2/3): Android
Android MAM protects all Microsoft 365 apps on mobile, not just Edge. 3 BYOD paths, different control levels, and the CA gap most organizations miss.
A user opens Outlook on their personal Android phone. They navigate to a SharePoint file, save it to their local Downloads folder, and share it via WhatsApp. Your app protection policy was assigned and active. It never triggered. When you investigate, you find the user never installed Company Portal. MAM enrollment requires it on Android. Without it, the policy has no enrollment to attach to. Conditional Access never checked. The data left your control with no record of it.
The Android story should be simpler than Windows. MAM covers the full Microsoft 365 app suite on Android, not just Edge. The tools are better. The failure points are different.
Key Takeaways
- Android MAM covers Outlook, Teams, Word, Excel, PowerPoint, OneNote, and OneDrive. Unlike Windows, where MAM is limited to Edge, protection follows the apps your users actually work in.
- MAM-only without enrollment is the right BYOD path for most organizations. Work Profile adds control but creates friction that reduces adoption.
- Company Portal must be installed on the device for app protection policies to apply on Android. Without it, MAM enrollment cannot complete, regardless of where the apps were downloaded from.
- “Require app protection policy” in Conditional Access is what makes MAM enforcement real. Without it, your policies are configured but not enforced.
- Device Administrator mode is deprecated. Any Android device still enrolled that way should be migrated to Android Enterprise.
How does Android BYOD differ from Windows?
The scope of MAM protection is fundamentally different on Android. On Windows, Intune MAM protects only Microsoft Edge. On Android, it protects Outlook, Teams, Word, Excel, PowerPoint, OneNote, OneDrive, and Edge. Every Microsoft 365 app on Android implements the Intune MAM SDK. App protection policies apply to the apps your users actually work in, not just the browser they use to access files.
This changes the risk model. On Windows, protecting BYOD means getting users to work through Edge for everything corporate. On Android, the protection travels with the apps themselves. A user who opens the managed Outlook app is covered, regardless of which browser they prefer personally. The scope limitation that defines Windows MAM does not exist on Android.
Read Part 1 of this series on Windows BYOD with Intune for the full picture on Edge-only MAM, enrollment pitfalls, and Conditional Access setup that applies equally across platforms.
What options does Microsoft Intune offer for Android?
Three paths exist for Android BYOD. They operate at completely different levels, and choosing the wrong one either leaves data unprotected or adds device management overhead that does not belong on a personal device. Unlike Windows, where MAM is limited to Edge, Android MAM-only covers your users’ actual productivity apps, which shifts the trade-off between the three paths considerably.
Option 1: MAM-only (no enrollment) - recommended for BYOD
App protection policies apply to supported Microsoft 365 apps without enrolling the device in Intune. The device stays outside your MDM. You protect corporate data in Outlook, Teams, and Office apps without touching anything personal on the device.
What you can do:
- Apply app protection policies to Outlook, Teams, Word, Excel, PowerPoint, OneNote, and Edge
- Require PIN or biometric authentication before opening any work app
- Block copy and paste of corporate content to personal apps
- Block saving corporate files to personal storage
- Block screenshots within managed apps
- Enforce minimum OS version and app version requirements
- Selective wipe: remove corporate app data without touching personal data or files
What you cannot do:
- See the device in Intune device management
- Push device configuration or required apps
- Use “Require compliant device” as a Conditional Access grant
- Control personal apps or personal storage
Requirements: Android 10.0 or later. Company Portal installed on the device. Intune Plan 1 license.
Option 2: Android Enterprise Work Profile - for higher-risk scenarios
The device enrolls in Intune using Android Enterprise. An OS-enforced Work Profile is created alongside the user’s personal profile. Work apps live in the managed container. Personal apps live in the personal profile. The two are isolated at the OS level via a separate partition created by Android Enterprise.
What you can do:
- All MAM capabilities, plus:
- Deploy required apps directly to the work profile
- Enforce device compliance policies
- Use “Require compliant device” in Conditional Access
- Wipe the work profile without touching personal data or apps
- Control which apps are available through the managed Play Store
What you cannot do:
- See or interact with personal apps or files
- Perform a full device wipe without specific configuration to allow it
Work Profile enrollment requires the user to install Company Portal and complete an enrollment flow. That friction matters in practice. Every time I’ve seen Work Profile mandated for BYOD without clear user communication, adoption drops. Users install personal copies of Outlook and Teams outside the managed profile to consolidate notifications and avoid policy restrictions. The profile exists in Intune. The corporate data flows through the unmanaged instance.
Option 3: Android Enterprise Fully Managed - corporate devices only
The entire device is managed by Intune. No personal profile exists. This is not BYOD. It is the correct path for corporate-owned, corporate-issued devices.
I include it here because organizations regularly misconfigure BYOD enrollment profiles and accidentally route personal devices into fully managed territory, particularly when enrollment groups are not scoped correctly.
How do the three options compare?
The three options differ not just in what they control, but in where they draw the line between IT management and employee privacy. MAM-only applies controls at the app layer without touching the device. Work Profile enforces separation at the hardware layer. Fully Managed removes the personal layer entirely. Choosing the right one means understanding which layer your risk actually lives at.
| Capability | MAM-only | Work Profile | Fully Managed |
|---|---|---|---|
| Recommended for BYOD | Yes | High-risk only | No |
| Device enrollment required | No | Yes | Yes |
| Protects Outlook, Teams, Office apps | Yes | Yes | Yes |
| Remote wipe (corporate data only) | Yes | Yes (work profile) | Yes |
| Remote wipe (full device) | No | No | Yes |
| Work/personal isolation | App-level | Hardware-level | No personal profile |
| Require compliant device (CA) | No | Yes | Yes |
| Device visible in Intune | No | Yes | Yes |
| Push app installations | No | Yes | Yes |
| Company Portal required | Yes | Yes | Yes |
| User privacy preserved | Yes | Yes | No |
What do app protection policies actually enforce?
What I find in most tenants: the app protection policies are created, assigned to a group, and the assumption is that users in that group are now protected. Three things have to be true for a policy to actually apply: the user is in the targeted group, Company Portal is installed on the device, and Conditional Access is configured to require an app protection policy for resource access. Remove any one of those three conditions, and the policy has nothing to enforce.
What a well-configured Android app protection policy controls:
PIN and biometrics. The user must authenticate before opening any work app. This requirement is independent of the device lock screen. The policy enforces its own auth check at the app level.
Copy and paste restrictions. Paste of corporate content into personal apps is blocked. You configure this directionally: corporate-to-personal only, or bidirectional. Users can still paste within managed apps.
Save restrictions. Files opened from work apps cannot be saved to personal storage. Saves to OneDrive for Business or SharePoint work. Saves to the local Downloads folder are blocked.
Screenshot blocking. Screenshots within managed apps are blocked at the OS level. This is enforced by the MAM SDK and cannot be overridden by the user.
Offline grace period. The policy sets how long the user can work offline before re-verifying policy compliance. After the grace period, access to work app data is blocked until the device reconnects.
Minimum OS and app versions. Access is blocked or warnings appear if the device falls below your minimum requirements.
What app protection policies do not control:
Anything outside the Microsoft 365 apps that implement the MAM SDK. Third-party apps do not have MAM SDK support unless the developer added it specifically. If a user shares a file to a personal cloud storage app before the policy can intercept, the policy had no enforcement point.
What enrollment pitfalls do organizations hit with Android?
Android enrollment has fewer hidden states than Windows, but the failure patterns are just as consistent. Most come down to three gaps: Company Portal not deployed for MAM-only users, legacy Device Administrator mode left in place, and Work Profile adoption that fails silently after rollout.
Managed Google Play not configured for Work Profile deployments
Managed Google Play is not required for MAM-only deployments. Microsoft 365 apps installed from the public Play Store support MAM enrollment. What is required for MAM-only is Company Portal: without it on the device, MAM enrollment cannot complete. The confusion arises when organizations plan Work Profile deployment but never link managed Google Play to their tenant.
For Work Profile enrollment, managed Google Play is the app distribution channel. Without it, you cannot push required apps to the managed work profile. Linking your Intune tenant to a Google enterprise account is a one-time setup. I have found tenants where Work Profile policies were configured and assigned, but no apps had been deployed because managed Play was never set up. The enrolled profile exists. It contains nothing.
Device Administrator mode still in use
In around a third of the tenants I work with that have had Intune for more than three years, I still find Android devices enrolled via Device Administrator mode. Google deprecated Device Administrator in 2020. Intune ended all support for DA devices with GMS in December 2024. These devices do not support Work Profile. They run without the management capabilities Android Enterprise provides. They appear in Intune but without the security posture the device list implies.
Migration to Android Enterprise requires re-enrollment. That requires user action. In practice, many organizations have accepted the gap rather than addressed it.
Work Profile friction and shadow adoption
Work Profile creates two distinct profiles with separate app drawers, separate notifications, and separate authentication states. The security design is sound. The user experience is jarring for users who are not expecting it.
What I see consistently: users enrolled in Work Profile start finding ways around the separation. They install a personal copy of Outlook in the personal profile to consolidate notifications. They access SharePoint through a personal browser instance because the work profile browser has restrictions they find inconvenient. The Work Profile is enrolled and visible in Intune. The actual corporate data is in the personal profile.
How do Conditional Access and app protection policies work together?
The Conditional Access grant “Require app protection policy” works correctly on Android for mobile app access. When configured, users accessing corporate resources from an Android device must do so through an app with an active app protection policy applied. If the app is not MAM-enrolled, because Company Portal was never installed or because the user never completed enrollment, access is blocked.
Without this CA policy, app protection policies are configured but optional. Users who happen to install apps from managed Play get the policy. Users who install from the public Play Store do not. There is no enforcement point.
The “Require approved client app” gap
Older Conditional Access documentation references “Require approved client app” as the Android and iOS grant. This grant is retiring June 30, 2026. It verifies that the user is running a specific approved app. It does not verify that an app protection policy is active. If your CA policies still use the approved client app grant, migrate to “Require app protection policy.” The newer grant verifies both the app and the policy state.
Session controls
The same session controls from the Windows BYOD setup apply here. Configure a shorter sign-in frequency for BYOD users (1 to 12 hours depending on your risk tolerance) and set Persistent browser session to “Never persistent” for any browser-based access on unmanaged devices.
For full Conditional Access configuration detail, read how compliance policies and CA work together in Part 1 of this series.
What goes wrong at clients?
These are the five situations I find most consistently when auditing Android BYOD deployments. Some are pure configuration gaps. Most follow a predictable pattern: a control exists on paper, a user found a workaround, and the workaround became permanent.
App protection policies exist but Conditional Access does not enforce them. The policy is assigned. Users are in the group. No CA policy requires app protection for resource access. Anyone using an unmanaged Outlook install gets through without the policy applying.
Company Portal not deployed for MAM-only users. Policies are assigned. Users have Outlook and Teams installed. But Company Portal is not on the device, so MAM enrollment never completes. The apps behave as unmanaged personal installs.
“Require approved client app” still in use. An outdated CA policy blocks unrecognized apps but does not verify that app protection policies are active. The migration to “Require app protection policy” is on the backlog.
Work Profile adoption failing silently. IT deploys Work Profile as the BYOD standard. Users enroll, find the dual-profile experience inconvenient, and use personal app instances for corporate work. The enrolled profile exists in Intune. The data is in the personal profile.
Device Administrator devices still active. Legacy Android devices in DA mode coexist with Android Enterprise devices. They hold active corporate accounts but are outside meaningful management capability.
The pattern is the same across all five: a control was put in place, a user found a path around it, and an exception was added to keep that user productive. The exception never got closed. The gap has been open for months or years without anyone noticing.
Which licenses do you need?
Android BYOD with MAM-only requires two licenses: Intune Plan 1 and Entra ID P1. Both are included in Microsoft 365 Business Premium and E3. E5 includes Entra ID P2, which covers all P1 requirements. Work Profile enrollment uses the same licenses. No additional Android-specific license is needed beyond the Google enterprise account for managed Play, which is free.
| Feature | License Required |
|---|---|
| Intune (MAM + Android Enterprise) | Microsoft Intune Plan 1 (included in Business Premium, E3, E5) |
| App protection policies | Microsoft Intune Plan 1 |
| Conditional Access | Entra ID P1 (Business Premium, E3) or P2 (E5) |
| Managed Google Play integration | Google enterprise account (free, one-time setup) |
| Defender for Endpoint mobile integration | Defender for Endpoint Plan 1 or Plan 2 (E5 Security or add-on) |
Frequently asked questions
Can a user have MAM applied on both a personal Android phone and a work phone?
Yes. MAM policies are user-based, not device-based. A user with two phones can have the policy applied on both, provided Company Portal is installed and MAM enrollment is completed on each device. Each app instance enrolls independently. A selective wipe targets a specific user and app combination, not the device.
Does the Work Profile prevent IT from seeing personal apps or data?
Yes. IT has visibility only into the work profile. Personal apps, photos, messages, and contacts in the personal profile are invisible to Intune. This is a common concern employees raise before agreeing to enroll. It is worth communicating clearly, in writing, before asking users to install Company Portal. The work profile wipe removes only the managed container, not personal data.
My app protection policies are assigned but the PIN requirement is not appearing in Outlook. What is wrong?
Check three things in order. First, confirm the user is in the assigned group in Intune. Second, verify that Company Portal is installed on the device. Without it, MAM enrollment cannot complete on Android, regardless of where the app was downloaded from. Third, confirm that a Conditional Access policy is configured to require an app protection policy for Exchange or Microsoft 365 access. All three must be true for the policy to apply.
What happens to corporate data when an employee leaves the organization?
With MAM-only, a selective wipe removes all corporate-context data from every MAM-enrolled app on the device. Corporate-context means Exchange email and OneDrive for Business files. Personal account data in those same apps, and all personal files and apps, are not touched. With Work Profile, a work profile wipe removes the entire managed container, including all managed apps and their data. Personal data in the personal profile remains intact. Neither option requires a full device wipe to remove corporate data.
Is “Require app protection policy” in Conditional Access enough, or do I also need Work Profile enrollment for Android BYOD?
For most BYOD scenarios, “Require app protection policy” enforced by Conditional Access is sufficient. It covers all Microsoft 365 apps, requires no device enrollment, and preserves user privacy. Work Profile is appropriate when you need device compliance signals in Conditional Access, need to push required apps directly to devices, or when data sensitivity requires hardware-level separation between work and personal profiles. That is the exception, not the standard.