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

App protection policies (APP) let you containerize corporate data inside the Microsoft 365 mobile apps — Outlook, Teams, Edge, OneDrive — without ever enrolling the device. The user keeps their phone private; you keep control of the org data that lands in those apps, and you can wipe it on demand. This guide builds the full MAM-WE stack end to end.

When MAM-WE is the right architecture (and when it isn’t)

MAM-WE (Mobile Application Management Without Enrollment) protects data at the app layer. MDM enrolls the whole device. The distinction drives the whole BYOD conversation:

Rule of thumb: if employees push back on enrolling personal phones (they will), and your real requirement is “don’t let corporate email leak to the camera roll or a personal cloud,” MAM-WE is the correct, lower-friction answer. You are not trying to manage their device — only the data your apps put on it.

A few hard constraints to internalize before you start:

• App protection on iOS/iPadOS and Android is mature. On Windows it exists only in preview and only for Microsoft Edge — do not plan a Windows BYOD strategy around it.
• MAM-WE itself needs no enrollment, but the Conditional Access layer that enforces it requires the device to be registered in Entra ID (not the same as MDM enrollment — registration is lightweight and happens silently during sign-in).
• Policies apply to apps built with the Intune App SDK or wrapped with the App Wrapping Tool. The Microsoft 365 apps qualify; arbitrary third-party apps do not unless the vendor integrated the SDK.

Step 1 — Prerequisites

• Intune licensing: Microsoft 365 E3/E5, EMS E3/E5, or Intune Plan 1. Every targeted user needs a license.
• Broker apps must be installed on the device. This trips people up because they differ by platform:
  • Android: Company Portal is required as the authentication broker for MAM-WE — even though the device is never enrolled. No Company Portal, no policy enforcement.
  • iOS/iPadOS: Microsoft Authenticator acts as the broker. It is strongly recommended (and required the moment you turn on app-based Conditional Access), though APP can apply to iOS apps without it in pure MAM scenarios.
• Targeting groups: create Entra security groups for your BYOD users (e.g. KV-BYOD-iOS, KV-BYOD-Android). Assign policies to users, not devices — MAM-WE has no device object to target.

Step 2 — Author the app protection policies (iOS and Android)

Create one policy per platform: Intune admin center -> Apps -> App protection policies -> Create policy -> iOS/iPadOS (then repeat for Android). The settings group into three blocks.

Apps

Target Selected apps and add the core M365 set: Outlook, Teams, Edge, OneDrive, Word/Excel/PowerPoint, OneNote. Targeting only the apps you actually use keeps the prompt surface small. You can also scope to app types — for MAM-WE, target Apps on unmanaged devices.

Data protection (relocation)

This is the heart of the policy — it stops data from leaving the corporate boundary:

• Backup org data to iTunes/iCloud / Android backups: Block.
• Send org data to other apps: Policy managed apps (so a corporate email can only be shared into other protected apps, never WhatsApp or a personal Gmail).
• Receive data from other apps: Policy managed apps (or All apps with incoming org data).
• Save copies of org data: Block; then set Allow user to save copies to = OneDrive for Business, SharePoint only.
• Restrict cut, copy, and paste between other apps: Policy managed apps (optionally with paste in to allow incoming pastes only).
• Org data notifications: Block org data (or Allow if you accept message previews on the lock screen).
• Restrict web content transfer with other apps: Microsoft Edge — forces corporate links to open in Edge, where your web policy applies.

Access requirements (encryption + PIN)

• PIN for access: Require. Set PIN type (numeric or passcode), minimum length (6+), and Allow simple PIN = No.
• Max PIN attempts (e.g. 5) and what happens on failure: Reset PIN or Wipe data.
• App PIN when device PIN is set: Require keeps an app-layer PIN even on devices with a passcode; relax to Not required only if you trust the OS lock.
• Recheck the access requirements after (timeout): e.g. 30 minutes offline, plus an offline grace period (e.g. 720 minutes / 12 hours) after which org data is wiped if the device never reconnects.
• Encrypt org data: Require. (On iOS this leverages the OS file-protection APIs; on Android the SDK encrypts the app’s data at rest.)

Conditional launch

Set runtime gates that block or wipe when posture degrades:

