# App Protection Policies block managed-app access when user re-authentication fails (disabled Entra ID accounts, blocked sign-ins, expired tokens)
When App Protection Policies (MAM) do not act on a user authentication failure, an employee who has been off-boarded — or a user whose account has been…
Source: https://maester.dev/docs/tests/ZTA.51013
## Overview
When App Protection Policies (MAM) do not act on a user authentication failure, an employee who has been off-boarded — or a user whose account has been disabled by Identity Protection due to high risk, blocked by Conditional Access, or whose refresh token has been revoked — can continue to read corporate email in Outlook, access files in OneDrive, and participate in Teams chats from their personal phone for an extended window until the auth token cached by the managed app expires (which can be hours or days). Threat actors who compromise an account, off-boarded staff who keep their personal device, or users whose token was revoked after a security incident can use that residual access to exfiltrate corporate data, forward sensitive mail, or screenshot Teams conversations long after the account is supposed to be locked out. The MAM `appActionIfUnableToAuthenticateUser` setting closes this window by instructing managed apps to either block access immediately or wipe corporate data the next time the app tries to refresh the user's auth token and the refresh fails — the precise condition that occurs when an Entra ID account is disabled, blocked by Conditional Access, or has had its tokens revoked. Without an App Protection Policy that sets this action to `block` or `wipe` on both iOS and Android, the off-boarding and token-revocation control plane has a multi-hour blind spot on every personally owned phone in the estate.
## Remediation
- [App protection policies overview](https://learn.microsoft.com/en-us/intune/intune-service/apps/app-protection-policy)
- [iOS app protection policy settings: Conditional launch](https://learn.microsoft.com/en-us/intune/intune-service/apps/app-protection-policy-settings-ios)
- [Android app protection policy settings: Conditional launch](https://learn.microsoft.com/en-us/intune/intune-service/apps/app-protection-policy-settings-android)
- [Create and assign app protection policies](https://learn.microsoft.com/en-us/intune/intune-service/apps/app-protection-policies)
- [Wipe corporate data from Intune-managed apps](https://learn.microsoft.com/en-us/intune/intune-service/apps/apps-selective-wipe)
## Run it
The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```
Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.
About this check
| | |
| --- | --- |
| Severity | High |
| Effort to fix | Low |
| Impact on users | Low |
| Pillar | Devices |
| Category | Devices |
| Product | [Intune](/docs/tests/products/intune) |
| Feature | App protection |
| Area | Access control |
| ATT&CK | [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts, [T1550.001](/docs/tests?mitre=T1550.001) Application Access Token |
| Licence | INTUNE_A |
| Tenant | Workforce |
Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.