Mobile Device Management & App Protection

Where Windows endpoint hardening lives

This chapter covers iOS and Android device management. For Windows endpoint configuration via the Open Intune Baseline (OIB) — settings catalog policies, compliance policies, the IntuneManagement tool import flow, the CMMC Control Mapping Matrix, USB device control, update rings, and Wi-Fi configuration — see Open Intune Baseline Deployment.

Mobile Enrollment and App Protection

Mobile security in Intune spans two distinct architectural models: Mobile Device Management (MDM), where Intune controls the device; and Mobile Application Management (MAM) — also called App Protection Policies (APP) — where Intune controls only the data inside specific managed apps, leaving the rest of the device untouched.

Apple and Google between them ship a dozen enrollment APIs and modes. For practical decision-making, collapse the spectrum to three tiers, organized by the level of organizational control required rather than by enrollment API:

Tier	What Intune controls	iOS implementation	Android implementation	When to use
Tier 0: Baseline (no enrollment, no Workplace Join)	Nothing — device is unmanaged	Native Mail / OWA / Outlook signed in without Authenticator broker broker: none — device not registered; no SDK policy fetch	Native mail / browser / Outlook signed in without Company Portal broker broker: none — device not registered; no SDK policy fetch	Baseline state — not a deployable posture. Most orgs explicitly block this at the Conditional Access layer using Require app protection policy. See the Tier 0 section below for the upgrade path to Tier 1.
Tier 1: BYOD MAM (no enrollment)	Data inside managed apps only; device is otherwise untouched	App Protection Policies (no enrollment) broker: Microsoft Authenticator (Company Portal not required)	App Protection Policies (no enrollment) broker: Intune Company Portal — installed but not signed in, device not enrolled	BYOD where the device touches only work email and Teams. The default for most BYOD scenarios.
Tier 2: BYOD with managed container	An isolated work container; personal side stays invisible to the org	Apple User Enrollment (requires Managed Apple ID from ABM) broker: Intune Company Portal — drives the User Enrollment flow	Personally-Owned Work Profile (Android Enterprise) broker: Intune Company Portal — drives the Work Profile enrollment	BYOD where you need device-level compliance signals for Conditional Access, or a visible OS-level work/personal boundary — niche tier most orgs skip
Tier 3: Corporate fully managed	The entire device, with non-removable enforcement	ADE supervised (requires ABM) broker: none — ADE enrolls automatically during Setup Assistant; Company Portal cannot enroll Tier 3 devices (optional post-enrollment app for end-user self-service)	Fully Managed (COBO) or COPE broker: Microsoft Intune app (DPC) — Company Portal not used	Any device with persistent access to high-sensitivity data; required when the user must not be able to remove management

The decision reduces to two questions:

1. Does the user need persistent access to high-sensitivity corporate data on mobile? Yes → Tier 3. No → Tier 1 or 2.
2. Is the device personally owned? Yes + MAM is acceptable for the data risk → Tier 1. Yes + need stronger separation → Tier 2. No → Tier 3.

The rest of this chapter walks through each tier's iOS and Android implementation. A reference section at the end covers the full set of enrollment options Apple and Google ship — including edge cases like Apple Configurator manual mode and the legacy Android Device Administrator API — for implementers who need to know exactly which API maps to which tier.

Mapping the tiers to regulatory frameworks

GCC High / CMMC L2

For CMMC L2 environments, Tier 3 (ADE supervised on iOS, Fully Managed or COPE on Android) is required for any mobile device with persistent access to CUI repositories — the non-removable management posture is what defends against the "user unenrolls and walks off with CUI" scenario. Tier 1 (MAM-only) is acceptable for BYOD where the device only touches work email, Teams, and chat (no CUI repositories) — many CMMC L2 organizations land here for the bulk of their workforce. Tier 2 sits between them and is rarely deployed in CMMC contexts because most orgs either accept Tier 1 for BYOD or escalate directly to Tier 3 for CUI-handling personnel.

Commercial

