Mobile Application Management protects corporate data inside mobile apps while leaving the device unmanaged. The protection boundary sits around the app, the signed in identity, and the work data, so you can secure information on personal, shared, partner, or contractor devices without enrollment or touching the user’s personal setup.
That differs from device management, which assumes OS level control and ownership. MAM removes the device from the trust equation and enforces policy inside the app instead. With that in mind, things like account removal, app PIN prompts, and selective wipes are expected outcomes of a strict local enforcement model, not random bugs.
This post breaks down the model step by step: what MAM is, why it exists, how enforcement works in app, how brokers fit into auth, and what happens on iOS and Android from sign in to steady state.
What is Mobile Application Management
Mobile Application Management, or MAM, is a security model that protects corporate data at the application level. It does not manage the device, does not evaluate device compliance, and does not require enrollment. The device itself is outside the trust boundary by design.
With Mobile Application Management , protection is applied after a user signs in with a work identity. The application becomes a controlled container for corporate data, enforced by the Intune SDK. Everything outside that container remains personal and unmanaged.
Policies apply to how data is accessed, stored, and shared inside the app. When authentication such as a PIN is required, it protects access to corporate data within the app, not the device itself. iOS security settings are not modified and are not relied upon.
MAM has no awareness of device posture. There is no device record, no compliance evaluation, and no configuration channel. Enforcement exists only where the data lives.
The Intune App SDK as the enforcement engine
At the core of Mobile Application Management is the Intune App SDK. This SDK is what turns a normal mobile application into a managed workspace for corporate data. It is not an agent, it is not installed separately, and it does not run as a background service on the device. The SDK is built directly into the application and executes inside the app process itself.
Because of this design, every enforcement decision is made locally by the application rather than by the operating system. The device is not queried for compliance, configuration, or posture. There is no fallback to device level controls. The SDK is the enforcement boundary.
When a user signs in with a work identity, the SDK initializes a protected container inside the application. Corporate data is encrypted and cryptographically bound to that identity. From that moment on, all interactions with work data are mediated by the SDK. Opening files, copying content, sharing data with other apps, background access, and offline behavior are all evaluated against the assigned App Protection Policy.
Authentication requirements enforced by MAM, such as a PIN or biometric unlock, are also implemented by the SDK. These controls protect access to the encrypted app container, not the device. The SDK does not modify system authentication settings and does not rely on device level security guarantees.
The SDK continuously monitors policy state and identity health during runtime. Token refresh, policy updates, and identity consistency are evaluated as part of normal app execution. If the SDK determines that policy can no longer be enforced safely, it does not defer enforcement or attempt recovery through the device. Instead, it performs a selective wipe by removing the protected container, clearing encryption keys and tokens, and returning the application to a personal state.
This behavior often surfaces as a work account being removed from the app. That is not an error condition. It is the SDK enforcing policy in the only way available to it.
Understanding the SDK as a local enforcement engine, rather than a remote management component, is essential to understanding why MAM behaves the way it does.
Why Mobile Application Management
Mobile Application Management exists because device management cannot solve every access scenario. Personal phones, tablets, partner devices, and contractor devices still need access to corporate data, even when enrollment is not acceptable or possible.
In these scenarios, device level assumptions fail. Disk encryption cannot be enforced. OS configuration cannot be guaranteed. Remote wipe of the device is not an option. Any security model that depends on device trust collapses immediately.
MAM removes the device itself from consideration, so access decisions are no longer based on the device being managed or compliant. Control is moved to the application and the signed in identity. Users keep ownership of their device. Organizations keep control over corporate data. The two never overlap. When access must be revoked, Mobile Application Management does not interact with the device. Corporate data is removed from the application container and access tokens are invalidated. The device remains untouched.
How Mobile Application Management works within an application
Mobile Application Management enforcement is implemented through the Intune Software Development Kit, or SDK. An SDK is a set of libraries and runtime logic embedded into an application to add specific functionality. In this case, the SDK turns a normal app into a policy enforcing container for corporate data. The SDK is part of the app itself. It runs in the app process and makes enforcement decisions locally. The operating system does not participate in these decisions and does not provide a fallback mechanism.
When a user signs in with a work identity, the SDK creates a protected container inside the app. Corporate data is encrypted and bound to that identity. Every interaction with that data is evaluated against the assigned App Protection Policy.
When a PIN is required, the SDK enforces an app scoped PIN. This PIN unlocks the encrypted container inside the app. It does not unlock the device and does not interact with device security settings. Biometrics, if allowed act only as a convenience layer on top of the app PIN.
The SDK continuously validates identity state and policy integrity during runtime. If policy can no longer be enforced or identity integrity is compromised, the SDK performs a selective wipe. Corporate data, encryption keys, and tokens are removed immediately.
Mobile Application Management execution flow
Flow on IOS
An iOS MAM enabled app is unmanaged when installed from the App Store. On first launch, the Intune SDK initializes but remains idle because no work identity exists.
When the user adds a work account, authentication is redirected to the iOS broker, Microsoft Authenticator. The broker signs the user in with Entra ID, evaluates Conditional Access, and issues access and refresh tokens. If authentication fails, the flow ends and MAM is never activated.
After successful sign in, the Intune SDK uses the access token to query the Intune MAM service for an App Protection Policy. No device object is queried and device compliance is not evaluated.
If no policy applies, the app remains personal. If a policy applies, the SDK switches the app to managed mode and creates an encrypted container bound to the signed in identity. Corporate data is stored only inside this container.
Policy requirements are enforced before data access. If configured, an app PIN unlocks the container inside the app and does not interact with iOS security.
Enforcement continues at runtime. Data sharing, clipboard use, file access, offline behavior, and session limits are evaluated locally. Identity and policy state are validated continuously.
If tokens fail to refresh, identities no longer match, or policy enforcement is no longer possible, the SDK performs a selective wipe. Corporate data, keys, and tokens are removed, the work account is deleted from the app, and the app returns to an unmanaged state.
Flow on Android
Android follows the same two phase model as iOS, but the control plane differs. Intune Company Portal is required for authentication, identity registration, and policy delivery.
A user installs an MAM enabled app from Google Play. On launch, the Intune SDK initializes but stays idle until a work account is added.
When the user signs in, authentication is redirected to Intune Company Portal. If it is not installed, installation is required before continuing. Company Portal performs identity registration for app based Conditional Access and redirects to Entra ID, where Conditional Access is evaluated. If authentication fails or requirements are not met, the flow stops and MAM is never activated.
If authentication succeeds, tokens are returned to the app. The Intune SDK then queries the Intune MAM service to determine whether an App Protection Policy applies. No device enrollment or device compliance state is evaluated.
If no policy applies, the app remains personal. If a policy applies, the SDK switches to managed mode and creates an encrypted container bound to the signed in identity. Corporate data is stored only inside this container.
Access requirements are enforced before data access. If configured, an app PIN unlocks the container inside the app only and does not interact with Android device security.
Enforcement continues at runtime. Data handling restrictions, session limits, and token health are validated locally. If identity validation fails, tokens cannot refresh, or container integrity cannot be guaranteed, the SDK performs a selective wipe. Corporate data, keys, and tokens are removed, and the app returns to an unmanaged state.
The essential remains: on Android, Company Portal is mandatory for authentication and policy delivery. Enforcement itself remains fully app scoped.
Authentication brokers in the Mobile Application Management model
Authentication brokers exist to solve an identity problem, not a data protection problem. On mobile platforms, applications are sandboxed. One app cannot securely share credentials, tokens, or authentication state with another app by itself. Brokers provide a trusted, Microsoft controlled component that handles authentication and token management on behalf of apps.
In a Mobile Application Management context, brokers sit in front of enforcement. They participate only in sign in and token lifecycle. They do not enforce App Protection Policies, do not create app containers, and do not control corporate data.
On iOS, the broker is Microsoft Authenticator. On Android, the broker role is fulfilled by Intune Company Portal. Although both are called brokers, their responsibilities are not identical.
On iOS, the broker is limited to authentication. When a user signs in to a Mobile Application Management enabled app, authentication is redirected to Microsoft Authenticator. The broker performs interactive sign in with Entra ID, evaluates Conditional Access, and returns access tokens to the app. From that point on, the broker is no longer part of the execution path. All Mobile Application Management enforcement is handled by the Intune SDK inside the app.
On Android, the broker has an additional responsibility. Intune Company Portal is required to complete the app based Conditional Access registration flow and to enable delivery of App Protection Policies to managed apps. Without Company Portal, authentication may succeed but MAM policy enforcement cannot be completed. This makes the broker part of the prerequisite chain on Android in a way that does not exist on iOS.
Despite this difference, the boundary remains clear. Brokers handle identity. They never enforce policy.
- They do not validate or store MAM PINs.
- They do not encrypt corporate app data.
- They do not trigger selective wipes.
- They do not decide whether an app is managed.
- Those actions are performed exclusively by the Intune SDK inside the application.
Operationally, this distinction matters. Missing or outdated brokers result in authentication failures, repeated sign in prompts, or Conditional Access blocks. They do not result in selective wipes or account removal after policy has already been applied. Those behaviors belong to the enforcement layer, not the authentication layer.
Understanding this separation prevents misdiagnosis. Authentication problems surface before Mobile Application Management becomes active. Enforcement problems surface after sign in, often as sudden account removal or data loss. Both feel similar to users. Technically, they live in entirely different layers.
Brokers answer one question only. Who are you. The Intune SDK answers the next one. What are you allowed to do.
Conclusion
Mobile Application Management is not device management in disguise. It is a strict, app scoped security model built around identity, policy, and local enforcement. Once you remove the device from the trust boundary, everything that happens starts to make sense.
Across these chapters, the pattern is consistent. Authentication is handled first, brokered where required by the platform. Only after a valid identity exists does Mobile Application Management come into play. From that moment on, enforcement lives entirely inside the application through the Intune SDK. Containers are created, data is encrypted, access is gated, and policy is enforced continuously. When enforcement is no longer possible, data is removed. Not negotiated. Not delayed.
iOS and Android follow the same principles, but differ in how identity and policy are brokered before the SDK takes control. Brokers answer who the user is. The SDK decides what the user can do. Mixing those layers is where most confusion starts.
If you understand this model, behaviors that are often labeled as bugs become predictable outcomes. Account removal is not random. PIN prompts are not device security. Selective wipe is not a remote action. They are all local enforcement decisions made by design.
In the next post, the focus shifts from execution to configuration. We will dive into App Protection Policies themselves. How they are evaluated, how settings interact, and how to design policies that align with the Mobile Application Management model instead of fighting it.
[…] is exactly where Mobile Application Management makes sense. Authentication through Conditional Access decides whether access is granted. The App […]