Intune App Protection Policies for BYOD: Securing Microsoft 365 Data Without MDM Enrollment

A contractor’s personal iPhone has your CEO’s mailbox in Outlook, three confidential decks in OneDrive, and a Teams channel full of unreleased financials — and your security team has zero control over that device. You can’t enforce a passcode, you can’t see what other apps are installed, and the moment that contract ends you have no way to claw the data back. The instinct is to demand they enroll the phone in Intune MDM. They refuse — it’s their phone, they don’t want IT reading their photos or wiping their device, and frankly they’re right to push back. This is the BYOD standoff that plays out in every organization, and the answer is not “enroll harder.”

The answer is app protection policies (APP), delivered through mobile application management without enrollment (MAM-WE). Instead of managing the device, you manage the corporate data inside specific apps. The Intune App SDK — compiled into Outlook, Teams, Edge, OneDrive, Word, Excel and the rest of the Microsoft 365 mobile apps — creates an encrypted, policy-governed container around org data inside each app. You require a PIN to open the container, you block copy-paste and “Save As” out of it, you force corporate links to open in managed Edge, you gate access behind Conditional Access so an unprotected app can’t even reach Office 365, and when the contractor leaves you issue a selective wipe that removes only the org data and never touches a single personal photo. The user keeps their phone fully private; you keep hard control of the data your apps put on it.

This is the complete MAM-WE architecture, end to end, written for the engineer who has to design it, ship it to thousands of users, and defend it in an audit. You will learn exactly how APP works under the hood (the SDK, managed apps, the broker handshake), every policy setting that matters and what each value actually does, how to wire Require app protection policy in Conditional Access (and migrate off the retiring approved-client-app grant), how iOS and Android genuinely differ, when MAM is the wrong tool and MDM is the right one, and how to diagnose the failure modes that bite in production — chief among them the quiet unmanaged-account leak that defeats a careless deployment. Every claim comes with the real setting name, the exact portal path, and az/Graph/PowerShell where it applies.

What problem this solves

The core problem is data residency on devices you don’t own. Microsoft 365 makes corporate data trivially mobile — a user installs Outlook, signs in, and your entire mail and calendar are now on a personal phone. Without a control layer, that data can be copied into WhatsApp, saved to a personal iCloud, screenshotted into the camera roll, forwarded from a personal Gmail account added into the same Outlook, or simply walk out the door on a phone you can never reach again. For regulated data — PHI, PCI, financial, legal-privilege — that is a reportable exposure, not a hypothetical.

The naive fix is full MDM enrollment: take over the whole device, enforce a passcode and encryption, and reserve a remote wipe. It works for corporate-owned hardware and fails for BYOD on two fronts. First, user revolt — people will not enroll personal phones once they understand IT gains device-level visibility and a wipe button, and many route around the policy or refuse mobile entirely. Second, privacy and liability — enrolling personal devices drags the organization into managing hardware it doesn’t own. For contractors, frontline workers, and any “I’ll use my own phone” population, MDM is a poor fit.

MAM-WE solves it by moving the boundary from the device to the app. The control surface is precisely the corporate data inside the managed apps — nothing more. IT sees no personal apps, no photos, no location; the user sees no device takeover and no risk of a full wipe. Who hits this: essentially every organization with BYOD, contractors, M&A populations on separate tenants, shared frontline devices, and anyone whose compliance team asked “can corporate email leak to a personal cloud from a phone we don’t manage?” The honest answer without APP is yes; with APP, no — and you can prove it.

To frame the whole field before the deep dive, here is what each layer of the MAM-WE stack contributes and what breaks if you skip it:

Learning objectives

By the end of this article you can:

• Explain precisely how app protection policies work — the Intune App SDK, managed apps, the policy-managed boundary, and the broker handshake that delivers policy without enrollment.
• Make the MAM-WE vs MDM decision correctly for any BYOD population, and articulate the trade-offs to security, privacy and support stakeholders.
• Author complete iOS and Android app protection policies — every data-relocation, access/PIN, and conditional-launch setting, the values each takes, the default, when to pick which, and the gotcha.
• Close the unmanaged-account leak with IntuneMAMAllowedAccountsOnly, IntuneMAMUPN, and (in multi-tenant/M&A topologies) the tenant-pinning control — the single most important hardening step in MAM.
• Enforce APP with Conditional Access using Require app protection policy, and migrate off the retiring Require approved client app grant safely.
• Configure Edge and Office managed apps correctly, including forcing links into managed Edge and locking Outlook to corporate accounts.
• Execute and verify a selective wipe that removes corporate data only, and configure automatic wipes via conditional launch.
• Drive the monitoring and troubleshooting surface fluently — App protection status, per-user troubleshooting, Graph queries — and resolve the common non-delivery and leakage failures.

Prerequisites & where this fits

You should already understand the basics of Microsoft Intune and Microsoft Entra ID: that Intune is the cloud endpoint-management service, that users and security groups live in Entra, and that MDM enrollment brings an entire device under management with a device object you can target. You should be comfortable with Conditional Access at a conceptual level — that it evaluates sign-ins against conditions and applies grant controls — and able to run az/Microsoft Graph in Cloud Shell or PowerShell. Familiarity with the Microsoft 365 mobile apps (Outlook, Teams, Edge, OneDrive) helps, since they are the subjects of every policy here.

This sits in the Endpoint Management / BYOD security track. It is the app-layer counterpart to device management: where Intune Android Enterprise enrollment and configuration profiles and Intune Autopilot zero-touch provisioning cover managed devices, this covers unmanaged devices with managed data. It depends heavily on the gating mechanics from Conditional Access with device compliance and filters, because Conditional Access is what turns an app protection policy from a suggestion into an enforced boundary. It complements data-classification controls from Purview sensitivity labels, auto-labeling and encryption and Purview DLP across endpoint and Exchange — APP controls movement of data out of apps, while labels and DLP control classification and content.

A quick map of who owns what during a MAM-WE rollout, so you pull in the right people:

Core concepts

