Conditional Access Policies That Actually Stop Breaches

Conditional Access looks the same in every demo: sign-in risk, require MFA, block or allow. It's easy to configure something that satisfies the checklist and does almost nothing against a real attacker. The gap between "looks secure" and "holds up" is bigger than most write-ups admit.

A policy that only checks one signal, location, for example, is trivial to route around with a VPN. A policy that requires MFA but doesn't account for session persistence lets a stolen token walk right past the control it was supposed to stop. The policy still "exists." It just isn't doing the job it was built for.

Single-signal policies are the most common failure mode

The most common weak Conditional Access setup I see is one built around a single condition, most often geography or device compliance, treated as if it's sufficient on its own. Real risk-based access control has to layer signals: sign-in risk, user risk, device state, session controls, and application sensitivity, evaluated together rather than as separate on/off switches.

A policy that blocks the obvious attack and misses the realistic one isn't protecting anything, it's just generating a false sense of coverage.

What separates a policy that works from one that just exists

Enforcing MFA on the systems that actually matter

In a healthcare environment, the systems handling protected health information need Conditional Access treatment that's meaningfully stricter than general account access, not the same baseline policy applied everywhere for simplicity. That means shorter session lifetimes on sensitive applications, risk-based re-authentication instead of a one-time check, and policies that get revisited when the threat landscape shifts, not set once and left alone.

The honest version of Zero Trust isn't a slogan, it's a policy set that gets audited against real attack patterns, not just checked off against a compliance template. That's the difference between a Conditional Access policy that looks secure on paper and one that actually holds up.

// NOTE
These are general observations from day-to-day identity and access work, not employer commentary. No employer-specific or PHI-related detail is referenced here.
// Talk Shop

Working In IAM Too?

I'm always glad to trade notes with other folks building toward IAM, cloud security, or healthcare compliance, or talk to teams looking to hire in that space.

Book a Call More Field Notes

// mark@markschwinn.com