For commercial deployments — including those subject to NIST 800-171 Rev. 3, HIPAA, PCI-DSS, GLBA, or similar — apply the same logic: Tier 3 for high-sensitivity data with persistent mobile access, Tier 1 for general corporate-data access on personal devices, Tier 2 when stronger work/personal separation is needed than app-level controls provide. The data classification rules for "high sensitivity" vary by regulation; the tier framework is regulatory-agnostic.

Two broker gotchas worth internalizing

On Android Tier 3 (Fully Managed), the Device Policy Controller is the Microsoft Intune app — not Company Portal. This is the single biggest source of confusion in Android corporate enrollment; documentation and end-user instructions frequently reference "Company Portal" by reflex when Intune is the actual requirement.

On Android Tier 1 (BYOD MAM), Company Portal must be installed but not signed in. The user does not enroll the device and never opens the app after install. It serves as the broker that the Intune App SDK inside each managed app uses to fetch policy. Without it, App Protection policies will not apply to Outlook, Teams, and other managed apps. (iOS Tier 1 is the opposite: the broker is Authenticator, not Company Portal.)

Tier 0: Baseline (No Workplace Join, No Enrollment)

Below Tier 1 is the baseline state where the user accesses corporate resources from a mobile device with no device registration in Entra, no MDM enrollment in Intune, and no App Protection Policy applied. The device is invisible to both admin portals.

Three flavors on iOS:

Tier 0 path	Device shows in Entra?	Device shows in Intune?	App Protection applies?
Native iOS Mail (EAS or modern auth via Apple Mail)	No	No	No — Apple Mail has no Intune App SDK
Outlook on the Web (Safari)	No	No	No — browser, not a managed app
Outlook iOS app signed in without Authenticator broker	No	No	Possibly partial — Outlook has the SDK, but the policy fetch chain is fragile without the broker

Most organizations explicitly block Tier 0 access at the Conditional Access layer. The CA grant Require app protection policy is the canonical mechanism: it allows access only if the Intune App SDK in a managed app reports policy enforcement is active. Tier 0 sign-ins fail this grant because no policy is being enforced (no SDK, no managed app, or no Workplace Join chain in place).

Why Tier 0 matters even though it's blocked. Tenants commonly discover Tier 0 access is silently happening when they look at Entra sign-in logs and see iPhone entries with no device record attached. The fix is twofold: enable the right CA grants to deny Tier 0 paths, and walk users through the upgrade to Tier 1.

Upgrading from Tier 0 to Tier 1