Five mental models make every later decision obvious. Internalize these and the settings stop being a checklist and start being a system.

APP manages the data, not the device. This is the whole thing. An app protection policy is a set of rules the Intune App SDK enforces inside a participating app at runtime. The policy has no device object, no enrollment, no view of the OS — it governs exactly what the managed app does with org data: whether it can save it, where it can paste it, whether it requires a PIN, whether it encrypts it. The device is never touched. This is why MAM-WE is the low-friction BYOD answer — you are not asking to manage someone’s phone, only to govern the corporate data your apps deposit on it.

The boundary is “policy-managed apps.” The SDK draws an invisible perimeter around the set of apps under an APP policy for this user’s corporate identity. Inside that perimeter, org data can flow (Outlook → OneDrive → Word, if you allow it). At the perimeter, the controls bite: data leaving for a non-managed app (WhatsApp, native Notes, personal Gmail) is blocked or redirected. The same app can hold both a corporate identity (governed) and a personal identity (not governed) — which is the origin of the unmanaged-account leak, the failure that defeats careless deployments. The policy follows the corporate identity, not the app or the device.

The Intune App SDK is what makes an app “managed.” A policy can only apply to an app that has integrated the Intune App SDK (or, historically, the App Wrapping Tool). The SDK is compiled into the app and intercepts data operations — copy, save, open-in, backup, screenshot (Android) — to enforce policy. The Microsoft 365 apps ship with it built in; a random third-party app does not qualify unless its vendor integrated the SDK and Microsoft published it as a managed app. You cannot “MAM” an app that wasn’t built for it — only SDK-enabled apps can be targeted.

Enrollment is not required, but a broker and (for CA) registration are. MAM-WE means no MDM enrollment — true. But the policy still has to reach the app, and that happens through an authentication broker the user installs: Microsoft Authenticator on iOS, Company Portal on Android. The broker brokers the sign-in and the SDK pulls the policy down on first app launch — this is check-in, the moment a policy goes from “targeted” to “applied.” Separately, the moment you enforce APP via Conditional Access, the device must be registered in Entra ID — a lightweight identity registration that happens silently during sign-in, not MDM enrollment. Registration gives Entra a device identity for CA evaluation; it grants IT no device-level visibility or control.

Wipe is selective and pull-based. Because the SDK owns the org-data container, removing org data is surgical: a selective wipe deletes only the managed app’s corporate data and leaves the app, the device, and all personal content intact. It is pull-based — the wipe executes the next time the user opens the affected app with network connectivity, not instantly pushed. Each protected app reports its own wipe status. The same mechanism powers automatic wipes via conditional launch: jailbreak, offline-grace expiry, or too many PIN failures all trigger a corporate-data wipe with no admin action.

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary at the end repeats these for lookup; this table is the mental model side by side:

MAM-WE versus MDM: the decision

The first architectural call is whether the BYOD requirement is a data problem or a device problem. MAM-WE answers the data problem at the app layer; MDM answers the device problem by taking over the whole device. Getting this fork right saves you a year of fighting users — or a reportable breach.

MAM-WE protects data at the app layer with no enrollment and minimal user-privacy footprint. MDM enrolls the device and enforces OS-level policy (passcode, encryption, restrictions, app inventory) with a full remote-wipe reserve. They are not mutually exclusive — a corporate-owned, enrolled device can also carry APP for defence-in-depth — but for personal phones, MAM-WE is almost always the correct, lower-friction answer. Here is the decision side by side:

Read the decision as a flow: is the device corporate-owned? If yes, enroll it (MDM) and optionally layer APP. If no — it’s personal — do you need OS-level control (passcode, encryption, device restrictions) or only data control? If only data control, MAM-WE is the answer. If you genuinely need OS control on a personal device, the least-bad option is Android Enterprise BYOD work profile (a managed work partition, personal side untouched) rather than full MDM. The matrix that drives the call:

Three hard constraints to internalize before you commit to MAM-WE:

How app protection policies actually work

To configure APP well you have to know what the SDK does at runtime. When a user signs a corporate identity into a managed app through the broker, the SDK contacts the Intune service, downloads the APP policy that targets that user, caches it, and from then on intercepts every data operation the app attempts. The flow has distinct phases, and knowing them tells you exactly where each failure can occur:

The data boundary the SDK enforces is the set of policy-managed apps for that identity. Picture three concentric zones: the corporate identity’s data inside managed apps (fully governed); other managed apps the user can move data into if you allow it; and outside, every unmanaged app and OS surface (camera roll, personal cloud, native share sheet) where the controls block or redirect. The crucial subtlety is that the boundary is per-identity — a personal Microsoft account in the same Outlook is outside the corporate boundary and your policy does nothing to its data, which is exactly why allowed-accounts-only matters.

A few mechanics that surprise people and that you must design around:

Prerequisites for the deployment

Three things must be true before any policy applies: the user is licensed, the broker is on the device, and you have target groups. Each trips people up in a specific way.

Licensing. Every targeted user needs an Intune entitlement. The SKUs that include it:

A user with Office but no Intune entitlement is the number-one “policy never applies” cause. Confirm the assignment, not just the tenant license count.

Broker apps. The authentication broker must be installed even though the device is never enrolled. This differs by platform and is the second-biggest non-delivery cause:

On Android, no Company Portal means no policy enforcement — full stop, even though the device is never enrolled. On iOS, APP can apply without Authenticator in a pure-MAM scenario, but Conditional Access (which you will use) makes Authenticator mandatory, so install it everywhere.

Targeting groups. APP has no device object to target, so you assign policies to users (groups), not devices. Create Entra security groups for your BYOD populations and assign per platform:

# Create BYOD targeting groups via Microsoft Graph (az rest)
az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/groups" \
  --headers "Content-Type=application/json" \
  --body '{
    "displayName": "KV-BYOD-iOS",
    "mailEnabled": false,
    "mailNickname": "KV-BYOD-iOS",
    "securityEnabled": true,
    "description": "BYOD users receiving the iOS app protection policy"
  }'

