Microsoft Entra Conditional Access Explained: MFA, Location Controls, and the What If Tool (Full Lab Guide)

8 min read

How Conditional Access Evaluates Sign‑Ins Behind the Scenes

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s cloud identity and access management (IAM) service. It handles authentication (proving who you are), authorization (what you can access), and identity governance for users, apps, and devices across Microsoft 365, Azure, and many third-party SaaS platforms.

What makes Entra ID especially powerful for modern security is Conditional Access, a policy engine that evaluates requests in real time and enforces security requirements based on conditions like user, location, device state, and risk. Microsoft positions Conditional Access as a key part of a Zero Trust approach, where access is continuously verified rather than assumed.

Why this lab matters (real-world context)

Passwords get phished. Tokens get stolen. Users sign in from coffee shops, mobile networks, and personal devices. Conditional Access helps you reduce those risks without blocking productivity, because you can require stronger controls only when the sign-in context is suspicious or outside your trusted boundaries.

If you’re building a Zero Trust Azure environment, identity controls like Conditional Access should always be combined with secure infrastructure design.
For a practical example, see Build a Secure Azure Environment in Minutes with Bicep, which shows how networking, private endpoints, and storage security work together with Entra ID.

Architecture Overview

In this lab, we’re building and validating three practical building blocks:

1. Require MFA for all users (with safe exclusions)

2. Restrict access by location (using trusted locations/regions).

3. Simulate sign-ins with the What If tool before enforcing policies (to avoid lockouts)

What’s being protected?

• Microsoft 365 apps (Exchange, SharePoint, Teams)

• Azure Portal and Azure resources

• Any enterprise app integrated with Entra ID

Prerequisites

You’ll need:

• A Microsoft Entra tenant

• An account with Global Administrator or Conditional Access Administrator permissions

• A test user (non-admin)

• At least one emergency “break-glass” admin account (more on this below)

Important safety note: Microsoft explicitly recommends maintaining emergency access accounts for tenant recovery scenarios.

Licensing note (don’t skip this)

Custom Conditional Access policies generally require Microsoft Entra ID Premium P1 (or a suite that includes it). Advanced risk-based policies typically require P2 (Identity Protection). Licensing details vary by SKU, so confirm against your tenant’s subscriptions.
If you want, tell me what licenses you have (M365 Business Premium/E3/E5, etc.), and I’ll map exactly which Conditional Access features are available.

 Video Walkthrough

• Require MFA for all users: protect every account with multi-factor authentication

• Restrict access by location: allow sign-ins only from trusted regions

• Use the What If tool: safely simulate outcomes before enforcement

Understanding Microsoft Entra Conditional Access

What Conditional Access is

Conditional Access is a policy-based access control engine in Microsoft Entra ID. It evaluates a sign-in attempt and decides whether to allow access, block it, or require additional security controls like MFA based on the conditions you define.

Instead of relying only on passwords, Conditional Access can evaluate signals such as:

• User identity

• Device platform/compliance

• Location

• Application being accessed

• Risk signals (if enabled)

Conditions vs controls (simple mental model)

Conditional Access policies are built using two key components: conditions and controls.

Conditions = “When should this policy apply?”

Examples:

• Which users/groups are signing in

• Which cloud apps are being accessed

• From which locations

• On what device platform

• Under what risk level (if using Identity Protection)

Controls = “What must be true before access is granted?”

Examples:

• Require MFA

• Require compliant device / hybrid-joined device

• Require passwordless

• Block access

In one sentence: Conditions decide when the policy triggers; controls decide what must happen next.

Why policies should be layered (defense in depth)

A single “mega-policy” is risky. Layering policies improves resilience and reduces lockout risk.

Layered policies let you:

• Apply stricter rules to admins than standard users

• Combine requirements safely (e.g., MFA + compliant device + trusted location)

• Reduce the blast radius of mistakes (one bad policy shouldn’t lock the whole tenant)

• Pilot changes gradually (report-only → pilot group → all users)

As environments grow, security controls must scale without introducing configuration drift. This becomes much easier when infrastructure is deployed consistently using Infrastructure as Code. A good next step is Deploying a Scalable Azure Environment with Bicep, which demonstrates repeatable, policy-friendly infrastructure design.

Lab setup: safety first (break-glass accounts)

Before you enforce tenant-wide policies, set up emergency access properly:

Emergency (break-glass) admin account guidance

Microsoft recommends having emergency access accounts to recover from:

• MFA outages

• Conditional Access misconfigurations

• Identity provider issues

These accounts should be tightly controlled and used only in true emergencies.

Best practice used in this lab

• Exclude your break-glass account(s) from Conditional Access policies

• Store credentials securely

• Monitor usage (alerts on sign-in events)

Key takeaway: Always exclude emergency “break-glass” admin accounts to prevent tenant lockouts.

Policy 1: Require MFA for all users (with safe exclusions)

Goal

