Evaluate Conditional Access policies and client app conditions
Can Relecloud trust that every client app attempting to sign in is even capable of proving it deserves that extra scrutiny? You build a Conditional Access policy that requires multifactor authentication (MFA) for the engineering group on Microsoft 365 apps, and for weeks it works exactly as designed. Then the help desk flags something that shouldn't be possible: a user in that same group signs in without ever seeing an MFA prompt. No error, no bypass request, no obvious misconfiguration—just a clean sign-in that skips the control you built. Before you can fix this, you need two things: a way to reason about how several Conditional Access policies interact on a single sign-in, and a clear line between the client apps that can satisfy MFA and the ones that can't.
Combine multiple policies with AND logic
Your first assumption is that only one policy applies to this user, but that's rarely how Conditional Access works in practice. Microsoft's guidance is direct about this: "Multiple Conditional Access policies can apply to an individual user at any time. In this case, all applicable policies must be satisfied." Every policy scoped to that user, app, and condition evaluates together, and the assignments across those policies combine using AND, not OR. A sign-in doesn't succeed because it satisfies one convenient policy—it succeeds only when every applicable policy's grant control is met.
This is where "block always wins" becomes more than a rule of thumb. If any applicable policy resolves to Block access, that block overrides every other policy in play, even one that would otherwise grant access with MFA satisfied. You can't reason about a single policy in isolation and expect an accurate prediction. You have to ask what every policy scoped to this user and this sign-in requires, then check whether all of them, together, allow it through.
Separate modern clients from legacy clients
Multi-policy logic explains how policies combine, but it doesn't explain how a user skips an MFA prompt entirely. That answer sits in a condition you likely scoped without a second thought: Client apps. This condition separates modern authentication clients—browser sign-ins, mobile apps, and desktop clients—from legacy authentication clients, the older protocols exemplified by Exchange ActiveSync.
The distinction matters because the two categories don't behave the same way under a grant control. Microsoft's documentation states it plainly: "Sign-ins from legacy authentication clients don't support multifactor authentication (MFA) and don't pass device state information, so they're blocked by Conditional Access grant controls, like requiring MFA or compliant devices." A legacy client isn't challenged for MFA and then given a chance to fail it—it's blocked outright, because it has no way to complete the challenge in the first place. Your policy still applies to that sign-in; the client itself just can't satisfy the control, so Conditional Access denies it rather than negotiating with it.
| Aspect | Modern authentication clients | Legacy authentication clients |
|---|---|---|
| Examples | Browser sign-ins, mobile apps, desktop clients | Older protocols, such as Exchange ActiveSync |
| MFA and device state | Can satisfy MFA and pass device-state information | Can't—no way to complete the challenge |
| Under a grant control | Challenged, and can satisfy the control | Blocked outright by Conditional Access |
Learn more about how the Client apps condition separates modern and legacy authentication and how a policy's assignments and grant controls are evaluated together.
Find the gap a client switch can open
Here's the piece that explains Relecloud's ticket: a policy that requires MFA but is scoped only to legacy authentication clients never touches a sign-in from a modern client. If the engineering group's MFA policy was scoped that way, a user connecting through a modern mail client sails past it—not because MFA failed, but because that policy was never the one evaluating the sign-in. Switching from an older mail protocol to a modern client is enough to step outside a policy's scope entirely.
That's not the same as escaping Conditional Access altogether, and this is exactly where the AND logic from earlier comes back into play. A user who moves to a modern client still has to satisfy every other policy that applies to them—an org-wide MFA requirement, a compliant-device policy, or anything else scoped broadly enough to catch that sign-in regardless of client type. Legacy-versus-modern only changes which policies are in scope for a given sign-in; it never removes the requirement to satisfy every policy that still applies.
Synthesis prompt: A user is subject to two Conditional Access policies: one requires MFA for all client apps, and a second requires a compliant device but is scoped only to modern authentication clients. If that user signs in from an unmanaged device using a legacy authentication client, which policy or policies apply, and does the sign-in succeed? Now change one variable—the user switches to a modern authentication client on the same unmanaged device. Does the outcome change, and why?
Learn more about why legacy authentication is treated as a high-risk sign-in pattern.
Confirm the fix instead of guessing at it
Reasoning through both rules gives Relecloud's incident a plausible explanation: the engineering group's MFA policy was likely scoped to catch legacy clients, or scoped broadly enough that a client switch moved the sign-in out of range of the check the help desk expected to see. Either way, an MFA policy that looks airtight on paper can still leave a gap if you don't know precisely which client apps and which combination of policies it actually covers.
A plausible explanation isn't proof, though, and you suspect a legacy client—or a scoping gap—slipped through, but suspicion alone doesn't tell you which policy actually applied to that sign-in, or whether your fix closes the gap for good. Confirming that takes a way to inspect exactly what Conditional Access decided and why, one sign-in at a time.