# Same with Microsoft Graph PowerShell
Connect-MgGraph -Scopes "Group.ReadWrite.All"
New-MgGroup -DisplayName "KV-BYOD-Android" -MailEnabled:$false `
  -MailNickname "KV-BYOD-Android" -SecurityEnabled:$true `
  -Description "BYOD users receiving the Android app protection policy"

A pre-flight checklist before you author a single policy:

Authoring the app protection policy: every setting

This is the meat. You create one policy per platform at Intune admin center → Apps → App protection policies → Create policy → iOS/iPadOS (then repeat for Android). The settings fall into four blocks — Apps (scope), Data protection (relocation), Access requirements (PIN/encryption), and Conditional launch (runtime gates) — enumerated below with values, default, when to change, and the gotcha.

Block 1 — Apps (scope)

Target Selected apps and add the core Microsoft 365 set: Outlook, Teams, Edge, OneDrive, Word, Excel, PowerPoint, OneNote. Targeting only the apps you actually use keeps the PIN-prompt surface small and the user experience tolerable. You also choose an app type — for MAM-WE you target Apps on unmanaged devices, which keeps this policy from colliding with managed-device configuration. The scoping choices:

A frequent mistake is targeting All apps, which pulls in apps you don’t intend and multiplies prompts. Be deliberate.

Block 2 — Data protection (relocation)

This block is the heart of the policy — it stops org data from leaving the managed boundary. Each setting and what its values do:

The two settings that do the most work are Send org data to other apps = Policy managed apps (corporate data shares only into other protected apps, never WhatsApp or personal Gmail) and Save copies of org data = Block with OneDrive/SharePoint allow-list (files save only back into corporate storage). The two most commonly missed are Restrict web content transfer = Microsoft Edge (without it, links open in Safari/Chrome where you have no control) and Receive data from other apps = Policy managed apps (without it, unmanaged data dilutes your boundary).

Block 3 — Access requirements (PIN and encryption)

These control how the user proves they’re allowed to open the org-data container. Each setting:

Max PIN attempts and its failure action (commonly 5 → Reset PIN or Wipe data) is configured here and mirrored in conditional launch. The App PIN when device PIN is set = Require choice deserves the most thought: it adds a second PIN even on a phone that already has a passcode. For sensitive data, require it; for lower-sensitivity data where you trust the OS lock, relaxing it improves UX — but document the risk acceptance.

Block 4 — Conditional launch

Conditional launch sets runtime gates evaluated on every app launch and resume. Each condition has a value threshold and an action: Warn, Block access, or Wipe data. This is where posture turns into enforcement:

The design principle: Warn for things the user can fix (app/OS version) to drive upgrades without lockouts, Block for integrity and policy floors (jailbreak, min SDK), Wipe for terminal posture (long offline). Set offline-grace generously — wiping a consultant’s phone because they were on a long-haul flight is an own-goal.

Assigning the policy and managing it as code

Assign each platform policy to its matching BYOD group. The GUI is the right place to learn the surface; once stable, manage it as code via Microsoft Graph to stop drift. The iOS policy shape via Graph (deviceAppManagement/iosManagedAppProtections):

{
  "displayName": "KV-iOS-APP-BYOD",
  "saveAsBlocked": true,
  "allowedOutboundDataTransferDestinations": "managedApps",
  "allowedInboundDataTransferSources": "managedApps",
  "allowedOutboundClipboardSharingLevel": "managedAppsWithPasteIn",
  "organizationalCredentialsRequired": false,
  "dataBackupBlocked": true,
  "deviceComplianceRequired": false,
  "managedBrowserToOpenLinksRequired": true,
  "managedBrowser": "microsoftEdge",
  "contactSyncBlocked": true,
  "printBlocked": true,
  "notificationRestriction": "blockOrganizationalData",
  "pinRequired": true,
  "minimumPinLength": 6,
  "simplePinBlocked": true,
  "maximumPinRetries": 5,
  "pinCharacterSet": "numeric",
  "periodOfflineBeforeAccessCheck": "PT30M",
  "periodOnlineBeforeAccessCheck": "PT0S",
  "periodOfflineBeforeWipeIsEnforced": "P90D",
  "appDataEncryptionType": "whenDeviceLocked",
  "faceIdBlocked": false,
  "allowedDataStorageLocations": ["oneDriveForBusiness", "sharePoint"]
}

# Create the iOS APP policy via Microsoft Graph PowerShell
Connect-MgGraph -Scopes "DeviceManagementApps.ReadWrite.All"
$params = @{
  "@odata.type"                          = "#microsoft.graph.iosManagedAppProtection"
  displayName                            = "KV-iOS-APP-BYOD"
  saveAsBlocked                          = $true
  allowedOutboundDataTransferDestinations = "managedApps"
  allowedInboundDataTransferSources      = "managedApps"
  allowedOutboundClipboardSharingLevel   = "managedAppsWithPasteIn"
  dataBackupBlocked                      = $true
  managedBrowserToOpenLinksRequired      = $true
  managedBrowser                         = "microsoftEdge"
  pinRequired                            = $true
  minimumPinLength                       = 6
  simplePinBlocked                       = $true
  maximumPinRetries                      = 5
  periodOfflineBeforeAccessCheck         = "PT30M"
  periodOfflineBeforeWipeIsEnforced      = "P90D"
  appDataEncryptionType                  = "whenDeviceLocked"
}
New-MgDeviceAppManagementiOSManagedAppProtection -BodyParameter $params

Manage policy through Graph/Terraform/Bicep only once the console settings are validated — the console teaches the surface, code keeps it from drifting. The Android equivalent uses deviceAppManagement/androidManagedAppProtections with an almost-identical property set, plus Android-only additions like screenCaptureBlocked (iOS cannot block screenshots through APP).

App configuration policies: closing the leaks

App protection controls data movement; app configuration pre-sets behaviour inside the app — and one configuration setting, allowed-accounts-only, is the single most important leak-closer in MAM-WE. There are two delivery channels and choosing the right one is critical:

