Prefer the exploit walkthrough? This is the "how MAM actually works" companion to the endpoint-by-endpoint technical write-up: VULN-172966: Satisfying Entra ID App Protection Conditional Access With a Self-Attested MAM Enrolment.
Intune App Protection (also known as MAM) has always seemed an elegant way to protect your organisation's data without deploying fleets of corporate-managed devices. If we don't own the device, let's manage the application. I've heard it explained as "containers around your data": isolated environments that let users reach corporate information on their personal devices while stopping them from exfiltrating it. The pitch is compelling.
Microsoft themselves pitch it like this:
Microsoft's Own Documentation
People regularly use their mobile devices for both personal and work tasks. While making sure staff can be productive, organizations also want to prevent data loss from applications on devices they may not manage fully.
Intune app protection policies ensure an organization's data remains safe or contained in a managed app. These policies allow you to control how data is accessed and shared by apps on mobile devices. A policy can enforce rules when the user attempts to access or move "corporate" data.
App-based Conditional Access with client app management adds a security layer that makes sure only client apps that support Intune app protection policies can access Exchange Online and other Microsoft 365 services.
App protection policies ensure that the app layer protections are in place.
It sounds secure. But how does it actually work, and what does it truly protect?
This article shares what I learnt when I set out to answer that, and how attackers might be leveraging the gaps against you.
Setting the Scene
A familiar picture. Your organisation holds trade secrets and customer data, living in emails, SharePoint sites, and the occasional Teams chat. Users keep complaining about being locked out on their mobile devices. Mobile Device Management (MDM) would be too expensive and, let's be honest, get abysmal uptake from staff who don't want their personal phones fully managed.
So you reach for the obvious tool: Microsoft Intune App Protection Policies. You require a 6-digit PIN, wipe data after 30 days, and encrypt everything at rest.
Next, you configure Conditional Access to require app protection policies for Microsoft Teams. Everything works. Users are happy. Security is happy. You're golden to knock off early.
But what are you actually protecting?
This is where my journey started.
The Proxy Setup
I decided to watch what happens when a mobile device signs in to Teams behind an HTTPS proxy. After entering username, password and MFA, Teams failed to authenticate:
{
"error": "invalid_grant",
"error_description": "AADSTS53009: Application needs to enforce Intune protection policies. Trace ID: 2acd9617-7adb-4a4d-b5f1-730257ea0900 Correlation ID: 5d326c04-7cf5-4b69-bbb8-5ac0a7024c9b Timestamp: 2025-11-20 13:04:45Z",
"error_codes": [
53009
],
"timestamp": "2025-11-20 13:04:45Z",
"trace_id": "5d326c04-7cf5-4b69-bbb8-5ac0a7024c9b",
"correlation_id": "5d326c04-7cf5-4b69-bbb8-5ac0a7024c9b",
"suberror": "message_only"
}It returns error 53009 which means we are blocked by our "require app protection policy" conditional access rule. Expected behaviour.
Okay, now what? What makes the difference between "access denied" and "welcome back"?
The Enrolment Dance
Watching the traffic flow, I started to piece together the sequence:
The Android device made its initial token request to Entra ID and, as expected, was denied by Conditional Access (2). But rather than stopping there, it registered itself with the enterprise device endpoint (3-4), creating a device object in Entra ID (5-6).
For those less familiar with registration versus enrolment: registration is the lighter-weight process where a device gets an identity in Entra ID and receives a Primary Refresh Token (PRT). This isn't full MDM enrolment: the organisation doesn't control the device, it simply knows about it and trusts its identity via cryptographic certificate exchange.
The device then used this newly minted refresh token, which carries all the device information, to request the MAM Intune resource (7). This exchange for a MAM access token bypasses Conditional Access: the client was Microsoft Teams, but the resource was the MAM endpoint itself, not Teams.
Then I hit a wall. The MAM endpoint uses certificate pinning, so my proxy couldn't see inside. Frustrating for research, but I had to acknowledge it raises the barrier to bypass: security through obscurity, sure, but certificate pinning makes man-in-the-middle (MITM) attacks significantly harder.
When I disabled the proxy and let the process complete naturally, the MAM registration succeeded. Now I could watch the resulting configuration. And there it was: a mysterious new header in subsequent Entra ID authentications (via the PRT v3 flows) named microsoft_enrollment_id.
The client must also declare to the Entra ID authorize endpoint that it is capable of App Protection policies, done by adding a claims header marking it protapp capable via the client capabilities functionality.
With these headers in place, the application could request access tokens scoped for Microsoft Teams. The Conditional Access policy was satisfied. Access granted.
The Hunt Begins
I went hunting for where this MAM enrolment ID lived. The Microsoft Graph API had the answer: the Managed Application Registrations endpoint. The GUID matched. This object held the relationship between the device and the managed app, plus app version, device health status, and last check-in time.
{
"@odata.type": "#microsoft.graph.managedAppRegistration",
"createdDateTime": "2025-01-01T00:02:43.5775965-08:00",
"lastSyncDateTime": "2025-01-01T00:02:49.3205976-08:00",
"applicationVersion": "Modern 42 CA Review Version",
"managementSdkVersion": "Microsoft Intune MAM SDK",
"platformVersion": "iOS 26.1",
"deviceType": "Modern 42 Iphone",
"deviceTag": "Modern 42 Iphone",
"deviceName": "Modern 42 Iphone",
"flaggedReasons": [
"rootedDevice"
],
"userId": "5d326c04-7cf5-4b69-bbb8-5ac0a7024c9b",
"appIdentifier": {
"@odata.type": "microsoft.graph.androidMobileAppIdentifier",
"packageId": "Modern42.ConditionalAccess.Review"
},
"id": "5496aa60-aa60-5496-60aa-965460aa9654",
"version": "1.1.1.1"
}I got momentarily excited when I noticed Graph suggested you could create these registrations for Android. Could it really be this simple?
Spoiler: no. It seems that endpoint was included by mistake.
But this raised the critical question: what actually happens between device registration and access token issuance from a MAM application?
The answer, which took considerable digging to confirm, was surprisingly straightforward: not much. There's no real verification that you're running a legitimate application, or even that the device is genuine rather than emulated.
I eventually went much deeper into the inner workings of this waltz, down a rabbit hole of building my own MAM application and learning more Android development than I'd bargained for. The full endpoint-by-endpoint breakdown lives in the companion write-up, VULN-172966: Satisfying Entra ID App Protection Conditional Access With a Self-Attested MAM Enrolment. At a high level, an attacker registers a managed-app instance and attests its own compliance: roughly five MAM calls sitting inside a slightly longer token exchange, ending with the app declaring the device isn't jailbroken.
When building an Android MAM capable application I learned that the full MAM SDK doesn't live in the application. What ships inside Teams or Outlook is really an offline MAM stub: enough to handle policy management while there's no account or Conditional Access in play. The moment Intune and Entra ID need to get involved, that stub hands off to the real SDK code, which lives in Microsoft Authenticator on iOS and Company Portal on Android. That's why a MAM protected app insists on one of those being installed alongside it, and it's why Teams sometimes asks you to update Microsoft Authenticator rather than Teams itself.
Understanding the Security Model
So let's articulate what MAM actually does: it enforces corporate policy within genuine applications. Teams, Outlook and SharePoint respect the policies you configure in Intune. However, MAM doesn't enforce that the application itself is genuine. It doesn't verify you're running the real Microsoft Teams rather than a counterfeit or emulated version.
The certificate pinning on the Intune API endpoints is good obscurity, but the registration process itself, while not trivial, can be defeated with enough effort. The trust model relies on Microsoft trusting the client to represent itself truthfully and respect the policies it's given. Ultimately the whole system is anchored to the device registration.
And device registrations are designed to be easy: they have to be. The limiting factor for BYOD registration is typically just an MFA requirement.
So here is the whole finding in one breath. MAM protects the data inside a cooperating app: the PIN, the encryption at rest, the copy-and-paste fences and the remote wipe are all genuine, and they hold for as long as the client really is Teams or Outlook honestly applying its policy. What MAM never establishes is that the client is genuine or that the device is real, because the whole chain is anchored to a device registration that is meant to be easy. App protection, then, is not the same thing as data protection the moment you stop assuming the app is honest, and that one assumption is where both the risk below and the controls further down are aimed.
The Attack Surface
Two scenarios make me uneasy when people place implicit trust in Intune App Protection as their total BYOD data protection.
Scenario 1: Token Theft
Let's start with the least likely but still technically feasible. Imagine an attacker running a man-in-the-middle attack (sitting between the victim and the legitimate service to intercept traffic) or otherwise compromising a device. They steal a refresh token generated from a Primary Refresh Token (which carries the device ID for downstream access tokens).
Once issued, these tokens typically aren't constrained by device compliance or network location. An attacker holding a valid refresh token and enrolment ID (readily extracted from downstream access tokens) can impersonate the managed application from anywhere: a different country, network, or device entirely. Entra ID Conditional Access will keep issuing access tokens for Teams, SharePoint and Outlook whenever those tokens are presented.
Scenario 2: Rogue Registration
This is on the more likely side. In default configurations, nothing prevents this attack chain:
- Steal initial authentication credentials (via MITM, device code flow phishing, or credential theft)
- Register a new device in Entra ID (typically requires MFA claim)
- Register a "managed app" against that device
- Start exfiltrating SharePoint documents, Outlook emails, Teams conversations
The attacker doesn't need to compromise the genuine application or a compliant managed device. They just need to convince Entra ID they're running a typical personal mobile device.
The Data Loss Protection Problem
We need to talk honestly about data loss protection (DLP) on MAM-protected personal devices. If MAM is your DLP boundary, these gaps matter. Setting up a proxy to steal a PRT's refresh token is relatively trivial for a determined attacker, or even a disgruntled employee with moderate skills. This isn't nation-state capability. This is "I know how to configure Burp Suite or HTTP Toolkit" capability.
And the economic reality: BYOD saves money and reduces complexity but expands the attack surface. You're trading away control to save cost, and that trade-off needs to be explicit and well understood.
When to Trust MAM
MAM isn't useless. Far from it. But it needs to be deployed with clear eyes about what it does and doesn't do.
MAM Makes Sense For:
- Lower sensitivity data on BYOD devices where convenience is valued.
- Email and calendar access where the risk of compromise is acceptable relative to user productivity
- Organisations that have explicitly accepted the trade-off and understand the residual risk
Compensating Controls You Could Implement:
- Exclude MAM access for specific sensitivity labels. If your data classification includes "Confidential" or "Restricted" labels, consider requiring MDM or compliant devices for that tier
- Limit device registrations by access packages, geographic location, time period or Phishing Resistance where feasible. If all your employees are in Australia, why are registrations coming from the other side of the world? (Remember, VPNs are easy to acquire these days.)
- Implement network location requirements where your architecture allows it
- Strong monitoring of Device Registrations. Alert on unexpected registrations, unusual access patterns (creating then deleting), and registrations from unexpected locations
When to Require More:
- Highly sensitive data should require MDM and compliant devices.
- Move to phishing-resistant MFA for device registration to reduce the risk of initial authentication compromise
- Consider risk-based conditional access policies that account for multiple factors beyond just "has MAM enrolled"
- For organisations with trade secrets or customer data that would cause material harm if exfiltrated, question whether BYOD is appropriate at all for accessing that data
The Bottom Line
MAM is valuable when properly scoped and configured with realistic expectations. It enforces policy compliance within applications and provides a reasonable control layer for low-to-moderate sensitivity data on personal devices.
MAM enforces policy compliance in apps, not app authenticity. It trusts that the client is truthful and will respect the policies it's asked to apply. That trust is anchored to device registration, which is intentionally designed to be easy to create.
As security architects, we must match the control to the risk. We cannot assume app protection equals data protection. Understand the threat model, acknowledge the gaps, and implement compensating controls where those gaps exceed your risk appetite.
Want to see where Modern 42 can help you in your Microsoft Entra ID or Microsoft Intune journey? Reach out to book in a session with one of our engineers.
Timeline
Disclosed to Microsoft Security Response Centre (MSRC) under VULN-172966.
- 3 Feb 2026 - Responsibly disclosed to the Microsoft Security Response Centre
- 11 Mar 2026 - Behaviour confirmed by MSRC and classified as Moderate
- 25 Jun 2026 - Closed as fixed by MSRC
