MAM vs MDM: Managing Apps vs Managing Devices

A sales rep opens Outlook on her own iPhone, and the question lands on IT's desk: manage the phone, or just the app? The answer decides who can wipe what, what the user gives up, and how many devices ever enroll. That is the MAM vs MDM choice, and this post gives you a rule for making it.

What MDM Controls

Mobile device management enrolls the device itself. Once a phone, tablet or laptop is enrolled, the management service can push apps, Wi-Fi profiles, VPN settings and certificates, enforce a device passcode, check the OS version, and wipe or lock the whole device. On Android that lands as a work profile or a fully managed device; on iOS it's a supervised device or a user enrollment; on Windows it's the Intune agent or a similar tool.

The trade is control for consent. An enrolled device shows up in an inventory with its model, OS build and compliance state. The admin sees the device, not the personal photos on it, but the user has to install a management profile and trust that line. For company-owned hardware nobody argues. For a personal phone, the argument starts at "why can you wipe my phone".

If you're weighing platforms, the MDM solutions comparison covers what enrollment looks like per OS. This post stays on the choice above it.

What MAM Controls

Mobile application management manages the app, and only the work account inside it. Nothing enrolls. The user installs Outlook, Teams or Word from the store, signs in with a work account, and the app pulls down a policy. In Microsoft's terms these are app protection policies, and Microsoft Learn's overview (updated March 2026) puts it plainly: they can be used "independent of any mobile-device management (MDM) solution".

What a policy can do is limited to the app: require a PIN or biometric to open work data, block copy and paste into personal apps, block "save as" to personal storage, encrypt the org data the app holds, and wipe that data on request. A personal Gmail account in the same Outlook app stays untouched because the policy only applies in the work context.

What it cannot do is the list Microsoft publishes for devices without enrollment: apps aren't deployed (the user fetches them), certificate profiles aren't provisioned, and company Wi-Fi and VPN settings aren't pushed. It also only works in apps built with the Intune SDK or wrapped with Microsoft's tool, which covers the Microsoft 365 apps and a published list of third parties, and no others.

Two more constraints matter in practice. On Android the Company Portal app has to be installed even though nothing enrolls, and Microsoft 365 apps need the device registered in Entra ID. And a policy that isn't paired with Conditional Access is a suggestion: Microsoft's own note says to use Conditional Access "to ensure that policies are enforced", because without it a user can sign in from an unprotected browser and skip the whole thing.

MAM vs MDM: The Differences That Matter

The row that decides arguments is the wipe row. An r/Intune admin asked in early 2025 whether to move BYOD iPhones from app protection to full enrollment, and stopped himself with the risk that comes with it: an enrolled fleet means a compromised tenant can wipe every personal phone. That fear is the reason MAM exists.

Where Each One Breaks

Picking MAM for the wrong job fails on day two. A field team that needs the company Wi-Fi certificate, a line-of-business app that isn't SDK-enabled, or a kiosk tablet that must lock down: none of that is reachable from an app policy. The user installs the app, the policy applies, and the thing IT needed to configure is still unconfigured.

Picking MDM for personal phones fails on day one. Enrollment invites go out, a handful of people install the profile, and the tickets that come back are about photos and location, not about Outlook. A January 2026 r/Intune thread titled "MDM on BYOD?" is the same conversation with the same shape: the admin wants visibility, the users want a boundary, and the answer is usually the lighter option.

Two quieter failures round out the set. App protection without Conditional Access leaks through the browser, as above. And a policy targeted to all app types lands on company-managed phones too, so a user on an enrolled device gets a device PIN and an app PIN. Microsoft's fix is to target policies by management state: a stricter policy for unenrolled devices, a lighter one, or none, for enrolled ones.

Intune App Protection Policies in Practice

Microsoft groups its recommended settings into three levels, and the names are worth knowing because they show up in tenders and audits. Level 1, basic, is a PIN, encryption and selective wipe. Level 2, enhanced, adds data transfer limits and a minimum OS version, and Microsoft calls it "applicable to most mobile users accessing work or school data". Level 3, high, adds stronger PIN rules and mobile threat defense for people handling high-risk data.