For BYOD you create a Managed apps configuration at Apps → App configuration policies → Add → Managed apps. The most valuable settings:

Outlook: lock to corporate accounts

The single biggest leak vector is a user adding a personal mailbox into managed Outlook — your APP policy is scoped to the corporate identity, so it does nothing to the personal account’s data. The fix is to forbid non-corporate accounts:

com.microsoft.outlook.EmailProfile.AccountType        = ModernAuth
com.microsoft.outlook.EmailProfile.EmailAddress       = {{userprincipalname}}
com.microsoft.intune.mam.OutlookContactSync           = false
IntuneMAMAllowedAccountsOnly                           = Enabled
IntuneMAMUPN                                           = {{userprincipalname}}

Edge: lock to your tenant and route links

For managed Edge, restrict the accounts and pre-set the org experience:

com.microsoft.intune.mam.managedbrowser.AllowListURLs    = https://*.kloudvin.com|https://*.sharepoint.com
com.microsoft.intune.mam.managedbrowser.bookmarks        = Portal|https://portal.kloudvin.com
com.microsoft.intune.mam.managedbrowser.homepage         = https://portal.kloudvin.com
IntuneMAMAllowedAccountsOnly                              = Enabled

The key configuration values and what each does:

IntuneMAMAllowedAccountsOnly = Enabled paired with IntuneMAMUPN is the control that prevents unmanaged-account leakage — without it, a user can sign their personal Microsoft account into managed Outlook and your APP policy never touches that account’s data. Set it for every app that supports it. In multi-tenant or merger scenarios, UPN alone is insufficient (a home-tenant identity can satisfy a UPN-only gate), so pin the tenant GUID with IntuneMAMOIDCTenantId.

Enforcing with Conditional Access

A policy that isn’t enforced is a suggestion. A user can simply not install Outlook and use the native iOS Mail app or a browser instead — and your beautifully configured APP policy never enters the picture. Conditional Access makes the protected, SDK-integrated apps the only path to Microsoft 365 data on mobile.

Critical 2026 change: the Require approved client app grant is retiring. Build all new policies on Require app protection policy instead. If you still have legacy “approved client app” policies, migrate them now using Require one of the selected controls during the transition, then drop the retiring grant.

Create the policy at Entra admin center → Protection → Conditional Access → New policy with these components:

This forces any mobile client touching Office 365 to be (a) an approved, SDK-integrated app and (b) covered by an APP policy. The native iOS Mail app or a browser on an unprotected device is blocked, with a message to use Outlook/Edge. The grants and what each does:

When this grant is enforced, the device must be registered in Entra ID. The first time a user signs into Outlook they’re silently registered and prompted to install the broker (Authenticator on iOS, Company Portal on Android). This is registration, not enrollment — IT gains no device-level visibility.

A common migration mistake is leaving Require approved client app as the sole grant past its retirement — when it stops functioning, BYOD users silently lose access. Switch to Require app protection policy now; run both with Require one of the selected controls only during the migration window.

Selective wipe: revoking data cleanly

The payoff of MAM-WE: when someone leaves or loses a phone, you remove only the org data, never their personal content. Trigger a wipe at Apps → App selective wipe → Create wipe request: pick the user and the device (devices appear once they’ve checked in under an APP policy).

Intune admin center
  → Apps
    → App selective wipe
      → Create wipe request
         User:   alex@kloudvin.com
         Device: alex-iPhone (MAM)

# Issue a selective wipe via Microsoft Graph (wipeManagedAppRegistrationsByDeviceTag or per-app)
az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/users/alex@kloudvin.com/wipeManagedAppRegistrationsByDeviceTag" \
  --headers "Content-Type=application/json" \
  --body '{ "deviceTag": "alex-iPhone" }'

What actually happens, and the timing that surprises people:

You can also configure automatic wipes via conditional launch (Block 4): jailbreak detection, offline-grace expiry, or max PIN failures all trigger a corporate-data wipe without an admin lifting a finger. The wipe-trigger comparison:

iOS versus Android: the real differences

APP is broadly equivalent across iOS and Android, but the platform mechanics differ in ways that change your policy and your support expectations. The honest comparison:

The headline practical differences: iOS cannot block screenshots through APP (the OS doesn’t expose it), so if screenshot prevention is a hard requirement, only Android can meet it. On Android, Company Portal is non-negotiable as the broker even though nothing is enrolled. Encryption is enabled on both but implemented differently — OS file-protection on iOS, SDK-level on Android — and both honour appDataEncryptionType. Android’s personally-owned work profile (Android Enterprise BYOD) layers APP on top of an already-partitioned work side — a strong combination, but a different posture than pure unmanaged. Plan settings per platform, not as a single cross-platform blob.

Architecture at a glance

Picture the request as it actually flows on a personal phone, and the four control points the architecture imposes. A BYOD user opens managed Outlook and signs in with their corporate identity. The sign-in routes through the broker — Microsoft Authenticator on iOS, Company Portal on Android — which authenticates against Entra ID. At this moment two things happen in parallel: Conditional Access evaluates the sign-in and, because the policy requires Require app protection policy, the device is silently registered in Entra (not enrolled) and the grant is satisfied only if an APP policy is applied; and the Intune App SDK inside Outlook contacts the Intune service and pulls down the app protection policy targeted at this user — the check-in that flips the app from “targeted” to “managed.”

From there the SDK becomes a runtime gatekeeper around the org-data container inside the app. Every data operation hits a control point. Access: the SDK demands the app PIN (or biometric) before the container opens, and conditional launch evaluates posture — OS version, jailbreak/root, offline grace, MTD threat level — blocking or wiping if posture is out of bounds. Data relocation: when the user tries to share a corporate email, Save As a file, or paste org text, the SDK checks the boundary — share goes only to other policy-managed apps, saves go only to OneDrive/SharePoint, paste is allowed only within managed apps; a personal app, the camera roll, or a personal cloud is blocked. Web: a corporate link is forced to open in managed Edge, where your Edge configuration (allow-listed URLs, locked accounts) applies, never in Safari or Chrome. Account boundary: the app configuration policy (IntuneMAMAllowedAccountsOnly) refuses any personal account from being added into the managed app, so there is no ungoverned second identity to leak through.

