The App Protection article in this series ends where most MAM deployments actually begin: with a policy designed, assigned, and quietly running. This companion is about what happens after that – the version floors, the timers, the wipe mechanics, and the enforcement Microsoft now performs on your behalf whether you asked for it or not. MAM in 2026 is an operational system, not a configuration artifact, and it fails in operational ways.
The Enforcement You Don’t Control
Since January 2026, Microsoft enforces minimum Intune App SDK and wrapper versions for iOS apps and a minimum Company Portal version on Android. Apps that fall below the floor don’t degrade gracefully – users are eventually blocked from launching them. The mechanics differ by platform in a way that matters operationally. On Android, the requirement concentrates in one place: get Company Portal to 5.0.6726.0 or later and at least one Microsoft app onto the current SDK, and the rest of the managed apps sort themselves out through normal update flows. On iOS there is no such shortcut. Store apps ride autoupdate and are rarely a problem, but every line-of-business app that embeds the Intune SDK or went through the wrapping tool has to be rebuilt or re-wrapped and redistributed. That is developer time, not an update button, and if your LOB portfolio has an owner who left two years ago, this enforcement regime is how you find out.
The impact also lands unevenly, which makes it look random from the help desk queue. When a stale app actually trips depends on offline grace timers, threat defense check intervals, and how Conditional Access is configured, so two identical devices can block weeks apart. Since late June 2026, iOS apps below SDK 20.8.0 show a dismissible update warning before enforcement reaches them. Treat that warning as the canary it is: inventory what triggers it while it is still dismissible.
One overdue Company Portal update can take down every managed work app on an Android device.
Conditional Launch Is a Precedence Engine, Not a Checklist
Every time a managed app launches or resumes, the SDK evaluates conditional launch from cached policy, and the evaluation has an order: wipe takes precedence over block, block over a dismissible warning. Among the version settings, app version outranks OS version, which outranks patch version, and where two policies overlap, the more restrictive value wins. This ordering is not trivia. It explains why a user hits the wipe you forgot about instead of the warning you intended, and why the policy you see in the console is not always the policy the device is enforcing.
The version floors deserve the same discipline this series applied to ASR rules: never move a minimum straight to Block. Raise the floor with a Warn action, watch the app protection status report for a couple of weeks, then escalate. A Min OS version wired directly to Block is how a Monday morning starts with a department that can’t open Outlook because their phones are one release behind. The jailbroken and rooted device check is the exception to all this gradualism, in both directions: the SDK enforces it automatically even if you remove the setting from the policy, and immediate action is correct anyway, because a compromised operating system is not a negotiation.
Two settings carry dependencies worth designing for. The disabled account check fires when the app can no longer refresh a token, and the realistic time from disabling a user to data actually wiping is the sum of directory sync, a 120 minute access token lifetime, and a 30 minute policy check-in – hours, not seconds, and account deletions are not detected at all; only the offline timers catch those. On Android, the Play Integrity verdict and threat scan settings require Google Play Services, and a device without it is blocked outright, not skipped – which is a deliberate decision you are making about China-market hardware whether you realize it or not. Play Integrity also needs the device online for its attestation round trip, while the jailbreak and root check enforces from cached policy offline. Running both is the layered posture; neither substitutes for the other.
The Two Timers Everyone Forgets
Offline grace period is really two decisions wearing one name. The first is a block timer: a device offline past the threshold loses access to work data until it can reach the service again. The second is an offline wipe interval: a device dark long enough forfeits the corporate data entirely. Set carelessly, the first generates the “the app locked me out on the plane” ticket and the second generates the “the app deleted my email” ticket. Set deliberately, they are the backstop for everything the online checks cannot see – deleted accounts, dead devices, the phone in a drawer. The right way to choose the values is to answer one question honestly: how long am I comfortable with corporate data sitting on a device I can’t hear from?
Selective Wipe as a Runbook
Selective wipe removes the work account and its data from managed applications and touches nothing personal. It arrives two ways: as the configured action on a conditional launch failure, or admin-initiated when someone leaves. For BYOD departures it is the correct tool, and the enrollment-side retire and wipe actions covered in the lifecycle article are the wrong ones, because there is no enrollment to retire. One behavior confuses users and help desks alike: the app PIN is shared across apps from the same publisher, so wiping one Microsoft app does not clear the PIN while sibling apps remain on the device. The user who insists the app “still remembers” them after a wipe is describing designed behavior, not a failed wipe.
Wiring It to Conditional Access
MAM without Conditional Access is a suggestion. The grant that turns it into enforcement is Require app protection policy – and that grant specifically, because the older Require approved client app grant retired on June 30, 2026. Retired here means frozen, not switched off: policies carrying the old grant still enforce while they remain enabled, but the control is read-only now, closed to new policies and to edits on existing ones, and the only actions left are disable or delete. Every policy still holding it is a migration you have not done yet. The migration itself carries one caveat with teeth: not every app that satisfied the approved client app grant supports app protection policy, and an unsupported app is blocked outright when the new grant enforces, which makes report-only mode mandatory rather than prudent. Two more operational notes on the wiring. Sign-in logs will show report-only failures for app protection controls until the APP itself is enabled and delivered, so a pilot full of failures is an artifact of sequencing, not a broken design. And the policy needs the same break-glass exclusions as every other policy in the framework, because a MAM grant applied to an emergency account is exactly the kind of self-inflicted lockout the framework exists to prevent.
The design article argued that an APP users route around defeats itself. The operating version of that argument is an APP nobody watches. The floors move on Microsoft’s schedule, the timers fire on yours, and the SDK enforces either way – the only question is whether you find out from the status reports or from the ticket queue.
Intune Deployment Guide · Phase 9: Mobile and BYOD
‹ Previous: [9.5] App Protection
