ALL THINGS IDENTITYEntra ID · Conditional Access
Andrew Chanthaphone · July 2026 · All Things IAMI've audited a lot of Entra ID tenants, and almost every one has at least one of these five Conditional Access mistakes. A couple of them will lock you out of your own tenant. One of them quietly leaves a door open that MFA doesn't even cover.
Quick framing before we start. Conditional Access is the heart of Entra ID security — it's the "if this, then require that" engine for every sign-in. The problem isn't that people don't use it. It's that they configure it the way the demo shows, not the way a real org needs. These five are the ones I see over and over. Number three is in almost every tenant I touch.
Let's go through all five — what people do, why it breaks, and how to fix it.
This is the one that bites hardest. Someone creates a "require MFA for all users" policy, scopes it to everyone, and flips it straight to On.
Here's why that breaks: the policy applies to you too. Lose your phone, hit an MFA outage, misconfigure a grant control — and now no admin can get in. People lock themselves out of their own tenant. It happens.
The fix is two things:
Neither step takes long. Skipping both is how you end up on the phone with Microsoft support asking to be let back into your own directory.
This is the silent one. Teams set up MFA, feel covered, and never touch legacy auth.
The problem: legacy protocols — older Office clients, IMAP, POP, SMTP basic auth — can't do modern MFA. That's not a configuration gap you can tune your way out of; the protocols themselves don't support it. And attackers know this, which is why they target exactly those endpoints to bypass MFA entirely. You can have a perfect MFA policy and still get password-sprayed through legacy auth. Your strongest control simply doesn't apply to those sign-ins.
The fix: block legacy authentication with a Conditional Access policy. Condition on the legacy auth clients, set the grant control to Block. But do it in the right order — check your sign-in logs filtered to legacy auth first, so you don't break a service account that's still quietly using an old protocol. Then enforce it.
One caveat: Microsoft has been retiring basic auth, but verify it's actually blocked in your tenant. Don't assume.
This is the one that's almost everywhere: treating "trusted locations" as security.
The pattern looks reasonable on paper. Mark the office IP range as a named/trusted location and skip MFA from there — "we're on the corporate network, we're fine."
But IP is not identity. VPNs, a compromised box sitting on that network, or a spoofed range — and the "trusted" bypass becomes the attacker's easiest path into your tenant. The exception you carved out for convenience is now their front door.
Location is a useful signal, not a control you grant trust on. That distinction is the whole fix:
This is the demo-configuration problem in its purest form. The trusted-locations carve-out feels like a sensible convenience when you set it up. It reads very differently in an incident report. If you fix only one thing after reading this, fix this one.
Same level of protection for the intern and the Global Admin. A single "require MFA" policy covers all users equally, and nobody ever revisits it.
Why it breaks: privileged accounts are the prize. An attacker who lands a regular user account has a foothold; an attacker who lands a Global Admin has your tenant. And standard MFA can still be phished with real-time proxy attacks — it raises the bar, but it doesn't put privileged accounts out of reach. Your admins need stronger controls than your general users, and most tenants don't separate them at all.
The fix: build a separate, stricter policy targeting directory roles — Global Admin and the other privileged roles. For that policy, require phishing-resistant MFA. In the portal this lives under authentication strengths, so verify the exact option name in your tenant — Microsoft moved it under Authentication strengths, and they rename things often.
This is also where PIM comes into the picture. But at minimum: your admins should not be on the same policy as everyone else. If your Global Admins and your general users face identical sign-in requirements, that's the gap an attacker will use.
You think you're covered. You're not.
Two versions of this mistake. First: scoping a policy to a couple of named apps and calling it done. Second: excluding so much — this app, that group, this location — that real sign-ins slip through unprotected.
Either way, the result is the same. Users authenticate to apps your policy never targets, or the stack of exclusions adds up to a wide-open lane. Coverage you assume but never verified is the same as no coverage.
The fix has two halves:
Notice what these five have in common. It's not that the settings are hard to find — every one of these fixes is a few clicks in the Entra admin center. The gap is knowing why each one matters and how they fit together into a tenant-wide policy structure.
Anyone can click into Conditional Access. Designing it so it actually holds — break-glass accounts underneath, legacy auth blocked, location used as a signal instead of a bypass, admins on stricter controls, coverage verified instead of assumed — that's the skill.
So here's your homework: go check your own tenant for these five. Fix number three first.
This is exactly Module 3 territory of my Entra ID Mastery course — Conditional Access designed the way a real org needs it, with the labs to build it yourself. If you want the full framework instead of five isolated fixes, that's where it lives: Entra ID Mastery.