The crucial thing the architecture does not touch is the device itself. There is no device object, no OS policy, no view of personal apps, photos, or location — the only surface IT can see or act on is the managed-app posture and the org-data container. When the user leaves, a selective wipe removes exactly that container and nothing else: the phone, the apps, and every personal byte remain. The design intent is clear: maximal control over the data your apps deposit, zero control over (and zero visibility into) the personal device that hosts them. That asymmetry is the entire value proposition of MAM-WE — and the reason it survives the BYOD privacy objection that sinks full enrollment.

Real-world scenario

Northwind Advisory is a 4,000-seat professional-services firm that rolled MAM-WE to roughly 900 contractors and partners who would never enroll their personal phones. The pilot on iOS looked clean: Outlook, Teams and Edge under an APP policy with a 6-digit PIN, Send org data to other apps = Policy managed apps, Save copies = OneDrive/SharePoint only, links forced into managed Edge, and a Conditional Access policy requiring app protection on Office 365. Selective wipe tested fine in the lab. They shipped it. For three months it was the textbook BYOD success story the security committee had asked for.

Then they acquired a smaller firm — Contoso Partners — whose ~200 staff lived in a separate, federated Entra tenant. To move fast, identity granted those users cross-tenant access into Northwind’s resources, and the Contoso people started using their home-tenant identity inside Northwind-managed Outlook. APP applied to Northwind’s resource-tenant data correctly. But IntuneMAMAllowedAccountsOnly was configured with IntuneMAMUPN only — a UPN gate — and the inbound cross-tenant access settings were quietly letting the home-tenant identities add a second account into the same managed Outlook. The result: corporate data was now sitting under an identity the Northwind APP policy didn’t fully govern, and when a Contoso contractor was offboarded, the selective wipe targeted the Northwind UPN, reported Wiped, and left data sitting under the Contoso account. Compliance found it during an audit sampling — exactly the leak MAM-WE was supposed to prevent.

The breakthrough was recognizing this as a tenant-boundary problem, not a policy-settings problem. The investigation, via Graph, enumerated every managed-app registration and flagged any whose userId resolved outside the resource tenant:

az rest --method GET \
  --uri "https://graph.microsoft.com/beta/deviceAppManagement/managedAppRegistrations?\$expand=appliedPolicies" \
  --query "value[?userId!=null].{user:userId, app:appIdentifier.bundleId}"

That surfaced dozens of registrations under home-tenant identities. The fix was two-layered. First, lock the inbound cross-tenant trust so only the intended Contoso tenant could resolve, eliminating the silent guest-account additions. Second, re-pin the allowed-account control to the tenant, not just the UPN, by adding the tenant GUID to the app configuration:

IntuneMAMAllowedAccountsOnly  = Enabled
IntuneMAMUPN                  = {{userprincipalname}}
IntuneMAMOIDCTenantId         = 11111111-2222-3333-4444-555555555555

Pinning the tenant GUID stopped the home-tenant identity from satisfying the allowed-accounts gate; only an identity in the resource tenant could add the corporate account. They re-ran the Graph audit weekly until it returned zero out-of-tenant registrations, then folded it into a monthly control. The numbers afterward: 900+ contractors and the new 200 Contoso staff under a single, tenant-pinned MAM-WE posture, zero ungoverned accounts in managed apps, and selective wipe validated to target the correct identity. The lesson on the wall: “In multi-tenant and M&A topologies, MAM’s account controls are only as tight as the cross-tenant access settings underneath them. Pin the tenant, not just the UPN — and audit the registrations, don’t assume the policy.”

Advantages and disadvantages

The “manage the data, not the device” model is exactly right for BYOD and exactly wrong for a few scenarios. Weigh it honestly:

MAM-WE is the right model when the requirement is data control on personal devices and you can live without OS-level enforcement — contractors, partners, frontline, M&A populations, and “I’ll use my own phone” staff. It bites when you genuinely need device-level control (then enroll, or use an Android work profile), when you must block screenshots on iOS, or when you skip allowed-accounts-only and leave the personal-account side door open. Every disadvantage is manageable — but only if you know it exists, which is the point of designing the full stack rather than just turning on a PIN.

Hands-on lab

Build a working MAM-WE posture end to end — an iOS app protection policy, an app configuration policy that closes the account leak, and a Conditional Access policy that enforces it — then validate on a real test phone. Most steps are portal-driven (the MAM surface is GUI-first); the targeting group and validation use az/Graph. Run this in a test/pilot tenant or against a pilot group only — Conditional Access can lock people out.

Step 1 — Create the BYOD targeting group.

az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/groups" \
  --headers "Content-Type=application/json" \
  --body '{
    "displayName": "KV-BYOD-iOS-Pilot",
    "mailEnabled": false,
    "mailNickname": "KV-BYOD-iOS-Pilot",
    "securityEnabled": true
  }'

Add one or two test users (not yourself if you’re the only admin — keep a break-glass account out).

Step 2 — Author the iOS app protection policy. In Intune admin center → Apps → App protection policies → Create policy → iOS/iPadOS:

• Apps: Selected apps → Outlook, Edge, OneDrive, Teams. App type: Apps on unmanaged devices.
• Data protection: Send org data → Policy managed apps; Save copies → Block, allow only OneDrive/SharePoint; Receive → Policy managed apps; Cut/copy/paste → Policy managed apps; Restrict web content → Microsoft Edge; Notifications → Block org data; Encrypt org data → Require.
• Access: PIN → Require; min length 6; Simple PIN → Block; App PIN when device PIN set → Require; Recheck after 30 min.
• Conditional launch: Jailbroken/rooted → Block access; Min OS → Warn; Offline grace → Block at 720 min, Wipe at 90 days; Max PIN attempts 5 → Reset PIN.
• Assignment: the KV-BYOD-iOS-Pilot group.