Selective wipe is the feature to test before you rely on it. The admin issues the wipe from Intune, and the app checks for it on next launch and sign-in, or within its regular check-in window, which Microsoft documents as every 30 minutes while the app is in use. The user keeps the app and everything personal in it.

The reach has grown past phones. Windows MAM protects org data in Microsoft Edge on personal Windows devices, with a Windows Security health check feeding Conditional Access, per Microsoft's October 2025 guidance. On Android, Microsoft's comparison of app policies with work profiles (June 2025) draws the line cleanly: use a work profile when you need to push apps, certificates and Wi-Fi; use app protection when the goal is protecting org data inside apps. On iOS, Apple's account-driven User Enrollment is the middle path, where IT "can manage only an organization's accounts, settings, and information", never the personal account.

This walkthrough of the two models inside Intune, recorded in 2026, is a useful companion if you're setting policies for the first time:

The licensing is simpler than the acronyms. App protection policies need an Intune license on the user and an Entra account; the Microsoft 365 apps need their own Microsoft 365 Apps license. If you already run Intune for laptops, the review of Intune as an RMM replacement covers what the same license reaches on Windows.

The Decision Rule

Start with who owns the device, then with what the device has to reach.

Company-owned phones and tablets get MDM, with app protection layered on top. You paid for the hardware, you can push everything it needs, and you can wipe it when it walks out the door. Layering app policies on enrolled devices adds copy-paste and save-as controls the device layer doesn't have.

Personal devices that only touch Microsoft 365 get MAM plus Conditional Access, and nothing enrolls. That covers email, Teams, files and the Office apps, which is what most BYOD requests are. Write the boundary into your BYOD policy template so users know IT can wipe work data and nothing else.

Personal devices that need more than Microsoft 365 get the lightweight enrollment their platform offers: an Android work profile or an Apple User Enrollment, again with app protection on top. That is how you push a certificate or a line-of-business app without taking the whole phone. The moment the request includes a device-level requirement, MAM alone is the wrong answer, and the platform's own light enrollment is the way to meet it.

Where both fleets exist, and they usually do, run both and target by management state. Microsoft's own example is a company phone enrolled and protected, plus a personal tablet protected only by app policies, for the same user. Laptops and desktops sit outside all of this; they belong to your RMM or unified endpoint management stack, and OpenFrame's device inventory covers those, not phones under MAM.

Short Version

MDM manages the device and can wipe it; MAM manages the work account inside supported apps and can only wipe org data. Company hardware gets MDM. Personal devices get MAM with Conditional Access, and step up to a work profile or User Enrollment only when they need something an app policy can't push. Test the selective wipe before you promise it, and target policies by management state so nobody types two PINs.

Next reads: the MDM solutions comparison for platform choices, and the BYOD policy template for the wording users sign.

FAQ

Is MAM enough for BYOD?
For personal devices that only use Microsoft 365 apps, yes, provided Conditional Access requires an app protection policy. Without that requirement, users can sign in from an unprotected browser. If the device also needs company Wi-Fi, certificates or an app that isn't SDK-enabled, MAM alone isn't enough.

Can MAM wipe a personal phone?
No. A MAM selective wipe removes org data from managed apps and leaves the apps and personal data in place. Wiping the whole device, or the work partition, needs MDM enrollment.

Do I need MDM to use Intune app protection policies?
No. App protection policies apply to unenrolled devices, Intune-enrolled devices and devices enrolled in a third-party MDM. On Android the Company Portal app must be installed and the device registered in Entra ID, but nothing enrolls.

What is the difference between MAM and an Android work profile?
A work profile is a separate partition on the device managed by MDM, so IT can push apps, certificates and Wi-Fi into it. MAM applies policies to individual apps and pushes nothing. Microsoft supports running app protection policies inside a work profile when you need both.