• Min OS version — Block access or Warn.
• Jailbroken/rooted devices — Block access (or Wipe data).
• Max PIN attempts — Reset PIN.
• Offline grace period — Wipe data at the threshold above.
• Min app version — Warn, so you can drive upgrades without locking users out.

Assign each policy to the matching BYOD group. Below is the equivalent shape if you manage policy as code via Microsoft Graph (PATCH/POST to deviceAppManagement/iosManagedAppProtections):

{
  "displayName": "KV-iOS-APP-BYOD",
  "saveAsBlocked": true,
  "allowedOutboundDataTransferDestinations": "managedApps",
  "allowedInboundDataTransferSources": "managedApps",
  "allowedOutboundClipboardSharingLevel": "managedAppsWithPasteIn",
  "organizationalCredentialsRequired": false,
  "dataBackupBlocked": true,
  "pinRequired": true,
  "minimumPinLength": 6,
  "simplePinBlocked": true,
  "maximumPinRetries": 5,
  "periodOfflineBeforeWipeIsEnforced": "P0DT12H0M0S",
  "periodOfflineBeforeAccessCheck": "PT30M",
  "appDataEncryptionType": "whenDeviceLocked"
}

Manage these through Graph/Terraform/Bicep only once the GUI settings are stable. The console is the better place to learn the surface; code is the better place to keep it from drifting.

Step 3 — App configuration policies (managed vs MAM)

App protection controls data movement; app configuration pre-sets behavior inside the app. There are two delivery channels, and choosing the right one matters:

• Managed devices configuration uses the OS MDM channel — only works on enrolled devices. Not for BYOD.
• Managed apps configuration uses the Intune App SDK and delivers to apps under an APP policy without enrollment — this is your channel for MAM-WE.

Create one at Apps -> App configuration policies -> Add -> Managed apps. Two high-value examples:

For Outlook, enforce that only the corporate account can be added (the single biggest leak vector is a user adding a personal mailbox into managed Outlook):

com.microsoft.outlook.EmailProfile.AccountType        = ModernAuth
com.microsoft.outlook.EmailProfile.EmailAddress       = {{userprincipalname}}
com.microsoft.intune.mam.OutlookContactSync           = false   # block contact export to native phonebook
IntuneMAMAllowedAccountsOnly                           = Enabled
IntuneMAMUPN                                           = {{userprincipalname}}

For Edge, lock it to your tenant and route bookmarks/proxy:

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

The IntuneMAMAllowedAccountsOnly = Enabled setting 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 will not apply to that account’s data. Set it for every app that supports it.

Step 4 — Enforce with Conditional Access

A policy that isn’t enforced is a suggestion. Conditional Access makes the protected apps the only path to M365 data on mobile.

Critical 2026 change: the Require approved client app grant is retiring in early March 2026. Build all new policies on Require app protection policy instead. If you still have legacy “approved client app” policies, migrate them now.

Create the policy at Entra admin center -> Protection -> Conditional Access -> New policy:

• Users: your BYOD groups (exclude a break-glass admin account — always).
• Target resources: Office 365 (and any other cloud apps that must be protected).
• Conditions -> Device platforms: iOS and Android.
• Conditions -> Client apps: Mobile apps and desktop clients.
• Grant -> Require app protection policy, and combine with Require approved client app only until March 2026 using Require one of the selected controls during the transition; after retirement, leave app protection policy as the sole control.

This forces any mobile client touching Office 365 to (a) be an approved, SDK-integrated app and (b) have an APP policy applied. The native iOS Mail app or a browser on an unmanaged device gets blocked, and the user is told to use Outlook/Edge instead.

When this grant is enforced, the device must be registered in Entra ID. The first time a user signs into Outlook they’ll be 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.

Step 5 — Selective wipe (corporate data only)

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 creates and tracks a separate wipe request per protected app for that user.

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

What actually happens:

• The wipe executes the next time the user opens the affected app — it is not instant and not push-forced.
• Expect it to complete within ~30 minutes of the app launching with network connectivity.
• Each app reports its own status: Pending -> Wiped (or Failed, usually because the app was never reopened).
• Personal apps, photos, accounts, and the device itself are untouched.

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

Verify

Run this on a real test phone — emulators behave differently for the broker handshake.