The trigger that promotes a device from Tier 0 to Tier 1 on iOS is adding the work account inside Microsoft Authenticator. (On Android, it's installing Company Portal so the SDK has a broker to talk to.) That single action causes three things:

1. Workplace Join fires: the device registers with Entra and appears in Entra admin center → Devices as Microsoft Entra registered.
2. The Intune App SDK in any installed managed app (Outlook, Teams, OneDrive) fetches App Protection Policy on next sign-in or check-in, applying enforcement (app PIN, copy/paste blocking, save restrictions). On Outlook iOS, this typically triggers a one-time "Connecting to GovCloud — restart required" prompt for sovereign-cloud tenants, followed by a "Your IT team is helping to secure your device" splash and the PIN-creation prompt.
3. The user appears in Intune admin center → Apps → App protection status within ~1–4 hours of first SDK check-in (occasionally up to 24 hours).

From the user's perspective this looks like one MFA-setup step; from the management chain's perspective it's the moment the device becomes visible to Entra and policy enforcement begins.

Tier 1: BYOD MAM (No Enrollment)

App Protection Policies protect corporate data inside managed apps — Outlook, Teams, OneDrive, Edge, Word, Excel, PowerPoint, and any line-of-business app that integrates with the Intune App SDK. Policies target the user identity, not the device. The device is never enrolled into MDM.

Typical protections:

• Require PIN or biometric to open managed apps
• Block copy/paste, Save As, and data transfer to unmanaged apps
• Block save-to-personal-cloud
• Enforce app-level encryption
• Selective wipe of corporate data only — personal data is never touched

iOS BYOD (MAM)

• Enrollment: none
• Broker: Microsoft Authenticator
• Company Portal: not required

User experience: the user installs Outlook (and Teams, OneDrive, etc.) from the App Store, signs in with their work account, and APP policy applies automatically on first launch. Most users already have Authenticator installed for MFA, so no additional setup is typically needed.

Android BYOD (MAM)

• Enrollment: none
• Broker: Intune Company Portal
• Company Portal: required — installed on the device, but the user does not sign in and the device is not enrolled

User experience: the user installs Company Portal from Google Play (no sign-in), installs Outlook (and Teams, OneDrive, etc.), then signs into the managed apps with their work account. APP policy applies automatically. The Intune App SDK inside each managed app uses Company Portal as the broker to fetch policy from Intune.

This is the exact opposite of iOS: on iOS the broker is Authenticator; on Android the broker is Company Portal.

What Tier 1 enables on the admin side

Capability	Where / how
Selective wipe of work data inside managed apps	Intune admin center → Apps → App selective wipe → Create wipe request, target the user × device. Next SDK check-in (typically within minutes) clears the work mailbox cache, removes the work account from managed apps, and leaves the device and personal data untouched. Useful demo to clients: "we can revoke access without touching the personal device."
Per-app data flow controls — app PIN, copy/paste blocking, save-as restrictions, screenshot redaction, jailbreak detection	All evaluated at the app level by the Intune App SDK; configured in the App Protection Policy itself
Conditional Access grant Require app protection policy	At sign-in, allows access only if the SDK reports policy is enforced. This is the canonical way to require Tier 1 for Exchange Online and SharePoint Online access on mobile, and how Tier 0 paths are typically blocked

What Tier 1 does not enable

• No MDM enrollment, no device-compliance signal, no configuration profiles. The device isn't enrolled, so there's nothing reporting compliance state to Intune. CA grants like Require compliant device will fail because the device exists in Entra but reports no compliance.
• No device-level configuration deployment. You can't push a Wi-Fi profile, a VPN, a certificate, or any other device-level setting. Everything happens inside managed apps.
• No remote wipe of the entire device. Only the work data inside managed apps is wipeable.

This is the Tier 1 design, not a bug. If your operational or regulatory posture requires any of the things above, escalate to Tier 2 or Tier 3.

Upgrading from Tier 1 to MDM enrollment

To get the device into Intune as a managed device — and unlock device-compliance signals, configuration profile push, and device-level controls — the device needs an MDM profile installed. Three paths, in increasing strength:

Apple Device Enrollment via Company Portal (for testing — user-removable). The user installs Company Portal, signs in, and walks through the MDM profile install in Settings → General → VPN & Device Management. The device appears in Intune Devices as Managed by: Intune, Enrollment type: AzureAD. The user can remove the management profile at any time from Settings — making this enrollment unsuitable for high-control deployments where "user can't escape the controls" is a load-bearing requirement. This path is the "corporate-flagged but user-removable" middle ground; it's fine for self-testing what an MDM-enrolled device experience looks like, but inappropriate for production deployment of devices handling regulated data. (See the iOS reference table for where it sits in the full enrollment spectrum.)

Apple User Enrollment (Tier 2 — BYOD with managed container). Requires Apple Business Manager set up at the org plus a Managed Apple ID issued to each user (federated to Entra or assigned manually). The User Enrollment flow installs an MDM profile at the OS level, creating a separate managed work container; personal data is invisible to the org. Cannot be self-tested on a personal device — the org must complete ABM setup and issue the Managed Apple ID first.

Apple Automated Device Enrollment / ADE (Tier 3 — supervised). Requires Apple Business Manager and the device's serial number registered to the org's ABM tenant. During Apple Setup Assistant, the device receives the ADE supervised profile — non-removable, full device management. This is the only path that produces non-removable enforcement, required for any device with persistent access to high-sensitivity data. Cannot be self-tested on a personal device unless the org specifically registers the serial in their ABM tenant — most orgs won't do this for a consultant's personal phone.

For self-testing what an MDM-enrolled experience looks like, Apple Device Enrollment via Company Portal is the only practical option without IT involvement. Accept that the resulting enrollment is user-removable; it's a valid testing tool, not a production posture. For a high-control production posture for personnel handling regulated data, the org must commit to ABM and either Tier 2 (User Enrollment) for BYOD-with-separation or Tier 3 (ADE supervised) for corporate-owned devices.

Tier 2: BYOD with Managed Container

When MAM alone is considered insufficient — for regulated data classification, when device-level compliance signals are needed for Conditional Access, or when the organization wants stronger separation than app-level controls provide — both platforms offer a container-based BYOD model. Intune manages a work container alongside the user's personal space; personal data stays invisible to the org.

iOS — Apple User Enrollment

Apple's BYOD model since iOS 13 — separates work and personal data via a Managed Apple ID distinct from the user's personal Apple ID. Work apps install into a managed container; personal apps and iCloud data are invisible to the org.

Hidden ABM dependency: User Enrollment requires Managed Apple IDs, which are issued from Apple Business Manager — even though the device itself is not ADE-enrolled. Setting up this tier requires an ABM tenant and a Managed Apple ID issued for each user, even if the org has no corporate-owned iPhones in scope.

• Enrollment: user installs Company Portal, signs in with their Entra credentials (federated to ABM if Federation is configured)
• Intune control scope: only the managed work container; selective wipe targets the container only
• Profile removal: user can remove the User Enrollment profile from Settings — personal data is unaffected

Android — Personally-Owned Work Profile

Android's BYOD container model — an Android Enterprise feature that creates a managed work profile alongside the user's personal space.

• Enrollment: Work Profile enrollment driven by Company Portal
• Company Portal: required — user signs in to provision the work container
• Intune control scope: only the work container — Intune can wipe the container without affecting personal data

What "stronger separation" actually means in practice

The boundary in Tier 1 (MAM) lives inside individual apps — Outlook on the phone holds both the user's work account and personal account in the same app instance, with App Protection Policies preventing data from crossing between accounts. The user navigates work vs. personal by switching accounts within an app.

The boundary in Tier 2 (Container) is enforced by the operating system:

• iOS Apple User Enrollment: Work apps install into a separate managed container with its own data sandbox. They appear on the home screen with a small briefcase indicator; their data lives in an isolated volume the personal side cannot read. iCloud Backup for personal data cannot include the work container, and the org cannot see anything in the personal space.
• Android Personally-Owned Work Profile: A separate work profile with its own launcher tab. The user sees two Outlook icons (one personal, one with a work badge), two Chrome icons, two file managers. Personal-profile apps cannot see work-profile apps exist. The work profile can be paused (e.g., off-hours) to silence all work notifications and freeze work apps.

Three scenarios where the OS-level boundary justifies the extra setup over MAM:

1. Device-level compliance signals are needed for Conditional Access — e.g., "block access from devices with rooted personal profiles." MAM cannot deliver this; the device isn't enrolled to report compliance. Tier 2 enrolls the container, which IS reportable.
2. User comfort with the work/personal boundary — even though MAM cannot see anything outside managed apps, the perception of "work has installed software on my phone" can be a friction point. Tier 2 makes the boundary visible to the user, which often resolves the perception problem.
3. Regulatory requirement names "container" or "isolated work space" explicitly — some regulations and customer contracts require container-based separation as written text. MAM may functionally meet the security goal but not the regulation's exact wording.

For BYOD scenarios that don't hit one of these three, MAM is sufficient and the extra setup of Tier 2 is operationally heavier without meaningful security gain.

Tier 1 vs. Tier 2 — when to escalate from MAM to a container

Consideration	Tier 1: MAM	Tier 2: Container
User friction	Minimal — install apps, sign in	Moderate — container provisioning takes several minutes
Separation strength	App-level (data inside managed apps)	Container-level (isolated work space)
Conditional Access grants supported	Require app protection policy only (app-level signal from the Intune App SDK; Require compliant device fails because the device is not enrolled)	Require app protection policy and Require compliant device (the container is MDM-enrolled and reports compliance state to Entra)
Appropriate for regulated data (CUI, ePHI, PCI)	Marginal — depends on regulatory interpretation	Preferred
Remote wipe scope	App data only (selective wipe)	Work container only (personal data preserved)
Operational overhead	Low — no Apple Business Manager needed for iOS	Higher — iOS User Enrollment requires ABM Managed Apple IDs

The general rule: start with Tier 1 (MAM) for most BYOD scenarios. Escalate to Tier 2 when data classification, regulatory exposure, or Conditional Access posture require device-level compliance signals.

Tier 3: Corporate Fully Managed

Org-owned devices that need persistent access to high-sensitivity systems or regulated data. The entire device is managed; the user cannot escape the controls.

iOS — Apple Automated Device Enrollment (ADE)

Prerequisites:

• Apple Business Manager (ABM) tenant
• ABM linked to Intune via an MDM server token
• Devices purchased through an ABM-registered reseller (or Apple direct) so they appear in ABM automatically

Enrollment flow:

1. Device is unboxed and powered on.
2. During Apple Setup Assistant, the device contacts Apple and is handed to Intune.
3. Intune applies the ADE enrollment profile — supervised mode, non-removable MDM, and any Setup Assistant panes configured to skip.
4. User signs in with their Entra ID work account; device is registered to that user.

Company Portal is not required for enrollment. It can optionally be pushed as a required app so users can reset their passcode, view compliance state, or initiate remote actions on their own device.

For legacy inventory not registered in ABM, Apple Configurator 2 can prep devices into your ABM tenant via "Prepare with Apple Business Manager" mode — after which the devices behave exactly as if originally purchased through ABM. Useful for one-time migration of an existing fleet.

Why ABM is mandatory for this tier. Only ABM-driven ADE produces durable supervision. User-driven enrollment via Company Portal — even when the user identifies the device as Corporate — produces a non-supervised enrollment that the user can remove from Settings → General → VPN & Device Management at any time. Apple Configurator without ABM linkage gives supervision that the user can remove via factory reset. For devices that must enforce non-removable management (regulated data, high-sensitivity systems, persistent corporate-resource access), only ABM-driven supervision delivers that posture. The supervision capabilities table in Reference: Full Enrollment Option Spectrum below contrasts what each enrollment mode unlocks.

Android — Fully Managed (COBO) and COPE

Fully Managed (COBO — Corporate-Owned Business-Only): entire device managed; no personal profile. Intune controls everything.

Fully Managed with Work Profile (COPE — Corporate-Owned Personally-Enabled): corporate-owned device with both a managed work profile AND a personal profile. User has a personal app space; the org manages the device-level config but the personal profile remains private to the user. Use COPE when the corporate device should permit personal use without exposing personal data to the org.

Enrollment methods (both modes):

Method	When to Use
QR code	Small-scale rollouts — QR is generated by the Intune Fully Managed enrollment profile and scanned during device OOBE
Google Zero-Touch Enrollment	Large-scale rollouts on supported OEMs (Pixel and most major brands) — devices assigned in the Zero-Touch portal auto-enroll on first boot
Samsung Knox Mobile Enrollment (KME)	Samsung-specific equivalent to Zero-Touch — assigned via the Knox portal
afw#setup token	Manual text entry during OOBE — useful for one-offs, not scale

The Microsoft Intune app is the DPC (Device Policy Controller) on Fully Managed Android. Company Portal is not used on this platform.

Reference: Full Enrollment Option Spectrum

The 3-tier framework above covers the practical decision. For implementers who need to know exactly which Apple or Google enrollment API maps to which tier — and which edge cases sit outside the framework — the full enrollment option set per platform is documented below.

iOS — full enrollment options

Approach	Microsoft / Apple terminology	Tier	Ownership	Profile removable	ABM required	Notes
MAM-only	App Protection Policies (no enrollment)	1	Personal	N/A	No	Apps protected; device untouched
Apple User Enrollment	User Enrollment with Managed Apple ID	2	Personal	Yes	Yes (Managed Apple ID, not device)	Container model; profile is user-removable
Apple Device Enrollment (no ABM)	Profile-based via Company Portal	(none)	Personal or Corporate-tagged	Yes	No	"Corporate" but user-removable; avoid for high-control deployments
Apple Automated Device Enrollment	ADE / Supervised	3	Corporate	No (non-removable)	Yes	Supervised, durable management
Apple Configurator 2 — Prepare with ABM	Apple Configurator + ABM	3	Corporate (legacy inventory)	No (after prep)	Yes	Retrofitting devices not purchased through ABM channels
Apple Configurator 2 — manual supervision	Apple Configurator only	(none)	Corporate	Removable via factory reset	No	Lab/test only; not durable

What supervision unlocks — capabilities available only when the device is ABM-supervised (Tier 3 ADE):

Capability	Without supervision	With supervision (ABM + ADE)
Force passcode complexity, encryption, screen lock	✓	✓
Deploy work apps, manage configurations	✓	✓
Block iCloud Backup / iCloud Photos / AirDrop	—	✓
Force Wi-Fi / VPN / proxy lockdown	—	✓
Single App Mode / kiosk lockdown	—	✓
Remove built-in apps (Safari, App Store, FaceTime)	—	✓
Always-on VPN	—	✓
Prevent user from removing the management profile	—	✓

The last row is the load-bearing one for high-control deployments: a user-removable management profile means a single tap in Settings severs Conditional Access, unenrolls from MDM, and removes the device from compliance reporting. For devices that must enforce non-removable management (regulated data, high-sensitivity corporate access), only Tier 3 (ABM-supervised) is acceptable.

Microsoft documents the iOS enrollment paths at Enrollment options for iOS/iPadOS; Apple's supervision capabilities are documented at the Apple Deployment Reference — Supervised Mode.

Android — full enrollment options

Approach	Microsoft / Google terminology	Tier	Ownership	Personal data visible to org	Notes
MAM-only	App Protection Policies (no enrollment)	1	Personal	No	Apps protected; device untouched
Personally-Owned Work Profile	Android Enterprise BYOD Work Profile	2	Personal	No	Container model; container is user-removable
Fully Managed (COBO)	Android Enterprise Fully Managed	3	Corporate	N/A — no personal profile	Whole device managed; no personal apps
Fully Managed with Work Profile (COPE)	Android Enterprise Corporate-Owned with Work Profile	3	Corporate	Limited (org manages the device but personal profile is private to the user)	Allows user personal apps in a separate space
Dedicated Devices (COSU)	Android Enterprise Dedicated	(edge)	Corporate	N/A	Kiosks, frontline single-task devices, point-of-sale
Device Administrator (legacy)	Android Device Admin (deprecated)	(avoid)	Personal	Yes	Microsoft and Google have both deprecated; phase out remaining deployments

End-User Communication Templates

Clear platform-specific guidance reduces help desk load. The single biggest source of support tickets in BYOD rollouts is users on Android not installing Company Portal, or users on iOS installing Company Portal unnecessarily.

iOS BYOD users:

To access company email and files on your personal iPhone or iPad:

1. Install Microsoft Authenticator from the App Store (you may already have this for MFA).
2. Install Microsoft Outlook (and Teams, OneDrive as needed) from the App Store.
3. Sign in with your work account. You may be asked to set an app PIN.

You do not need to enroll your device or install the Company Portal app.

Android BYOD users:

To access company email and files on your personal Android device:

1. Install the Intune Company Portal app from Google Play. Do not sign in or enroll the device — just leave it installed.
2. Install Microsoft Outlook (and Teams, OneDrive as needed) from Google Play.
3. Sign into Outlook with your work account. You may be asked to set an app PIN.

Your personal data and apps remain untouched — the company can only manage data inside the work apps.

Play Integrity on Android App Protection

Android App Protection policies can evaluate Google Play Integrity verdicts to detect rooted, emulated, or otherwise tampered devices and block access accordingly. The underlying Graph schema settings still carry the legacy "SafetyNet" prefix (requiredAndroidSafetyNetDeviceAttestationType, requiredAndroidSafetyNetAppsVerificationType), but Google retired SafetyNet Attestation and Intune now evaluates verdicts via the Play Integrity API.

Google's Strong Integrity verdict definition is currently enforced. App Protection policies left at none for device attestation accept any device — including rooted ones — without challenge. Recommended baseline: enable at least basic integrity for device attestation; consider basic & device integrity for higher-sensitivity data.