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 this 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 marks its own compliance, which is roughly five MAM calls sitting inside a slightly longer token exchange, then declares the device isn't jailbroken.
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. But here's the distinction that often gets lost: 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 registration endpoint 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.
The Attack Surface
Two scenarios make me uneasy when people place implicit trust in MAM as their total 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 DLP Problem
We need to talk honestly about data loss prevention 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.
The Trade-off Reality
This is where the conversation usually collapses into a false binary: lock everything down with MDM, or wave BYOD through with MAM and hope. It isn't a binary. Every option sits on a plane defined by two axes that pull against each other: how much device trust you actually get, and how much cost and management overhead you pay for it.
Plotting them this way exposes two things a simple list hides: plain MAM buys far less security than its price tag suggests, and it's entirely possible to spend more and end up less secure.
Device trust versus cost and management overhead. Plain MAM lands in the low-trust "eyes open" quadrant, not the secure one.
Unmanaged BYOD (bottom-left): cheap, frictionless, and trusts nothing. Nobody defends this for corporate data; it's the baseline you're trying to move away from.
BYOD with MAM (bottom-left, slightly up): the point people misread. MAM is cheap, easy to deploy, and does enforce policy inside the app. But as the registration and DLP gaps above show, the trust it grants rests on nothing sturdier than a self-service device registration an attacker can mint. It nudges you up the trust axis, not into the secure half of the chart. Deploy it knowing that: "fine, with eyes open."
Corporate devices with MDM (top-right): full device trust, compliance verification, attestation, real visibility. You earn it with upfront cost, ongoing management overhead, and staff friction. For data that would cause material harm if it leaked, that's a price worth paying.
MAM plus compensating controls (centre, climbing): the goal for most organisations is to climb the trust axis without paying full MDM cost, by layering the controls in the next section onto MAM: sensitivity-label gating, registration monitoring, network and location constraints, Token Protection. That's the real middle ground: not a vague compromise, but a deliberate decision about what you're protecting, what you're not, and which threats you're accepting versus defending.
The quadrant to design your way out of is the bottom-right: spending on management yet still landing at low trust. That's what happens when you buy MAM, treat it as a security boundary it was never built to be, and pile on process without closing the registration and DLP gaps. Effort without assurance is the worst deal on the board.
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 or time period 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
- Token Protection to limit your exposure to refresh token theft from legitimate devices
When to Require More:
- Highly sensitive data should require MDM and compliant devices. Full stop.
- 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.
But the key insight is this: 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.
When an executive asks "Is our data secure with MAM?", the honest answer is: "It depends on what threats we're defending against and what level of risk we're willing to accept." That might not be the answer they want to hear, but it's the answer that keeps organisations secure.
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