Require multi-factor authentication for sign-ins, reducing the impact of stolen passwords.

Why MFA is non-negotiable

MFA adds a second factor (app prompt, hardware key, OTP, biometrics), making credential theft significantly less useful to attackers.

Identity controls protect who can sign in, but sensitive data still needs its own protection layer. To see how identity-aware access combines with storage security, read Securing Azure Blob Storage with PowerShell, covering network isolation, SAS tokens, and immutable policies.

Recommended approach

1. Create the policy in Report-only first

2. Test with your pilot group

3. Validate in Sign-in logs

4. Move to On when confirmed

High-level configuration

• Users: Include “All users”

• Exclude: break-glass admin account(s)

• Cloud apps: All cloud apps (or start with Microsoft 365/Azure Portal for pilot)

• Grant: Require multi-factor authentication

• Session: leave default for now (avoid complex session controls early)

Validate with logs (don’t guess, verify)

After a pilot sign-in:

• Go to Entra ID → Monitoring & health → Sign-in logs

• Open a sign-in event

• Check the Conditional Access tab to see which policies applied and why

This step is critical for troubleshooting and proving your policy does what you think it does.

Learn governance foundations first: Azure Policy, Tags, and Resource Locks Explained

Policy 2: Restrict access by location (trusted regions)

Goal

Allow sign-ins only from approved locations/regions, reducing exposure from unexpected geographies.

When to use location controls

• Your organization operates primarily in specific countries

• Admin access should be limited to known geographies

• You want to reduce brute-force attempts from high-volume threat regions

Practical guidance

Start with a targeted policy (e.g., admin group first), not “All users” on day one.

High-level configuration

• Users: start with admin group or pilot group

• Cloud apps: choose sensitive apps (Azure management, Microsoft 365, etc.)

• Conditions → Locations:

  • Include: Any location

  • Exclude: Trusted locations (your corporate regions / known egress IPs)

• Grant: Block access (for disallowed locations) or require MFA (for “step-up” model)

Tip: Location policies are powerful—but they can also create accidental lockouts during travel, VPN changes, or ISP IP shifts. That’s why simulation and report-only mode matter.

Build the network baseline behind trusted access paths: Setting Up Clean Azure VNets, Subnets & Tagging also to go deeper into network design and verification: Azure Networking with PowerShell: VNet Design, Peering, VM Provisioning & Network Watcher

The What If tool: simulate policies before enforcement

What the What If tool does

The Conditional Access What If tool simulates how your policies would evaluate a sign-in—without needing to repeatedly sign in and risk lockouts.

You can simulate sign-ins for:

• A user

• A workload identity/service principal (in supported scenarios)

It returns:

• Which policies would apply

• Which controls would be enforced

• Whether access would be allowed or blocked

How to use it in this lab (workflow)

1. Build the policy in Report-only

2. Run What If with:

   • User: test user

   • App: Microsoft Azure Management or Office 365

   • Location: a “trusted” country vs “untrusted” country

   • Device platform/client app (optional)

3. Confirm the output matches your intent

4. Only then move the policy to “On”

This is one of the safest ways to design Conditional Access in real environments.

Real-world security scenarios (how these policies help)

1) MFA enforcement for remote users

If a user signs in from home or a new device, MFA prevents simple password theft from becoming an account takeover.

2) Location-based access for admins

Admins are high-value targets. Location restrictions reduce the attack surface, especially if admin sign-ins should only occur from known regions.

3) Insider threat mitigation

Conditional Access can reduce damage from risky sign-ins by enforcing stronger controls under abnormal conditions (e.g., requiring MFA, compliant device, or blocking where appropriate). The right design depends on your environment and licensing.

Conditional Access also plays a critical role in protecting production applications during deployments. If you’re running web workloads, Azure Web App Zero-Downtime Deployment shows how identity, scaling, and deployment slots reduce risk during releases.

Operational best practices (the “don’t get locked out” checklist)

• Keep emergency access accounts and exclude them from CA policies

• Use Report-only mode for new policies and analyze impact before enforcing

• Validate outcomes in Sign-in logs → Conditional Access tab

• Use the What If tool to simulate uncommon scenarios safely

• Roll out changes in layers: pilot → phased rollout → tenant-wide

Standardized environments make Conditional Access easier to reason about and troubleshoot. One effective approach is using golden images to ensure consistent OS baselines. See Building Golden Images with Azure Compute Gallery for a hands-on lab.

Conclusion (what you should do next)

If you’re serious about Zero Trust, Conditional Access is one of the highest-impact controls you can deploy quickly.

Start simple:

1. MFA for users (pilot first)

2. Location controls for admins

3. Validate everything with What If + sign-in logs

4. Gradually layer in stronger controls as your environment matures

Finally, Conditional Access works best when infrastructure and identity changes are deployed in a controlled, automated way. If you want to remove manual portal drift entirely, Automating Azure Infrastructure with Bicep walks through a clean IaC-driven workflow using VS Code.