Four parts in, you’ve got devices enrolled (Parts 1–3) and apps deployed (Part 4)[cite: 4]. This is where everything turns into a solid security posture rather than just a collection of working settings[cite: 4] — covering compliance policy design, how to actually choose between MAM and MDM, and the Android-specific Conditional Access quirks that love to trip up Windows admins[cite: 4]. ...
Part 3 ended on a deliberately uncomfortable note: a compliance policy by itself doesn’t block anything. It grades a device and moves on. This post is the other half of that pairing — Conditional Access is the piece that actually turns “this device is noncompliant” into “this device doesn’t get in.” ...
Here’s an uncomfortable fact about compliance policies that a lot of tenants learn the hard way: a compliance policy, on its own, doesn’t block anything. It evaluates a device against a set of rules and labels it Compliant or Not Compliant — that’s it. Nothing downstream actually happens unless something else is watching that label and acting on it. Get this wrong and you can have a fully built-out compliance policy that’s pure checkbox theater, catching real problems and doing absolutely nothing about them. ...