Unmanaged Devices with Microsoft Intune (3/3): iOS
iOS MAM covers the full M365 app suite but requires Microsoft Authenticator as broker. 3 BYOD paths, the CA gap most organizations miss, and what goes wrong.
A user opens Outlook on their personal iPhone. They download a SharePoint file and AirDrop it to their personal MacBook. Your app protection policy was assigned and active. It never triggered. When you investigate, you find Microsoft Authenticator is not installed on the device. On iOS, Authenticator is the MAM broker. Without it, the policy has no mechanism to activate. The enrollment never completed. The data moved without a record.
The iOS story is often the quietest of the three platforms. MAM covers the full Microsoft 365 app suite, the same as Android. The tools are mature. The failure points are different, and they are easier to miss.
Key Takeaways
- iOS MAM covers Outlook, Teams, Word, Excel, PowerPoint, OneNote, OneDrive, SharePoint, To Do, and Edge, among others. Unlike Windows, where MAM is limited to Edge, protection follows the apps your users actually work in.
- Microsoft Authenticator is the MAM broker on iOS. Without it, Conditional Access cannot enforce app protection policies, regardless of which apps the user has or which group they belong to.
- MAM-only without enrollment is the right BYOD path for most organizations. User Enrollment adds privacy-preserving MDM but requires Managed Apple IDs for each enrolling user. Apple Business Manager or Apple School Manager is the standard way to provision them at scale.
- “Require app protection policy” in Conditional Access is what makes MAM enforcement real. Without it, your policies are configured but not required.
- “Require approved client app” in Conditional Access is retiring June 30, 2026. If your iOS CA policies still use it, migrate now.
How does iOS BYOD differ from Android?
The most important difference is the broker. On Android, Company Portal handles MAM enrollment. On iOS, Microsoft Authenticator serves that role. The result is the same: without the broker app installed and enrolled on the device, app protection policies have nothing to attach to. But the broker is different, and that is where most iOS deployments go wrong. Administrators who correctly deploy Company Portal for Android BYOD sometimes assume the same app handles iOS. It does not.
The scope of MAM protection is identical between iOS and Android. Both platforms cover the full Microsoft 365 app suite. On Windows, MAM is limited to Edge. On iOS and Android, protection travels with Outlook, Teams, Word, Excel, PowerPoint, OneNote, OneDrive, SharePoint, To Do, Edge, and more. The platform difference is in how enforcement is brokered, not in what is protected.
Read Part 1 of this series on Windows BYOD with Intune for the contrast with Edge-only MAM and enrollment pitfalls that apply across platforms. Part 2 covers Android BYOD, including how Company Portal works as the Android broker and the three Android BYOD paths.
What options does Microsoft Intune offer for iOS?
Three paths exist for iOS BYOD. They operate at different levels of control and require different infrastructure. The wrong choice either leaves data unprotected or introduces device management overhead that does not belong on a personal device.
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 scope. You protect corporate data in Outlook, Teams, and Office apps without access to anything personal on the device.
What you can do:
- Apply app protection policies to Outlook, Teams, Word, Excel, PowerPoint, OneNote, OneDrive, SharePoint, To Do, and Edge
- Require PIN, Face ID, or Touch ID before opening any work app
- Block copy and paste of corporate content to personal apps
- Block saving corporate files to personal iCloud or local storage
- Control which apps can receive files from managed apps (Open-in management)
- Enforce minimum iOS version and app version requirements
- Selective wipe: remove corporate app data without touching personal content
What you cannot do:
- See the device in Intune device management
- Push device configuration profiles or required apps
- Use “Require compliant device” as a Conditional Access grant
- Control personal apps or iCloud storage
Requirements: iOS 17 or later (Microsoft follows an N-1 support model; this minimum changes with each iOS release cycle). Microsoft Authenticator installed on the device. Intune Plan 1 license.
Option 2: User Enrollment (for higher-risk scenarios)
User Enrollment is Apple’s privacy-preserving MDM enrollment model. Intune gains management authority over a separate encrypted volume on the device. Personal data stays in the user’s personal Apple ID partition and is invisible to IT.
Two enrollment methods exist. Account-Driven User Enrollment (iOS 15 or later) is the recommended path: the user adds their work account in Settings > VPN & Device Management, and the enrollment profile installs silently. No Company Portal is needed; Microsoft Authenticator must be installed. Profile-based enrollment with Company Portal (iOS 13 or later) has been deprecated by Microsoft and is no longer available for new enrollments. Any new User Enrollment deployment should use the account-driven method.
What you can do:
- All MAM capabilities, plus:
- Deploy required apps to the managed volume
- Enforce device compliance policies
- Use “Require compliant device” in Conditional Access
- Wipe the managed volume without touching personal data
- Push Wi-Fi and VPN profiles for corporate access
What you cannot do:
- See personal apps, photos, messages, or contacts
- Perform a full device wipe
- Access the device’s IMEI or serial number (User Enrollment uses a privacy-preserving identifier by design)
- Use Automated Device Enrollment features (those require Supervised)
User Enrollment requires Managed Apple IDs for each enrolling user. Apple Business Manager or Apple School Manager is not strictly required, but it is the practical standard: it enables federation with your Entra ID tenant, which eliminates manual ID creation, and is the only realistic way to provision Managed Apple IDs at scale. Without ABM and federation, Managed Apple IDs must be created individually. Organizations that skip this setup assign User Enrollment profiles that users cannot complete.
Every time I have seen User Enrollment mandated for BYOD without a working ABM setup and clear user communication, adoption fails. Users do not know what a Managed Apple ID is. The enrollment flow is unfamiliar. They stop partway through and install personal Outlook instead. IT sees no enrolled devices in the group and assumes users ignored the communication.
Option 3: Supervised (corporate devices only)
Supervised is Apple’s full-management mode for corporate-owned iOS devices. IT has complete control: silent app installation, feature restrictions, kiosk configurations, and full device wipe capability. Supervision requires Automated Device Enrollment through Apple Business Manager or Apple School Manager.
This is not BYOD. It is the correct path for corporate-issued iPhones and iPads.
I include it here because organizations regularly misconfigure enrollment profiles and route personal devices into Supervised territory, particularly when ABM setup and enrollment group scoping are incomplete.
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. User Enrollment enforces separation at the volume level. Supervised removes the personal layer entirely. Choosing the right one means understanding which layer your risk actually lives at.
| Capability | MAM-only | User Enrollment | Supervised |
|---|---|---|---|
| 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 (managed volume) | Yes |
| Remote wipe (full device) | No | No | Yes |
| Work/personal isolation | App-level | Volume-level | No personal profile |
| Require compliant device (CA) | No | Yes | Yes |
| Device visible in Intune | No | Yes | Yes |
| Silent app installation | No | Yes | Yes |
| Broker app required | Yes (Authenticator) | No | No |
| Managed Apple IDs required | No | Yes | No |
| Apple Business Manager or Apple School Manager | No | Recommended | Required |
| 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, Microsoft Authenticator is installed and the user has completed MAM enrollment through it, 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 iOS app protection policy controls:
PIN and biometrics. The policy enforces its own authentication check at the app level. Face ID and Touch ID are both supported. This requirement operates independently of the device lock screen. The user must authenticate before opening any work app, even if the device is already unlocked.
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 paste freely between managed apps.
Open-in management. Files from managed apps can only be shared to other managed apps. On MDM-enrolled devices, app protection policies combine with iOS OS sharing controls to restrict data transfers to policy-managed and MDM-deployed apps. On unenrolled MAM-only devices, Intune encrypts data transferred to unmanaged destinations, making it unreadable outside managed apps. A SharePoint file opened in managed Outlook cannot be usefully shared to a personal Files app or AirDropped to an unmanaged device. Android implements equivalent data transfer restrictions through its own app protection policy settings.
Save restrictions. Corporate files cannot be saved to personal iCloud Drive or local device storage. Saves to OneDrive for Business or SharePoint work. Saves to personal storage are blocked.
Offline grace period. The policy defines how long the user can work offline before re-verifying compliance. After the grace period, access to work app data is blocked until the device reconnects and the policy is re-verified.
Minimum iOS and app versions. Access is blocked or warnings appear if the device or app falls below your minimum requirements.
Screenshot blocking. When the Send org data to other apps setting is configured to a value other than “All apps,” screenshots within managed apps are blocked. This is enforced by the Intune MAM SDK (version 20.2.1 or later) and cannot be overridden by the user.
What app protection policies do not control:
Anything outside the Microsoft 365 apps that implement the MAM SDK. Third-party apps have no MAM SDK support unless the developer added it specifically. If a user finds a way to move content before the policy can intercept, the policy had no enforcement point.
What enrollment pitfalls do organizations hit with iOS?
iOS enrollment has fewer legacy states than Android, but the failure patterns are just as consistent. Most come down to four gaps: Microsoft Authenticator not deployed for MAM-only users, Open-in management not configured, Apple Business Manager or Apple School Manager not set up for User Enrollment, and the APNS certificate expired or its Apple ID lost.
Microsoft Authenticator not deployed for MAM-only users
This is the most common iOS MAM failure I see. App protection policies are assigned. Users have Outlook and Teams installed. Microsoft Authenticator is not on the device, so MAM enrollment never completes. The apps behave as unmanaged personal installs. No PIN requirement appears. No copy-paste restriction applies. Conditional Access finds nothing to evaluate for app protection policy state because no enrollment exists.
The fix is straightforward: include Authenticator in any onboarding communication sent to BYOD users. It is not optional. Without it, Conditional Access cannot enforce the app protection policy, and the device presents no enrollment for Intune to evaluate.
Open-in management not configured
iOS has a native mechanism for controlling which apps can receive files from other apps. When Open-in management is enabled through the app protection policy, files from managed apps can only be shared to other managed apps. When it is not configured, a user can open a SharePoint file in managed Outlook and immediately AirDrop it to a personal device or share it to a personal app without restriction.
Open-in management gaps appear in most iOS BYOD deployments that were set up more than two years ago. The save and copy-paste restrictions are in place. The Open-in setting was never configured. Files still move freely through sharing actions.
Apple Business Manager or Apple School Manager not configured for User Enrollment
User Enrollment requires Managed Apple IDs for each enrolling user. Apple Business Manager or Apple School Manager is the standard way to provision them at scale and enables federation with Entra ID. Without it, Managed Apple IDs must be created individually, which is impractical beyond a handful of users. Organizations plan User Enrollment, configure the profile in Intune, assign it to a group, and communicate it to users. Users encounter an error or an incomplete flow because no Managed Apple ID exists for them. The enrollment profile was configured. The prerequisite infrastructure was not.
Configuring Managed Apple IDs and linking Intune to ABM is a prerequisite, not a post-deployment task. Every User Enrollment deployment that skips this step produces the same outcome: zero enrolled devices and a user population that falls back to personal app installs.
APNS certificate expired
Any iOS MDM enrollment, including User Enrollment, requires a valid Apple Push Notification Service certificate in Intune. The certificate expires annually and must be renewed with the same Apple ID that was used to create it. Renewing with the same Apple ID does not require device re-enrollment. If the Apple ID is lost, the certificate cannot be renewed — it must be replaced with a new one, and every enrolled iOS device must re-enroll. Organizations that manage Intune without a shared service account for the Apple ID regularly encounter this scenario.
How do Conditional Access and app protection policies work together?
The Conditional Access grant “Require app protection policy” works correctly on iOS for mobile app access. When configured, users accessing corporate resources from an iOS device must do so through an app with an active app protection policy applied. If Authenticator is not installed or the user never completed MAM enrollment, access is blocked.
Without this CA policy, app protection policies are configured but optional. Users who complete Authenticator enrollment get the policy. Users who skip Authenticator do not. There is no enforcement point, and nothing surfaces in Intune to flag the gap.
The “Require approved client app” gap
The same issue that affects Android applies equally to iOS. “Require approved client app” is retiring June 30, 2026. It verifies the app. It does not verify that an app protection policy is active. If your CA policies still use this grant for iOS access, the migration path is the same as Android: switch to “Require app protection policy.” That grant verifies both the app and the active policy state.
Session controls
Apply a shorter sign-in frequency for BYOD users. One to twelve hours depending on your risk tolerance is a reasonable range. Set Persistent browser session to “Never persistent” for any browser-based access on unmanaged devices. These controls apply the same way on iOS as they do on Android and Windows.
For the full Conditional Access configuration detail, read how compliance policies and Conditional Access work together from Part 1 of this series.
What goes wrong at clients?
These are the five situations I find most consistently when auditing iOS BYOD deployments. Some are pure configuration gaps. Most follow the same pattern as Android and Windows: a control was put in place, a prerequisite was missed, and the gap was never detected because nothing failed visibly.
Microsoft Authenticator not installed. Policies are assigned. Users have Outlook and Teams. Authenticator is absent. MAM enrollment never completes. The apps behave as unmanaged installs. Nothing in Intune surfaces this as a failure because the device is not enrolled.
Open-in management not configured. Files move from managed Outlook to personal apps through sharing actions without restriction. The copy-paste policy is active. The open-in setting was never enabled. The data boundary exists for typed content but not for files.
“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. It retires June 30, 2026.
User Enrollment adoption failing silently. IT deploys User Enrollment as the BYOD standard. Users encounter the Managed Apple ID requirement and stop. They install personal Outlook instead. IT sees no enrolled devices in this group and escalates it as a communication problem. The actual problem is that Managed Apple IDs were never provisioned for users — the prerequisite infrastructure was never completed.
APNS certificate expired. New iOS enrollments fail. Existing enrolled devices stop receiving policy updates. The certificate expired, and the Apple ID used to create it is no longer accessible to the team that manages Intune.
The pattern is the same across all five: a control was put in place, a prerequisite was missed or a user found a workaround, and an exception was created to keep that user productive. The exception never got closed. The gap has been open for months without anyone noticing.
Which licenses do you need?
iOS MAM requires Intune Plan 1 for app protection policies. Entra ID P1 is required specifically for Conditional Access enforcement. The “Require app protection policy” grant is what makes MAM real. Without CA enforcement, app protection policies can be deployed with only an Intune license. In practice, deploying MAM without CA enforcement means your policies are configured but not required. Both licenses are included in Microsoft 365 Business Premium and E3. Microsoft 365 E5 includes Entra ID P2, which covers all P1 requirements. User Enrollment uses the same licenses. Apple Business Manager or Apple School Manager is free and requires a one-time setup with an Apple ID your organization owns and controls.
| Feature | License Required |
|---|---|
| Intune (MAM + User Enrollment) | Microsoft Intune Plan 1 (included in Business Premium, E3, E5) |
| App protection policies | Microsoft Intune Plan 1 |
| Conditional Access (“Require app protection policy”) | Entra ID P1 (Business Premium, E3) or Entra ID P2 (E5) |
| Apple Business Manager or Apple School Manager | Free (one-time setup) |
| APNS certificate | Free (renewed annually) |
| 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 iPhone and a work iPad?
Yes. App protection policies are user-based, not device-based. A user with two iOS devices can have the policy applied on both, provided Microsoft Authenticator is installed and MAM enrollment is completed on each device independently. Each app instance enrolls separately. A selective wipe targets a specific user and app combination, not the device.
Does User Enrollment give IT access to personal apps or photos?
No. IT has visibility only into the managed volume created during User Enrollment. Personal apps, photos, messages, and contacts in the personal Apple ID partition are invisible to Intune. This is worth communicating clearly before asking users to complete the enrollment. The managed volume wipe removes only the work portion. Personal content is not affected.
My app protection policy is 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 Microsoft Authenticator is installed on the device and that the user completed MAM enrollment through it. Without Authenticator, MAM enrollment cannot complete on iOS, regardless of which apps are installed. 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 corporate app data from each app that has an active Intune app protection policy assigned to the user. Personal files and apps are not touched. With User Enrollment, a managed volume wipe removes the entire managed partition, including all managed apps and their data. Personal data in the personal Apple ID partition remains intact. Neither option requires a full device wipe to remove corporate data.
Is Apple Business Manager or Apple School Manager required for iOS MAM-only BYOD?
No. MAM-only does not require Apple Business Manager or Apple School Manager. Microsoft 365 apps installed from the public App Store support MAM enrollment through Microsoft Authenticator. Apple Business Manager or Apple School Manager is required only for User Enrollment and Supervised. If your BYOD strategy is MAM-only, you can deploy it without any ABM setup. The only prerequisite is Authenticator on each device.