MAM without enrollment is the part of Microsoft Intune that protects company data inside an app on a device you do not manage, and it is also the part that most often appears to do nothing at all. The policy shows as assigned in the admin centre, the user signs into Outlook on their own phone, and no PIN prompt arrives. There is no error code to search for and no failed deployment to open. What follows is what the service is actually waiting for, the retry intervals that decide when a change takes effect, and the exact error strings that name the cause.
Settle policy precedence first if the same people also carry an enrolled device, because an Intune policy conflict decides which value a device applies and app protection targeting collides in the same quiet way. Every fact below was verified against Microsoft Learn on 4 September 2026.
What MAM without enrollment actually is, and what it will not do
Mobile Application Management for unenrolled devices uses app configuration profiles to configure apps on a device that is never enrolled, and app protection policies to control what happens to the data once it is inside. The two are separate objects and either can be deployed without the other, which is the first thing that catches people: an app configuration profile alone protects nothing. Microsoft supports the pattern on Android, iOS/iPadOS and Windows, and explicitly supports it on devices already enrolled with a third-party MDM, per Microsoft’s guidance on MAM for unenrolled devices.
Three things it does not do, and each of them has been the subject of a support call somewhere this week. Apps are not deployed to the device, so the user installs them from the public store themselves. Certificate profiles are not provisioned. Company Wi-Fi and VPN settings are not provisioned. If your BYOD design assumed any of those would arrive with the policy, the design is wrong rather than the tenant.
It is also worth reading Microsoft’s own position on scope, because it is more restrictive than most blog posts imply. For personal or BYOD devices it is the recommended option. For organisation-owned devices it is marked as not recommended as the only method, with the guidance that those devices should be enrolled and MAM used alongside enrolment for extra protection on specific apps. For user-less devices such as kiosks it is marked unsuitable outright.
The retry clock, and why a licence fix takes twelve hours
This is the part that explains most of the reports that a policy is not applying, and it is the part almost nobody writes about. When an Intune SDK enabled app starts, it asks the Intune MAM service what policy applies. If the answer is unusable, the app does not keep asking. It backs off, and the interval it backs off by depends on why the answer was unusable.
| What the service returns | Retry interval |
|---|---|
| Tenant not onboarded | 24 hours |
| User not licensed | 12 hours, or 24 hours on Android below Intune App SDK 5.6.0 |
| User not assigned any app protection policy | 12 hours |
| User assigned a policy, but this app is not in it | 12 hours |
| User successfully registered for Intune MAM | typically 30 minutes |
| Network connectivity failure | backs off up to 60 minutes, then retries hourly |
Read the second row again. If a user launches Outlook before their Intune licence is assigned, assigning the licence five minutes later changes nothing the user can see. The app is not going to ask again for twelve hours, and on an older Android SDK build it is twenty four. The admin centre will show the licence, show the policy, show the assignment, and show a user who is still unprotected, and every one of those readings is correct. The retry intervals also assume the app is actually being launched and used, so a phone in a drawer never picks anything up. Microsoft documents all of this on the app protection policy delivery and timing page, along with the detail that apps which have not checked in for 90 days may be deregistered from the service automatically.
There is no MAM equivalent of the sync button. With an enrolled Windows device you have several ways to force an Intune sync and confirm it happened. Here the only lever the user has is signing out of the app and back in, or clearing the app data, and the only lever you have is waiting. Plan the sequence accordingly: licence first, policy second, tell the user to launch the app third.
The client prerequisites that are not on the policy page
MAM without enrollment carries two client-side dependencies that the policy blade never mentions, and both of them land on the user rather than on you. On Android the Company Portal app must be installed on the device. It is not used to enrol anything and the user never signs into it as an enrolment step, but a large part of the app protection functionality on Android lives inside it, so without it the protected app has nothing to talk to. Users see a dialog telling them to install it, and the honest answer to the inevitable question is that enrolment is not required but the app is.
On iOS and iPadOS the equivalent is a broker app, in practice Microsoft Authenticator, and it becomes mandatory rather than optional once app-based Conditional Access is in play. If you are pairing this with a Conditional Access policy design using the Require app protection policy grant control, treat Authenticator as a prerequisite you communicate up front, not as something the user discovers at the blocking screen.
One more constraint that surprises people: only one work or school account per device can be managed by MAM at a time. A consultant with two tenants in Outlook will hit this, and the error text is unhelpfully polite about it.
Creating the policy, and the targeting decision that matters
- In the Microsoft Intune admin centre, go to Apps > Protection and select Create policy.
- Choose the platform. App protection policies are created per platform, iOS/iPadOS or Android, so a BYOD rollout is always at least two policies.
- Work through the wizard tabs in order: Basics, Apps, Data protection, Access requirements, Conditional launch, Assignments, Review and create.
- On Apps, set the target. The choices are All Apps, Microsoft Apps, Core Microsoft Apps, or Selected apps. Core Microsoft Apps means Microsoft Edge, Excel, Office, OneDrive, OneNote, Outlook, PowerPoint, SharePoint, Teams, To Do and Word.
- On Assignments, decide the device management state. Filters exist for Unmanaged, Intune managed devices, Android device administrator, Android Enterprise and several others. If you set none, the policy reaches the user on their enrolled corporate device as well as their personal one, which is usually not what a BYOD policy was written for.
- Check the result at Apps > Monitor > App protection status. That report covers app instances that have checked in within the last 90 days.
If more than one team administers Intune, scope the policy as you create it rather than afterwards, because Intune scope tags control what an administrator can see as well as what they can change, and a policy created without one is visible to everybody.
The failure modes
These are the strings a user will read out to you over the phone, and what each one actually means. All of them are documented by Microsoft on the app protection policy user issues page.
| What the user sees | What it means |
|---|---|
| This app has not been set up for you to use. Contact your IT administrator for help. | No app protection policy targeting that user reaches that app. Check the Apps tab of the policy, not just the assignment. |
| Your organization has not set up your account to access work or school data. | No Intune licence on the account. Assign it, then expect the twelve hour retry. |
| This app must be managed by Microsoft Intune, but your account has not been set up. | The Android wording of the same licence problem. |
| To use your work or school account with this app, you must install the Intune Company Portal app. | Android only. Company Portal is missing. Enrolment is still not required. |
| The work or school account you specified does not have access to this app. | A second work account was used. One MAM managed account per device. Remove the existing one or sign in as the pre-populated user. |
| This app cannot be used because you are using a jailbroken device. | A conditional launch check fired, not a policy delivery failure. The rooted device wording is the Android equivalent. |
| This app must be managed by Microsoft Intune, but we were unable to register this app at this time. | Registration with the MAM service failed. Clear the app data and collect logs through Company Portal before raising anything. |
Removal has its own timing. When you issue a selective wipe, the SDK checks for the request every 30 minutes while the app is in use, and again at first launch when the user signs in with the work account. That is a different action with different consequences from the device level commands, and the distinction between an Intune wipe and a retire is worth being clear on before anyone leaves the organisation.
What I would do differently
I have not run this across a production BYOD fleet. My tenant is a lab with no enrolled devices, so what follows is the documented behaviour and where I would expect it to hurt, not a measured result.
I would assign the Intune licence, publish the policy, and only then tell anybody to open the app. The retry table makes the order matter far more than the settings do, and a pilot that starts with users launching Outlook on day one produces a group who all look broken for half a day and a change request that gets rolled back before it ever worked.
I would set the device management state filter on every policy from the start, even when the answer is that it should apply everywhere. Leaving it empty is a decision that looks identical to not having made one, and six months later nobody can tell which it was.
I would not treat MAM without enrollment as the cheap alternative to enrolment. It is a genuinely different control surface with a different failure profile, and the places it does not reach, certificates, Wi-Fi, VPN and app deployment, are exactly the places a BYOD programme tends to discover it needed six weeks in.
Last verified: 4 September 2026
