App protection policies are what make Outlook safe on personal phones, but when one doesn't apply, nothing visibly breaks: there's simply no PIN prompt and copy and paste works everywhere. In this post I'll go through the causes in the order I check them, show where to confirm each one, and finish with the Conditional Access piece that makes the policy mandatory.
Symptoms#
- Outlook never asks for an app PIN or biometrics, and there was no Restart Required message after sign-in.
- Data transfer and Save As restrictions aren't enforced.
- The App protection status report shows no policy or app for the user, or a Not checked in status.
- Sign-in is blocked because the app must be protected, or the user is sent to the store to install a broker app.
Why it happens#
App protection applies to a work identity inside an app, not to a device. The Intune App SDK in Outlook checks in with the Intune service as the signed-in work account, and the policy only lands when every condition is true: the user has an Intune licence, belongs to a user group the policy targets, Outlook is in that policy's app list, the user signed in to Outlook with that same account and, on Android, Company Portal is installed.
When a condition isn't met, the app waits and asks again later:
| User state | Next check-in attempt |
|---|---|
| Not licensed for Intune | 12 hours (24 hours on Android apps with an older SDK) |
| No app protection policy assigned | 12 hours |
| Policy assigned, but Outlook isn't in it | 12 hours |
| Successfully registered | Typically every 30 minutes |
Those retries may need the app to be open and in use, so a fix you make now can take a while to show on the phone.
How to fix it#
1. Target users, not devices#
App protection policies must be assigned to user groups; a device group assignment won't apply. Open the policy's assignments, check the user's membership under Groups › All groups, and make sure they aren't in an excluded group.
2. Confirm Outlook is in the right policy#
iOS/iPadOS and Android policies are separate, so check that Microsoft Outlook is listed in the policy for the user's platform. If you target the policy only at apps on Intune-managed iOS devices, Outlook also needs an app configuration policy that sets IntuneMAMUPN and IntuneMAMOID.
3. Check the licence#
The user needs an Intune licence. Open Troubleshooting + support › Troubleshoot and select the user to confirm it at a glance.
4. Check the account signed in to Outlook#
The policy follows the work account, so a personal mailbox in the same app is deliberately left alone. Make sure the user signed in with the targeted account, and that the UPN the app uses matches the UPN in Microsoft Entra ID, which can differ in environments with alternate login IDs. Only one work or school account per device is supported. Also expect drafts to be unprotected: Outlook supports both work and personal contexts, so it doesn't enforce the policy on draft emails.
5. Install the broker apps#
- Android: Company Portal must be installed even without enrollment, because much of the app protection functionality lives in it. Keep it up to date.
- iOS/iPadOS: Company Portal isn't needed for app protection itself, but Microsoft Authenticator is required as the broker once Conditional Access demands app protection.
6. Force a fresh check-in#
Changes for a user who is already signed in can take up to eight hours to arrive. Asking the user to sign out of Outlook and back in, or to restart the device, speeds this up. If registration fails because of network problems, the SDK retries at growing intervals of up to 60 minutes, so check the connection as well.
Verify the fix#
In the admin center#
Go to Apps › Monitor › App protection status, select the Assigned users tile, then Select user. The page shows whether the user is licensed, which apps and devices have checked in, the policy applied and the last sync time. A newly targeted user can take up to 24 hours to appear in the reports.
On the device#
Microsoft Edge for iOS and Android has a built-in diagnostics page. Open Edge, type about:intunehelp in the address bar, choose View Intune App Status and select Outlook. If you only see the app version and a check-in timestamp, no policy is applied. Get Started on the same page collects logs, which you should attach to any support case.
Good looks like this: the report lists Outlook with your policy and a recent check-in, the Edge page shows your settings for Outlook, and the user gets the PIN prompt.
Prevent it next time#
Make it mandatory with Conditional Access#
The Require app protection policy grant blocks access from apps without a policy, which turns app protection from optional into mandatory. It needs the device registered in Microsoft Entra ID through a broker (Authenticator on iOS, Company Portal on Android); users without one are sent to the store. Microsoft has announced the retirement of the older Require approved client app grant, so build new policies on the app protection grant. In report-only mode, a Report-only: Failure result is expected because the control isn't actually enforced.
Tip: roll out the Intune policy first and confirm it in the report before switching Conditional Access on. If Outlook isn't covered by a policy when the sign-in is evaluated, access is denied.
Key takeaways#
- Target user groups, include Outlook in each platform's policy, and license the user.
- Use the same work account in the app as in the assignment, with one work account per device.
- Company Portal on Android; Authenticator on iOS once Conditional Access is involved.
- Confirm with the App protection status report and
about:intunehelprather than guesswork.