Building Resilience - A Practical Zero-Trust Baseline in Entra ID Conditional Access

Zero trust sounds great in a slide deck. In a real tenant, it usually comes down to a handful of decisions that either tighten things up properly or leave gaps you only discover later.

I’ve seen environments with dozens of Conditional Access policies that nobody can confidently explain. I’ve also seen tenants with almost nothing enforced because “it might break something.” Neither approach is sustainable.

A good baseline isn’t complicated. It’s clear. It’s consistent. And it reflects how attackers actually operate.

Block Legacy Authentication

If legacy authentication is still enabled, that’s the first thing to deal with.

Protocols that don’t support modern authentication can bypass MFA and most Conditional Access controls. Leaving them enabled because one old system still depends on them is a risk decision, whether it’s acknowledged or not. In most modern environments, legacy authentication should simply be blocked across the board. If something breaks, that tells you exactly where your technical debt is sitting.

Make MFA Non-Negotiable

MFA shouldn’t depend on whether someone is inside the office network. It shouldn’t only apply to admins. And it definitely shouldn’t be optional.

If users can sign into cloud services with just a password, you’re depending on something that gets phished every day. A baseline Conditional Access policy should require MFA for all users across all cloud applications, with tightly controlled emergency accounts carved out for recovery scenarios.

This isn’t about adding friction for the sake of it. It’s about removing an obvious weakness.

Treat Admin Accounts Like Admin Accounts

One of the most common design mistakes is protecting administrators the same way you protect everyone else.

Administrative roles are different. If a standard user account is compromised, you’re dealing with contained damage. If a Global Administrator is compromised, you’re dealing with someone who can change policy, create accounts, and potentially lock you out.

That difference should show up in your Conditional Access design.

Privileged roles should have their own policy. Stronger authentication methods. No legacy authentication. Tighter device requirements where it makes sense. If you’re not separating admin controls from user controls, you’re flattening risk in a way that doesn’t reflect reality.

Use Device Compliance With Intent

Device compliance is useful, but it’s not something you apply blindly to everything.

Requiring compliant devices for high-impact systems — admin portals, finance platforms, security tools — makes sense. Requiring it for every low-risk SaaS application might just generate noise and support tickets.

The point isn’t to trust devices completely. It’s to avoid trusting credentials alone. When credentials get stolen, device controls often become the second line of defence.

Turn On Risk-Based Policies and Actually Pay Attention

Entra ID gives you sign-in risk and user risk signals. Many tenants enable them and never look at them again.

If you’re going to build a proper baseline, use those signals properly. Require stronger authentication for elevated sign-in risk. Force password resets when user risk is high. Then review what’s being triggered.

If you never check how your policies behave, you’re assuming they work the way you think they do. Assumptions are usually where things go wrong.

Keep the Structure Simple

You don’t need fifteen overlapping policies with clever conditional logic. That just makes troubleshooting painful.

A solid structure usually boils down to a small number of clearly defined policies:

• Block legacy authentication

• Require MFA for all users

• Enforce stronger controls for privileged roles

• Apply device requirements to high-impact applications

• Use risk-based enforcement

Each one should have a clear purpose. If something fails, you should immediately understand which layer is responsible. When policies start filling up with exclusions and edge cases, that’s often a sign the underlying design needs rethinking.

Don’t Let Emergency Access Undermine Everything

Break-glass accounts are necessary. They shouldn’t quietly weaken your entire baseline.

Keep at least two. Protect them properly. Exclude them only where absolutely required. Monitor every sign-in. If an emergency account is used unexpectedly, that’s not routine activity. That’s something you investigate.

A Baseline Is About Removing Obvious Weaknesses

At its core, a zero-trust baseline in Entra ID Conditional Access is about getting rid of the easy wins for an attacker. Password-only access. Legacy protocols. Under-protected admin roles. Ignored risk signals.

Once those are gone, you’re not relying on best-case scenarios anymore. You’re operating with stronger defaults. From there, you can start thinking about how the design holds up under pressure. That’s where resilience comes in.

Next topic: Building Resilience - Blocking Legacy Authentication