Intune MDM vs MAM: When to use which approach

Most IT teams still reach for the same tool every time: full Microsoft Intune device enrollment. That default decision causes real damage: privacy pushback from staff, support tickets that pile up, and Conditional Access policies that quietly stop enforcing what you think they enforce.

This guide gives you a decision matrix for choosing between Mobile Device Management (MDM) and Mobile Application Management (MAM) in Microsoft Intune. We’ll cover the technical scope of each, the scenarios where one clearly wins, the hybrid model that works for most tenants, and the June 30, 2026 Conditional Access change that affects almost every existing app-based policy.

Key Takeaways

MDM manages the device; MAM manages the data inside specific apps. The choice hinges on who owns the device, not on company size.

For BYOD, MAM-only policies on Outlook, Teams, OneDrive, and SharePoint deliver app-level controls without the privacy friction that kills enrollment-based rollouts.

On June 30, 2026, Microsoft retires the standalone “Require approved client app” Conditional Access grant. Every policy using only that control must migrate to “Require app protection policy”.

What’s the difference between MDM and MAM in Intune?

MDM operates at the device layer; MAM operates at the application layer. With MDM, the device itself is enrolled into Intune and IT can enforce things like encryption, OS version, screen lock, and remote wipe. With MAM, only specific managed apps (Outlook, Teams, Word, Excel, OneDrive) get a policy wrapper around them, controlling how corporate data behaves inside the app. Microsoft’s own framing is direct: app protection policies “ensure an organization’s data remains safe or contained in a managed app, regardless of whether the device is enrolled”.

That single sentence is the cleanest mental model you’ll find. MDM asks: is this device trustworthy? MAM asks: is this data leaving the place where it’s allowed to be? The two questions have very different answers depending on who owns the device.

This diagram shows: MDM wins on anything that touches the device itself, MAM wins on anything that touches data inside specific apps, and they overlap meaningfully on selective wipe and DLP. That overlap is the reason most well-run tenants run both, but on different devices, not on the same device.

When should you use MDM in Intune?

Use MDM when the organization owns the device, when regulation requires device-level proof, or when the device has no individual user at all.

The clean MDM scenarios are easy to spot:

Corporate-owned laptops, tablets, and phones issued through procurement. The user has no expectation of privacy on the hardware.
Frontline and shared devices such as warehouse scanners, in-store tablets, hospitality kiosks, hospital carts. There’s no personal data to respect, and full lockdown is the goal.
Regulated workloads where ISO 27001, NIS2, or sector-specific rules require attested device posture before granting access. Auditors want device-level evidence, not app-level promises.
Specialty hardware like Surface Hubs, HoloLens, or dedicated kiosks running a single line-of-business app.

What we see in the field: Most MSP rollouts that go sideways don’t fail because of technical configuration. They fail because of scope creep. A tenant starts with “MDM for laptops” and gradually expands to personal phones, because enrollment gets confused with security. A clear indicator is a spike in support tickets about two weeks after rollout all from users who can no longer install personal apps without a corporate prompt. Set the device-ownership question before you touch a policy.

If you’re managing a mixed fleet of Windows, macOS, iOS, Android, and Linux endpoints, MDM-via-Intune covers the full range without needing a secondary vendor.

When should you use MAM-only?

Use MAM-only when the user owns the device and the only thing you need to protect is corporate data, not the hardware around it. Most employees access work email and Teams from personal phones. If you’re enforcing MDM enrollment on those devices, you’re asking users to hand over management of hardware they own, and that’s where adoption breaks down.

The clean MAM-only scenarios:

BYOD smartphones for email, Teams, and OneDrive access.
Contractors and temporary staff who need 30 days of access without a procurement process.
Mergers and acquisitions during the transition window, where users need M365 access before they’re moved into the unified tenant.
Cross-organizational collaboration with guest users, partner tenants, or joint ventures.

The interesting thing about MAM-only is that it lines up with where breaches actually originate. Look at the 2025 Verizon Data Breach Investigations Report and the threat distribution is striking:

Stolen credentials and exploited vulnerabilities, the top two non-ransomware vectors, are not problems that device enrollment solves. They’re problems that app-level access controls and conditional sign-in solve. MAM addresses both: it enforces a managed-app context for sign-in, blocks copy/paste to unmanaged apps, requires app-level PIN, and lets you wipe corporate data without touching the user’s photos, messages, or banking apps.

Microsoft now layers app protection in three escalating tiers: Enterprise Basic (Level 1), Enterprise Enhanced (Level 2 with DLP), and Enterprise High (Level 3 with Mobile Threat Defense integration). This lets you match the policy strength to the data sensitivity. For a mid-market tenant, Level 2 across all BYOD users is a sensible default. See the app protection data protection framework on Microsoft Learn for the full tier breakdown.