Step 3 — Add the app configuration policy (managed apps). In Apps → App configuration policies → Add → Managed apps, target the same apps and group, and set:

IntuneMAMAllowedAccountsOnly  = Enabled
IntuneMAMUPN                  = {{userprincipalname}}

For Outlook also add com.microsoft.outlook.EmailProfile.AccountType = ModernAuth and com.microsoft.intune.mam.OutlookContactSync = false.

Step 4 — Create the Conditional Access policy. In Entra admin center → Protection → Conditional Access → New policy:

• Users: include KV-BYOD-iOS-Pilot; exclude your break-glass admin.
• Target resources: Office 365.
• Conditions → Device platforms: iOS. Client apps: Mobile apps and desktop clients.
• Grant: Require app protection policy.
• Start in Report-only mode first to confirm it matches before enforcing.

Step 5 — Validate policy delivery on a real device. On a test iPhone, install Microsoft Authenticator, then Outlook, and sign in with the corporate account. Expected: silent registration prompt, broker handshake, then a prompt to set an app PIN. Confirm check-in:

# List managed app registrations for the test user — confirms check-in
az rest --method GET \
  --uri "https://graph.microsoft.com/beta/users/testuser@kloudvin.com/managedAppRegistrations?\$expand=appliedPolicies" \
  --query "value[].{app:appIdentifier.bundleId, policies:appliedPolicies[].displayName}"

In the portal: Apps → Monitor → App protection status should list the user with Checked in.

Step 6 — Test the data-relocation controls. On the device:

• Open a corporate email, select text, try to paste into native Notes → blocked.
• Try Save As on an attachment → only OneDrive/SharePoint offered.
• Tap a link in a corporate email → opens in managed Edge, not Safari.

Step 7 — Test the account leak is closed. Attempt to add a personal Microsoft account into managed Outlook → rejected by IntuneMAMAllowedAccountsOnly.

Step 8 — Test Conditional Access enforcement. Open the native iOS Mail app (or Safari to Outlook on the web) and try to reach Office 365 → blocked, with a message to use the approved app. (Flip the CA policy from Report-only to On first.)

Step 9 — Test selective wipe. In Apps → App selective wipe → Create wipe request, target the test user + device. Reopen Outlook on the device, wait, and confirm the corporate mailbox disappears while the phone and personal data remain. Confirm the request flips to Wiped:

az rest --method GET \
  --uri "https://graph.microsoft.com/beta/deviceAppManagement/managedAppRegistrations" \
  --query "value[?userId=='testuser@kloudvin.com']"

Validation checklist — what each step proved:

Teardown. Delete the CA policy (or leave it report-only), delete the APP and app configuration policies, and remove the pilot group. No paid resources are consumed by MAM-WE itself — the cost is per-user Intune licensing, which already exists if you got this far.

Common mistakes & troubleshooting

This is the playbook — the part you bookmark. First the scannable symptom → cause → confirm → fix table, then expanded reasoning for the entries that bite hardest.

The expanded form, for the entries that cause the most wasted time:

1. Policy never applies — user unlicensed. The most common cause. Office 365 licenses alone do not include Intune. Confirm the user has an Intune-bearing SKU (M365/EMS E3-E5, Intune Plan 1, Business Premium, or F3) actually assigned, not just present in the tenant. Graph: GET /users/{id}?$select=assignedPlans and look for the Intune service plan. Fix by assigning the license.

2. “Not checked in” — app never opened. Enforcement is pull-based: a policy is “targeted” the moment you assign it but only “checked in” once the user opens a targeted app with that policy. A user who hasn’t launched Outlook shows as targeted-not-checked-in forever. This is your primary non-delivery signal and is almost never a bug — have the user open the app.

6. Personal account still holds data — allowed-accounts-only missing. The quiet, dangerous one. Your APP policy is scoped to the corporate identity, so a personal Microsoft account added into the same managed app is outside the boundary and ungoverned. The only reliable fix is IntuneMAMAllowedAccountsOnly = Enabled plus IntuneMAMUPN in the app configuration policy, set for every app that supports it. Audit explicitly — this is the failure that defeats otherwise-correct deployments.

7. Cross-tenant identity bypasses the gate — UPN-only in M&A. In multi-tenant or merger topologies, a UPN-only allowed-accounts gate can be satisfied by a home-tenant identity, and cross-tenant access settings may silently allow a second account into a managed app. Confirm via the Graph managedAppRegistrations query, flagging any userId outside the resource tenant. Fix by adding IntuneMAMOIDCTenantId (pin the tenant GUID) and locking inbound cross-tenant access to only the intended partner tenant.

8. CA blocks legitimate access — retiring approved-client-app grant. If your enforcement rests solely on Require approved client app, it stops working when that grant retires and BYOD users silently lose access. Confirm in the CA policy’s grant controls and the sign-in logs. Fix by switching to Require app protection policy; during migration run both with Require one of the selected controls, then drop the retiring grant.

9. Wipe reports Wiped but data remains — wrong identity. Selective wipe targets a specific identity. If data sits under a second (cross-tenant or personal) account, a wipe against the corporate UPN reports success while data persists under the other identity. Confirm which userId holds the registration via Graph, re-issue against the correct identity, and pin the tenant to prevent the second identity in the first place.

Best practices