1. Policy delivery: sign into Outlook on the test device. You should be prompted to register/install the broker, then to set an app PIN. Apps -> Monitor -> App protection status should list the user with Policy: targeted -> Checked in.
2. Data relocation works: open a corporate email, try to copy text into a personal app (e.g. native Notes) — it should be blocked. Try Save As to local storage — only OneDrive/SharePoint should be offered.
3. Unmanaged-account block: attempt to add a personal Microsoft account into managed Outlook — it should be rejected by IntuneMAMAllowedAccountsOnly.
4. Conditional Access: open the native iOS Mail app or Chrome and try to reach Outlook on the web — access should be blocked with a message to use the approved app.
5. Selective wipe: issue a wipe request, 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 in the console.

Reporting and troubleshooting non-delivery

• App protection report: Apps -> Monitor -> App protection status. The main report shows users, platform, app version, policy check-in status, and device type (managed vs unmanaged).
• Per-user drill-down: Troubleshoot + support -> Troubleshoot, enter the user, and view their assigned app protection policies and last check-in.
• Potentially harmful apps / configured vs not-configured: the same blade flags users who are targeted but not yet checked in — your primary signal for non-delivery.

Most non-delivery cases come down to a short list:

Edge cases

• Dual-enrolled devices: if a device is also MDM-enrolled (e.g. corporate Android with a work profile), APP still applies, but be careful targeting the same user with both managed-device and managed-apps configuration — settings can conflict. Use the app type targeting (managed vs unmanaged) to keep them separate.
• Mobile Threat Defense (MTD): integrate a connector (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; APP blocks or wipes when it exceeds your threshold — real device-risk signal without enrolling the device.
• Unmanaged-account leakage is the quiet failure mode of every MAM-WE deployment: a user signs a personal account into a managed app, and your policy — scoped to the corporate identity — never touches it. The combination of IntuneMAMAllowedAccountsOnly = Enabled and the per-app IntuneMAMUPN is the only reliable fix. Audit for it explicitly.

Enterprise scenario

A 4,000-seat professional-services firm rolled MAM-WE to ~900 contractors and the iOS pilot looked clean — until acquisition. They’d onboarded a subsidiary whose users sat in a separate, federated Entra tenant, and those users authenticated into managed Outlook with their home-tenant identity. APP applied to the resource tenant’s data fine, but IntuneMAMAllowedAccountsOnly is evaluated against the device’s home tenant context, and cross-tenant access settings on the inbound side were silently letting guest identities add a second account into the same managed Outlook. Selective wipe targeted the wrong UPN and reported Wiped while data sat under the guest account.

The fix was two-layered. First, lock the inbound cross-tenant trust so only the intended subsidiary tenant could resolve, then re-pin the allowed-account control per app:

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

Pinning the tenant GUID (not just UPN) stopped the home-tenant identity from satisfying the allowed-accounts gate. Second, they audited via Graph for any protected app reporting a userId 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}"

Lesson: in multi-tenant or M&A topologies, MAM-WE’s account controls are only as tight as the cross-tenant access settings underneath them. Validate the home tenant, not just the resource tenant.

Checklist

• Confirmed MAM-WE (not MDM) fits the BYOD requirement
• Intune licenses assigned to all BYOD users
• Broker apps available: Company Portal (Android), Authenticator (iOS)
• iOS and Android app protection policies (relocation, PIN, encryption, conditional launch)
• Managed-apps app configuration for Outlook + Edge with allowed-accounts-only
• Conditional Access: Require app protection policy (not the retiring approved-client-app grant)
• Selective wipe tested and validated as corporate-data-only
• App protection status report and per-user troubleshooting reviewed
• MTD connector wired to conditional launch (device-risk gating)
• Periodic audit for unmanaged personal accounts in managed apps

Pitfalls

The two failures that bite hardest in production are both subtle. First, leaving Require approved client app as your sole grant past March 2026 — it stops working and BYOD users silently lose access; switch to app protection policy now. Second, forgetting allowed-accounts-only, which leaves a wide-open side door for personal accounts that your policy never sees. Get those two right and MAM-WE gives you genuine data control with almost none of the privacy cost — and far less user revolt — than full device enrollment.