How do you build a hybrid MDM + MAM strategy?

Run MDM and MAM in parallel. MDM for corporate-owned, MAM-only for BYOD. Use Conditional Access to enforce the correct policy based on device ownership. This dual-track approach is what well-run tenants converge on, and the reason is simple: it respects the device-ownership signal that already exists in your environment, rather than forcing one policy stance onto two very different populations.

The decision logic looks like this:

Conditional Access is what binds the two together. For corporate-owned devices, you require a compliant device grant. That means MDM enrollment plus a passing compliance policy. For BYOD, you require an app protection policy grant. That means the user signs in via Outlook or Teams, the app proves it’s wrapped in the policy, and access is allowed without enrolling the underlying phone.

A practical configuration pattern many teams use:

One CA policy targeting iOS/Android with Require app protection policy for the M365 worker apps. Applies to every user.
A second CA policy targeting Windows and macOS with Require compliant device plus Require multifactor authentication. Applies to every user.
Group exclusions for true edge cases (break-glass accounts, service accounts).

In practice, MAM-only rollouts consistently achieve higher voluntary adoption than enrollment-based ones, because users don’t perceive their personal device as being seized by IT. That adoption gap matters: a policy that 40% of users avoid is a policy that doesn’t protect 40% of your data.

Do I already have this?

If your tenant runs Microsoft 365 Business Premium or E3, MDM and MAM are already included. No additional Intune license needed.

What’s changing in 2026 you need to know?

June 30, 2026 is the date that matters. On that date, Microsoft retires the standalone “Require approved client app” Conditional Access grant, and any policy that uses only that control will stop being enforced. The replacement is “Require app protection policy”, a stricter and more capable control that not only checks for an approved client app but also verifies a corresponding Intune app protection policy is applied.

Why does this matter so much? Because thousands of tenants set up “approved client app” CA grants between 2018 and 2022, configured them once, and haven’t touched them since. After June 30, 2026, those policies silently stop providing the protection the security team thinks they’re providing. There’s no breaking error, just an enforcement gap.

The migration checklist is short but non-trivial:

Audit existing CA policies for any using Require approved client app as the sole grant.
For each policy, confirm every targeted app supports Require app protection policy. Not all approved-client apps do, especially older line-of-business connectors.
Stage the new grant in report-only mode for one to two weeks. Watch sign-in logs.
Flip to enforce, retire the old grant control.

Don’t wait until June. Sign-in log analysis is the time-consuming step, and you want it done well before the deadline rather than under pressure.

Frequently asked questions

Can MAM work without enrolling devices in Intune?

Yes. That’s the entire point of MAM-only. App protection policies apply to managed apps regardless of enrollment state, so a personal iPhone or Android can sign into Outlook or Teams, receive the policy, and enforce DLP, PIN, and selective wipe without ever appearing in Intune as a managed device.

Does MAM work on personal iOS and Android devices?

Yes, on both, and that’s where MAM’s biggest value lands. The policy framework supports iOS 16+ and Android 10+ for the main M365 worker apps. Some Level 3 features depend on Microsoft Defender for Endpoint integration, which adds platform-specific requirements. Always check the current OS support matrix before promising universal coverage.

What happens if a user uninstalls a MAM-protected app?

When the user uninstalls the managed app, the corporate data wrapped inside that app goes with it. There’s nothing to recover from the personal device because the data was sandboxed in the app container. Selective wipe via the Intune admin console accomplishes the same thing remotely, on demand, without touching personal photos or messages.

How do I know if my Conditional Access policies are affected by the June 30 deadline?

Open the Entra admin center and go to Security, Conditional Access, Policies. Filter on enabled policies and look for any grant that uses Require approved client app as the sole control, without Require app protection policy alongside it. Those are the policies that will stop enforcing on June 30. Put them in report-only mode first, add the app protection grant, verify sign-in logs for one to two weeks, then switch to enforce.

Which Microsoft 365 license includes MAM?

MAM (app protection policies) is part of Intune Plan 1, which is included in Microsoft 365 Business Premium, E3, E5, F1, F3, and Enterprise Mobility + Security E3 and E5. If you have any of those SKUs, you already own MAM and can deploy it today.

Conclusion

The MDM-vs-MAM choice isn’t actually a comparison. It’s a routing question based on who owns the device. Run MDM where the organization owns the hardware and needs device-level proof. Run MAM-only where the user owns the hardware and you only need to protect the data inside specific apps. Use Conditional Access to bind both tracks to the access decisions that matter.

The two near-term actions that pay back fastest:

Audit your Conditional Access policies before June 30, 2026 and migrate any “approved client app” grants to “app protection policy” grants.
For BYOD, run a Level 2 app protection policy across Outlook, Teams, OneDrive, and SharePoint. These are the four apps that carry 80%+ of mobile corporate-data exposure.