• Always pair APP with Conditional Access “Require app protection policy.” A policy without enforcement is a suggestion; the CA grant makes protected apps the only path to data. Migrate off the retiring approved-client-app grant now.
• Set IntuneMAMAllowedAccountsOnly on every app that supports it. This closes the unmanaged-account leak — the single most important hardening step in MAM-WE. Pair with IntuneMAMUPN, and in multi-tenant topologies add IntuneMAMOIDCTenantId.
• Assign policies to users, not devices — MAM-WE has no device object. Use platform-specific groups (KV-BYOD-iOS, KV-BYOD-Android).
• Use app-type targeting (unmanaged vs managed) to keep MAM-WE configuration from colliding with MDM configuration on dual-enrolled devices.
• Block the big four relocation paths: Send org data → policy-managed; Save As → OneDrive/SharePoint only; Cut/copy/paste → policy-managed; Restrict web content → Edge. These four stop most leaks.
• Use Warn, not Block, for app/OS version conditional launch so you drive upgrades without locking users out; reserve Block for integrity (jailbreak, min SDK).
• Set offline-grace generously for the wipe action (e.g. 90 days) so travelers and drawer phones aren’t wiped prematurely; use a shorter block grace for access.
• Require an app PIN even when a device PIN is set for sensitive data; document a risk acceptance if you relax it.
• Deploy the broker proactively: Authenticator on iOS, Company Portal on Android. On Android it’s mandatory even unenrolled — without it nothing works.
• Manage policy as code once stable. Author in the console to learn the surface, then move to Graph/Terraform to stop drift; review changes in PRs.
• Audit managed-app registrations on a schedule. A periodic Graph query for out-of-tenant or unexpected identities catches leaks the policy can’t.
• Wire MTD (Defender/partner) into conditional launch for device-risk gating without enrollment — a real integrity signal on unmanaged devices.

Security notes

• Least-privilege Conditional Access. Scope the CA policy to the specific BYOD groups and always exclude a break-glass admin account — a misconfigured grant can lock everyone, including you, out of Office 365. Test in Report-only first.
• Encryption is mandatory. Require Encrypt org data so the managed app’s corporate data is encrypted at rest (OS file-protection on iOS, SDK-level on Android). This is your data-at-rest control in the absence of device-wide encryption.
• Close the identity boundary. The unmanaged-account leak is a security control, not a nicety — IntuneMAMAllowedAccountsOnly + tenant pinning prevents an ungoverned identity from holding corporate data inside a managed app. In M&A scenarios, lock inbound cross-tenant access settings underneath it.
• Integrity gating. Use conditional launch to Block (or Wipe) on jailbreak/root and to enforce a minimum SDK/OS floor; layer MTD threat-level gating so a compromised but unenrolled device is blocked from org data.
• Notifications and previews. Set org-data notifications to Block org data so message previews don’t leak content to a lock screen anyone can see.
• Don’t over-trust the device. MAM-WE deliberately has no device-level visibility — that’s the point — so your assurance comes from the app-layer controls. For higher-assurance data, require corporate-credential re-auth, shorter recheck timeouts, and an app PIN even with a device passcode.
• Selective wipe targets identity, not device — validate it removes data under the correct identity, especially across tenants, or you’ll report a clean offboarding while data persists.

The security controls and what each defends against:

Cost & sizing

MAM-WE has no infrastructure cost of its own — there are no servers, no gateways, no per-device charges. The entire bill driver is per-user Intune licensing, which most organizations already hold via Microsoft 365 or EMS bundles. The economics are what make MAM-WE attractive for large BYOD and contractor populations: you pay per user, you deploy to devices you don’t own and don’t buy, and there is no hardware or enrollment-support overhead.

Sizing is about user count, not device count or compute. A few sizing notes:

The cost case versus MDM is decisive for BYOD: MDM implies buying devices or shouldering the support and liability of managing personal hardware; MAM-WE implies neither. For 900 contractors, it is the only economically and politically viable control — the licenses are already in the M365 bundle, and there is nothing else to buy.

Interview & exam questions

1. What is MAM-WE and how does it differ from MDM? MAM-WE (Mobile Application Management Without Enrollment) protects corporate data at the app layer using app protection policies enforced by the Intune App SDK, with no device enrollment. MDM enrolls the whole device and enforces OS-level policy (passcode, encryption, restrictions) with a full-device wipe reserve. MAM-WE is the low-friction BYOD answer; MDM fits corporate-owned hardware.

2. How does an app protection policy actually enforce anything without enrolling the device? The policy targets apps built with the Intune App SDK (the M365 apps). The SDK is compiled into the app and, after the user signs the corporate identity in through a broker (Authenticator/Company Portal), pulls down the policy and intercepts data operations at runtime — PIN, encryption, save, copy, paste, open-in — enforcing the boundary inside the app with no OS involvement.

3. What is the unmanaged-account leak and how do you close it? A user adds a personal account into a managed app; because the APP policy is scoped to the corporate identity, the personal account’s data is ungoverned and can leak. Close it with IntuneMAMAllowedAccountsOnly = Enabled plus IntuneMAMUPN in an app configuration policy, set per app — and in multi-tenant topologies add IntuneMAMOIDCTenantId to pin the tenant, not just the UPN.

4. Which Conditional Access grant enforces app protection, and what’s the 2026 change? Require app protection policy enforces that an APP policy is applied to the app accessing the resource. The Require approved client app grant is retiring — migrate to Require app protection policy now, running both with “require one of the selected controls” during the transition, then drop the retiring grant.

5. Does enforcing APP via Conditional Access require device enrollment? No — it requires device registration in Entra ID, which is a lightweight identity registration that happens silently during sign-in. Registration is not MDM enrollment; IT gains an Entra device identity for CA evaluation but no device-level visibility or control.

6. How does selective wipe work, and what does it remove? It removes only the corporate data inside the managed apps for a specific identity, leaving the device, the apps, and all personal content intact. It is pull-based — it executes the next time the user opens the affected app with network connectivity (typically within ~30 minutes), and each protected app reports its own Pending → Wiped status.

7. Name three iOS-vs-Android differences that affect APP design. (a) iOS cannot block screenshots via APP; Android can (screenCaptureBlocked). (b) Android requires Company Portal as the broker even unenrolled; iOS uses Authenticator (mandatory once app-based CA is on). © Encryption is OS file-protection on iOS vs SDK-level on Android (both honour appDataEncryptionType).

8. What is conditional launch and give three actions it can take. Conditional launch evaluates device/app posture on every launch/resume and takes an action: Warn, Block access, or Wipe data. Examples: jailbroken/rooted → Block; min OS/app version → Warn; offline beyond the grace period → Wipe; max PIN failures → Reset PIN; MTD threat level above threshold → Block.

