You assigned an Intune app protection policy (APP, also called MAM) for iOS/iPadOS or Android. Outlook still lets the user copy mail into a personal notes app, Teams never asks for a PIN, and the Intune admin center either shows nothing for that user or a policy with an old Last sync. The ticket says "Intune app protection policy not applying."
Don't retire the device or rebuild the policy yet. App protection runs as a chain that has nothing to do with device enrollment: the user is licensed for Intune → a policy targets the user (not a device group) → the same policy targets that exact app and app type → the user signs in to the app with the targeted work account → the broker app is present (Company Portal on Android) → the app registers and checks in with the Intune MAM service → the settings show up in the app's own diagnostics. Most "APP not applying" tickets stop at a missing license, a device-group assignment, an app that isn't in the policy, a personal account, or delivery timing nobody waited out. Very few come down to "Intune is broken."
If the device is enrolled and MDM policies aren't landing either, start with the Company Portal / device not syncing triage. If the user is being blocked at sign-in by a Conditional Access "require app protection policy" grant, read the sign-in log first with the AADSTS53003 triage. This post covers the case where the app opens fine but app protection isn't there.
TL;DR
- App protection policies target users, not devices. Microsoft says the policy must be assigned to user groups and not device groups. Assigning it to a device group means nothing applies.
- The user needs an Intune license (the iOS and Android error "Account not set up" maps to a missing Intune license). An unlicensed or untargeted user's app then waits for a 12-hour retry interval before it tries again. Fixing the license doesn't produce an instant result.
- Both the policy and the app have to match. Each policy must include the specific app (from Microsoft's protected-apps list, or a line-of-business app built with the Intune App SDK) and the right app type (unmanaged devices, Intune-managed devices, Android personally-owned work profile).
- Android needs Company Portal installed to receive app protection, even without enrollment. Microsoft also now requires Entra device registration on Android for MAM on Microsoft 365 apps.
-
iOS devices enrolled in Intune that you target as "managed" also need app configuration keys
IntuneMAMUPNandIntuneMAMOIDfor the managed apps. - Policy only applies in the work context. A personal account, an Outlook draft, or a new unsaved Word document isn't protected by design.
-
Device truth lives in Edge
about:intunehelp(View Intune App Status) and in the App protection status report, not in the policy's assignment list.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. License | User has an Intune license (Intune Plan 1 service plan) | "Account not set up"; App reporting shows the user isn't licensed for app protection |
| 2. User targeting | User is in an included user group and not in an excluded group | User missing from App protection status; policy assigned to a device group |
| 3. App + app type | Policy includes this app and this management type | "App not set up"; policy applies to Outlook but not Teams; enrolled iOS devices ignored |
| 4. Identity | User signed in to the app with the targeted work account | Works for one account, not another; personal account context unprotected |
| 5. Broker | Android: Company Portal installed and current (plus Entra registration for M365 apps). iOS with app-based CA: Authenticator | "Company Portal required"; "Failed app launch"; prompts to install Authenticator |
| 6. Check-in timing | App registered with the MAM service and checked in recently | Old Last sync; "Not checked in"; changes take hours to show |
| 7. Device-side proof | Edge about:intunehelp lists the app with policy settings |
App shows only version and check-in time, which means no policy is applied |
Pick one user + app + device that should be protected and isn't, and one that works, and compare them at each step.
Step 1: Read the license
Microsoft's deployment troubleshooting guide lists the prerequisites in this order: Intune license, a user in a targeted security group with the same policy targeting the app, and Company Portal on Android. Start with the license.
In the Intune admin center: Apps > Monitor > App protection status > Assigned users tile > Select user. The top of the App reporting page shows whether the user is licensed for app protection and whether they have a Microsoft 365 license, along with app status for all of that user's devices.
Read-only from PowerShell (Microsoft Graph PowerShell SDK):
Connect-MgGraph -Scopes 'User.Read.All','DeviceManagementApps.Read.All'
$upn = 'jdoe@contoso.com'
# Intune Plan 1 shows up as the INTUNE_A service plan inside many SKUs (EMS, M365 E3/E5, Business Premium...)
Get-MgUserLicenseDetail -UserId $upn |
Select-Object SkuPartNumber -ExpandProperty ServicePlans |
Where-Object ServicePlanName -eq 'INTUNE_A' |
Select-Object SkuPartNumber, ServicePlanName, ProvisioningStatus
| Result | Meaning |
|---|---|
INTUNE_A with Success
|
Licensed. Continue to Step 2 |
| No rows | No Intune service plan. App protection isn't active for this user |
INTUNE_A but Disabled
|
The SKU is assigned with the Intune plan switched off in the license options |
If you use Word, Excel, or PowerPoint under APP, Microsoft adds two more requirements: a Microsoft 365 Apps for business or enterprise license, and a managed save location (for example OneDrive) configured through the Save copies of org data setting, with that storage app also targeted.
Step 2: Read user targeting (user groups only)
Microsoft is explicit: "The Intune app protection policy must be assigned to user groups and not device groups." The same article also notes that a newly targeted user can take up to 24 hours to appear in the reports.
| Read | Healthy | Watch for |
|---|---|---|
| Policy Assignments | Included group is a user group containing the user | Device group (common copy-paste from a configuration profile) |
| Excluded groups | User not in any excluded group | Pilot exclusion group that the user was never removed from |
| Group membership | Direct or nested membership resolves to the user | Dynamic group rule that doesn't match the user's attributes |
| Report | User appears under App protection status > User status for the platform | Not listed yet (allow the 24-hour reporting delay before concluding) |
Read the policy, its assignments, and its apps from Graph (read-only, iOS shown; swap the cmdlet nouns to AndroidManagedAppProtection for Android):
$policies = Get-MgDeviceAppManagementiOSManagedAppProtection -All
$policies | Select-Object DisplayName, Id, IsAssigned, DeployedAppCount, LastModifiedDateTime
foreach ($p in $policies) {
"`n== $($p.DisplayName)"
Get-MgDeviceAppManagementiOSManagedAppProtectionAssignment -IosManagedAppProtectionId $p.Id |
ForEach-Object { $_.Target.AdditionalProperties } # groupId + @odata.type (inclusion vs exclusion target)
Get-MgDeviceAppManagementiOSManagedAppProtectionApp -IosManagedAppProtectionId $p.Id |
ForEach-Object { $_.MobileAppIdentifier.AdditionalProperties } # bundleId / packageId
}
# Is the user actually in the included group? (transitive = nested groups count)
Get-MgUserTransitiveMemberOf -UserId $upn -All |
ForEach-Object { [pscustomobject]@{ Id = $_.Id; Name = $_.AdditionalProperties.displayName } }
Compare the group IDs from the assignments with the user's transitive membership. IsAssigned = False means the policy isn't deployed to any inclusion group at all.
Step 3: Read app targeting and app type
Two separate questions: is this app in the policy, and does the policy target this kind of device management?
The app. Targeted apps must use the Intune App SDK, or the policy "may not work correctly." Check that the app appears in Microsoft's Microsoft Intune protected apps list. For line-of-business apps, confirm they're built with a current SDK version. A store app that isn't SDK-enabled can't be protected just by adding its bundle ID.
The app type. When you create the policy, you either target all app types or choose from:
| App type option | Covers | Extra requirement worth reading |
|---|---|---|
| Apps on unmanaged devices | Personal / BYOD devices with no MDM | None beyond Steps 1–5 |
| Apps on Intune-managed devices | Devices enrolled in Intune MDM |
iOS: app configuration keys IntuneMAMUPN and IntuneMAMOID for MDM-managed apps; IntuneMAMDeviceID for third-party and LOB MDM-managed apps |
| Apps in Android personally-owned work profile | Android Enterprise BYOD work profile | Company Portal (Step 5) |
For iOS Intune-managed targeting, Microsoft's iOS data-transfer doc gives the Intune values: IntuneMAMUPN = {{userprincipalname}} and IntuneMAMOID = {{userid}} (string), in an app configuration policy with enrollment type Managed devices. The app must also be installed from Company Portal or pushed as required. If only IntuneMAMDeviceID is configured, Intune APP treats the device as unmanaged, which means a "managed devices only" policy never matches.
Two enrollment notes from the same troubleshooting article:
- iOS Automated Device Enrollment (ADE): User Affinity must be enabled, because any app that needs user authentication under ADE requires it.
- Android Enterprise: the deployment-troubleshooting article says only personally-owned work profiles support app protection among Android Enterprise modes. The newer overview separately documents support for dedicated devices with Shared device mode, and says APP is not supported on dedicated devices without Shared device mode. Check the current platform notes for your exact enrollment type before you build on fully managed devices.
Step 4: Read the identity the user signed in with
App protection is tied to identity. Microsoft: policies are applied only when apps are used in the work context, and the user must sign in to the app with the targeted corporate account. The UPN in the app has to match the Entra UPN.
| Read | Healthy | Broken pattern |
|---|---|---|
| Account in the app | Work/school account of the targeted user | Personal Microsoft account only, or no sign-in at all (some apps run without sign-in) |
| UPN consistency | Sign-in name = Entra UPN (Microsoft recommends UPN = primary SMTP address) | On-premises/alternate login ID, so policy doesn't apply as expected |
| Multiple work accounts | Supported app + Multiple managed accounts (MMA) enforces policy per account | Older guidance: one MAM-enrolled work account per device; a second account gets "Accessing Your Organization's Data" on iOS |
| Auth path | Modern authentication | Basic/legacy auth flows: Microsoft says outcomes are "not consistent or guaranteed" |
On multiple accounts, Microsoft's troubleshooting article still says one work account per device, while the current overview documents Multiple managed accounts (MMA) in supported apps. If only one of two work accounts is protected, check whether that app supports MMA before you call it a bug.
Expected behavior, not bugs (from Microsoft's user-issues article):
| What the user sees | Why |
|---|---|
| Outlook draft email isn't protected | Outlook supports both corporate and personal context and doesn't enforce MAM on drafts |
| New Word/Excel/PowerPoint document isn't protected | Treated as personal context until saved to a corporate location like OneDrive |
| iOS share extension still opens data in unmanaged apps | APP can't control the share extension without device management; Intune encrypts the data instead, so it won't open outside managed apps |
| "Restart Required" dialog | The app just received a policy and has to restart to apply it. Policy is arriving, not failing |
| Prompt to install Authenticator on iOS | App-based Conditional Access needs the broker |
Step 5: Read the broker app (Company Portal on Android)
| Platform | Read | Microsoft's requirement |
|---|---|---|
| Android | Company Portal installed and current | Required to receive app protection policies, even with no enrollment. It works as the policy broker agent. Removing it stops policy updates |
| Android | Entra device registration | Intune MAM on Android requires Microsoft Entra ID device registration for Microsoft 365 apps. Users may get an authentication/registration prompt if the device isn't registered |
| iOS/iPadOS | Authenticator (when CA requires app protection) | The CA "Require app protection policy" grant needs the device registered in Entra through a broker: Authenticator on iOS, Company Portal on Android |
Android dialogs that point straight at this step:
- "Company Portal required: To use your work or school account with this app, you must install the Intune Company Portal app." Install Company Portal. Enrollment isn't required.
- "Failed app launch": Intune found a valid policy, but the app crashes during MAM initialization. Update both the app and Company Portal, then send logs from Company Portal if it persists.
Step 6: Read check-in status and delivery timing
This is where most "it's still not applying" tickets go after the config was fixed. Microsoft's app protection policy delivery timing table:
| User state | What the app does | Retry interval (Microsoft) |
|---|---|---|
| Tenant not onboarded for Intune | App Protection not active | 24 hours |
| User not licensed | App Protection not active | 12 hours (Android needs Intune APP SDK 5.6.0+ for 12; otherwise 24) |
| User not assigned app protection policies | App Protection not active | 12 hours |
| User assigned policies, but this app isn't in them | App Protection not active | 12 hours |
| User successfully registered for Intune MAM | Policy applied; updates on the service interval | Service-defined by load, typically 30 minutes |
Read the notes too:
- Retries may need active app use. If the interval is 24 hours and the user doesn't open the app for 48, the retry happens at 48.
- Network failures use an accelerated retry that backs off to 60-minute intervals until a connection succeeds.
- Apps that haven't checked in for 90 days may be automatically deregistered. They try to re-register at next launch, which may prompt for credentials.
- For users who are already signed in, Microsoft says changes to existing policy may not appear for up to 8 hours. The SDK checks for selective wipe every 30 minutes. To speed things up, Microsoft suggests the user sign out of the app and back in, or restart the device.
In the console: Apps > Monitor > App protection status > Assigned users > Select user shows the policies currently applied, their status, and the last sync time. If the status is Not checked in or the sync is old, Microsoft's next checks are network connectivity and (on Android) the latest Company Portal.
Read the same thing from Graph (read-only). Each managedAppRegistration is one user + app + device instance, with intendedPolicies (what you assigned) and appliedPolicies (what the app had at last sync):
$user = Get-MgUser -UserId $upn -Property Id, UserPrincipalName
# Lists every app registration in the tenant; filter client-side for one user. Large tenants: expect a slow call.
$regs = Get-MgDeviceAppManagementManagedAppRegistration -All |
Where-Object UserId -eq $user.Id
$regs | Select-Object DeviceName, DeviceType, PlatformVersion, ApplicationVersion,
ManagementSdkVersion, LastSyncDateTime, FlaggedReasons,
@{n='App';e={ $_.AppIdentifier.AdditionalProperties.bundleId ?? $_.AppIdentifier.AdditionalProperties.packageId }}
foreach ($r in $regs) {
$intended = (Get-MgDeviceAppManagementManagedAppRegistrationIntendedPolicy -ManagedAppRegistrationId $r.Id).DisplayName
$applied = (Get-MgDeviceAppManagementManagedAppRegistrationAppliedPolicy -ManagedAppRegistrationId $r.Id).DisplayName
[pscustomobject]@{ Device = $r.DeviceName; LastSync = $r.LastSyncDateTime
Intended = $intended -join '; '; Applied = $applied -join '; ' }
}
(The ?? operator needs PowerShell 7. On Windows PowerShell 5.1, read bundleId and packageId as two separate properties.)
| Result | Meaning |
|---|---|
| No registration for that app | App never registered with MAM for this user: Steps 1–5 (license, targeting, identity, broker) |
| Intended set, applied empty, old LastSync | Policy assigned but the app hasn't checked in since: timing, network, or the app isn't being opened |
| Intended = applied, recent LastSync | Policy is applied. Re-read the setting itself (Step 7) or the "expected behavior" table in Step 4 |
FlaggedReasons populated |
Microsoft's example is an app running on a rooted device. Conditional launch is acting on it |
Step 7: Read device-side proof with Edge about:intunehelp
Microsoft's recommended device-data collection works on both iOS and Android:
- Open Microsoft Edge on the device.
- Type
about:intunehelpin the address bar. Edge opens in troubleshooting mode. - Select View Intune App Status, then the affected app.
| What you see | Meaning (Microsoft) |
|---|---|
| App listed with its APP settings | Policy is applied on this device. Compare the values with what you intended |
| Only app version, bundle, and policy check-in timestamp | No policy is currently applied to that app on the device |
| App not listed | App isn't registered with MAM for the signed-in identity (Steps 1–5) |
Get Started on that same screen collects app protection logs. Microsoft says to always include them in a support case when you can. Android users can also upload logs through Company Portal.
The logs record each setting under an internal name. A few that come up in "not applying" tickets, from Microsoft's Review client app protection logs reference:
| Log setting | Values | Admin center setting |
|---|---|---|
AppSharingToLevel |
0 = None, 1 = Policy managed apps, 2 = All apps | Data protection > Send org data to other apps |
AppSharingFromLevel |
0 = None, 1 = Policy managed apps, 2 = All apps | Data protection > Receive data from other apps |
FileSharingSaveAsDisabled |
0 = Allow, 1 = Block | Data protection > Save copies of org data |
PINEnabled |
0 = Not required, 1 = Require | Access requirements > PIN for access |
AuthenticationEnabled |
0 = Not required, 1 = Require | Access requirements > Work or school account credentials for access |
IntuneIdentityUPN (iOS table) |
UPN of the Intune MAM user | Read-only: confirms which identity MAM bound to |
If AppSharingToLevel = 2 in the log, the policy did apply and it allows sharing to all apps. That's a policy-content fix, not a delivery problem.
Decode the error the user actually saw
From Microsoft's user-issues article (iOS and Android wording is close; platform noted where it differs):
| Dialog | Cause (Microsoft) | Step |
|---|---|---|
| App Not Set Up / App not set up | No required app protection policy detected for the app | 2–3: deploy a policy to the user's group that targets this app |
| Account Not Set Up / Account not set up | User has no Intune license | 1 |
| Sign-in Failed (iOS) | Couldn't enroll the user with the MAM service after work sign-in | 2–3 |
| Sign-in failed (Android) | Couldn't authenticate the account. Use the first work account successfully enrolled in this app | 4 (clear app data; update app + Company Portal) |
| Accessing Your Organization's Data (iOS) | Signed in with a second work account different from the MAM-enrolled one | 4 (you may need the user UPN setting for Intune) |
| Company Portal required (Android) | Company Portal missing | 5 |
| Failed app launch (Android) | Valid policy, but the app crashes in MAM init | 5 (update app + Company Portal, send logs) |
| Unable to register the app (Android) | Automatic MAM enrollment failed | 6 (clear app data, send logs via Company Portal) |
| Device Non-Compliant (jailbroken/rooted) | Jailbreak/root detected | Expected enforcement, not a delivery failure |
Conditional Access: "require app protection policy" is a separate control
Intune APP protects data inside the app. The Entra Conditional Access grant Require app protection policy requires an APP-capable app before granting access. They fail in different ways:
- APP not applying with no CA: data leaks, but nothing blocks the user (this post).
- CA requires app protection and the app or broker isn't ready: the user is blocked at sign-in. Read the sign-in log (AADSTS53003 triage) and test changes in report-only first (CA report-only results).
Microsoft notes for the grant: the device must be registered in Entra through a broker (Authenticator on iOS, Company Portal on Android). Apps that don't support the grant are blocked. Microsoft also scheduled the older Require approved client app grant to move to a read-only state on June 30, 2026. Existing policies keep enforcing while enabled, but you can no longer create or edit policies that use it. New policies should use Require app protection policy.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
No INTUNE_A / license plan disabled |
Assign or enable the Intune plan, then have the user relaunch or sign out and back in (12-hour retry otherwise) | Rebuilding the policy |
| Policy assigned to a device group | Reassign to a user group; read exclusions | Adding "All devices" on top |
| App missing from the policy | Add the app (protected-apps list or SDK-enabled LOB) to the existing policy | Creating a second overlapping policy for the same app and user |
| Enrolled iOS devices ignored | Deploy app config with IntuneMAMUPN + IntuneMAMOID (Managed devices), or target all app types deliberately |
Targeting "managed devices" only without the app config keys |
| ADE iOS device, user-auth apps fail | Enable User Affinity in the enrollment profile for new enrollments | Expecting APP on userless ADE devices |
| Android with no Company Portal | Install Company Portal (no enrollment needed); keep it updated | Removing Company Portal after a "MAM without enrollment" rollout |
| Personal account / Outlook draft "not protected" | Explain the work-context design; consider CA requiring app protection for corporate access | Filing it as a policy failure |
| Policy changed, users still see old behavior | Wait out the documented window (up to 8 hours) or have the user sign out and back in / restart | Selective wipe to "force" a refresh, which removes corporate data |
| Fleet rollout of a new APP + CA | Pilot group, report-only CA first, then enforce | Enforcing the CA grant and the APP policy on all users the same day |
FAQ
Why is my Intune app protection policy not applying when it's assigned?
Usually because it's assigned to a device group (APP must target user groups), the user has no Intune license, the specific app or app type isn't in the policy, or the user signed in with a different account. Read Apps > Monitor > App protection status for that user, then Edge about:intunehelp on the device.
Why is the Intune app protection policy not applying on Android?
Android needs the Company Portal app installed to receive app protection, even without device enrollment, and Microsoft now requires Entra device registration for MAM on Microsoft 365 apps. Also check that the policy targets the right app type (for example, Android personally-owned work profile).
Why isn't the app protection policy applying to enrolled iOS devices?
If the policy targets apps on Intune-managed devices, iOS needs app configuration keys IntuneMAMUPN and IntuneMAMOID for the MDM-managed apps (and IntuneMAMDeviceID for third-party and LOB MDM-managed apps). On ADE devices, User Affinity must be enabled.
How long does an Intune app protection policy take to apply?
For a registered user, check-ins are service-defined and typically every 30 minutes. An unlicensed or untargeted user's app retries every 12 hours (24 hours for a tenant not onboarded). Changes to an existing policy can take up to 8 hours for signed-in users. Signing out of the app and back in, or restarting the device, speeds it up.
How do I check whether an app protection policy is applied on the device?
Open Edge on the device, go to about:intunehelp, and select View Intune App Status. If the app shows only its version, bundle, and a check-in time, no policy is applied. If it lists settings, the policy is there, so compare the values with your intent.
Related posts
- AADSTS53003 Blocked by Conditional Access: A Read-First Sign-In Log Triage
- Conditional Access Report-Only Results: Logs vs On
- Company Portal can't connect / device not syncing: a 10-minute triage order
- Compliance before Conditional Access: an Intune enrollment & compliance runway that won't lock out Outlook
Free checklist
App protection usually ships together with a Conditional Access policy that requires it, and that's the half that locks people out of Outlook on a Monday. The free Conditional Access pre-enforcement checklist puts break-glass, pilot groups, and report-only review on one page so the APP + CA rollout happens in the right order:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards, and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack goes well with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=intune-app-protection-policy-not-applying
Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 only read data until you deliberately change an assignment, license, app configuration policy, or Conditional Access grant. Pilot app protection and any CA "require app protection policy" grant on a small user group first, and check current Microsoft docs for app protection prerequisites, supported apps, and delivery timing.
Top comments (0)