9. Why does an app show “targeted but not checked in,” and is it a bug? Enforcement is pull-based: a policy is “targeted” when assigned but only “checked in” once the user opens a targeted app with that policy. A user who hasn’t launched the app shows targeted-not-checked-in — almost never a bug; have them open the app.

10. A user is unlicensed for Intune but has Office 365 — will APP apply? No. Office 365 licenses alone do not include Intune. Every targeted user needs an Intune-bearing entitlement (M365/EMS E3-E5, Intune Plan 1, Business Premium, or F3) actually assigned. This is the number-one “policy never applies” cause.

11. What’s the difference between the two app-configuration delivery channels? Managed devices configuration uses the OS MDM channel and works only on enrolled devices. Managed apps configuration uses the Intune App SDK and delivers to apps under an APP policy without enrollment — this is the channel for MAM-WE.

12. How do you give MAM-WE a device-risk signal without enrolling the device? Integrate a Mobile Threat Defense connector (Microsoft Defender for Endpoint, or a partner like Lookout/Zimperium) and add a Max allowed device threat level conditional-launch condition. The MTD app reports the device’s risk score over MAM, and APP blocks or wipes when it exceeds your threshold — real device-risk gating on an unmanaged device.

These map to MD-102 (Endpoint Administrator) — manage apps, app protection, and app configuration policies; Conditional Access — and SC-300 (Identity and Access Administrator) — Conditional Access grant controls. The data-governance angle touches SC-400 (Information Protection). A compact cert mapping:

Quick check

1. A user has an Office 365 E3 license and is targeted by your app protection policy, but the policy never applies. What is the most likely cause?
2. Which app configuration setting closes the “personal account added into managed Outlook” leak, and where do you set it?
3. Which Conditional Access grant should new MAM-WE policies use, and which grant is retiring?
4. You issue a selective wipe; it reports “Wiped” but the corporate data is still on the device. Name the most likely cause.
5. Name one data-protection control you can enforce on Android via APP that you cannot enforce on iOS.

Answers

1. The user is unlicensed for Intune — Office 365 licenses do not include Intune. Assign an Intune-bearing license (M365/EMS E3-E5, Intune Plan 1, Business Premium, or F3). This is the number-one non-delivery cause.
2. IntuneMAMAllowedAccountsOnly = Enabled (paired with IntuneMAMUPN), set in an app configuration policy → Managed apps for Outlook (and every app that supports it). It restricts the managed app to the corporate account.
3. New policies should use Require app protection policy. The Require approved client app grant is retiring — migrate off it, running both briefly with “require one of the selected controls,” then drop it.
4. The wipe targeted the wrong identity — the data is held under a second (cross-tenant or personal) account, so a wipe against the corporate UPN reports success while data persists. Confirm the holding userId via Graph, re-issue against the correct identity, and pin the tenant.
5. Blocking screen capture (screenCaptureBlocked) — Android can block screenshots of org data via APP; iOS cannot (the OS doesn’t expose it). (Also acceptable: blocking Google Assistant scraping.)

Glossary

• MAM-WE (Mobile Application Management Without Enrollment) — the model that protects corporate data inside apps on devices that are not MDM-enrolled.
• APP (App Protection Policy) — the runtime rule set (PIN, encryption, data relocation, conditional launch) the Intune App SDK enforces inside a managed app.
• Intune App SDK — code compiled into an app that intercepts data operations to enforce APP; only SDK-built apps (the M365 apps) can be managed.
• Policy-managed app — an app under an APP policy for a given corporate identity; defines the data boundary the SDK enforces.
• Broker app — Microsoft Authenticator (iOS) or Company Portal (Android); brokers sign-in and delivers/enforces policy without enrollment. Mandatory on Android.
• Check-in — the first download/application of a policy when the user opens a targeted app; the “targeted → managed” transition.
• Conditional launch — APP gates evaluated on app launch/resume (OS/app version, jailbreak, offline grace, PIN attempts, MTD threat level) that Warn, Block, or Wipe.
• Registration (Entra device registration) — a lightweight device identity in Entra ID required by Conditional Access for app-based access; not MDM enrollment.
• Selective wipe — removal of only the corporate data inside managed apps for a specific identity; pull-based, executing on next app launch.
• Data relocation — the APP controls governing where org data can move: send/receive, save copies, cut/copy/paste, web content transfer, backup, notifications.
• IntuneMAMAllowedAccountsOnly — app configuration setting restricting a managed app to corporate accounts; closes the unmanaged-account leak.
• IntuneMAMUPN — pins which account is “allowed” (paired with allowed-accounts-only).
• IntuneMAMOIDCTenantId — pins the tenant (not just the UPN) so a cross-tenant identity can’t satisfy the allowed-accounts gate.
• App configuration policy (managed apps) — pre-sets app behaviour via the SDK without enrollment; the channel for allowed-accounts-only and app-specific config.
• App-type targeting — assigning to managed devices vs unmanaged devices to keep MAM-WE and MDM configuration from colliding.
• MTD (Mobile Threat Defense) — Defender for Endpoint or a partner app that reports device risk over MAM, gating access via conditional launch.
• Require app protection policy — the Conditional Access grant that enforces an APP policy is applied; the current control (the approved-client-app grant is retiring).

Next steps

You can now design, ship, enforce, and troubleshoot a full MAM-WE posture for BYOD. Build outward:

• Next: Conditional Access with Device Compliance and Filters — the gating layer that turns app protection from a suggestion into enforcement, and how filters refine targeting.
• Related: Intune Android Enterprise Enrollment and Configuration Profiles — the managed-device counterpart, including the personally-owned work profile that pairs with APP.
• Related: Intune Autopilot Zero-Touch Provisioning — when the device is corporate-owned and full enrollment is the right call.
• Related: Purview Sensitivity Labels, Auto-Labeling and Encryption — classify and encrypt the data itself, complementing APP’s control of data movement.
• Related: Purview DLP across Endpoint and Exchange — content-aware data-loss prevention that layers with app-layer relocation controls.