Microsoft Entra Conditional Access Best Practices for Zero Trust Security

Microsoft Entra Conditional Access best practices start with understanding this: Conditional Access misconfigurations are the number one cause of self-inflicted IT outages. Not phishing. Not malware. A policy an admin built and turned on without testing it first.

One cloud architect put it simply at a recent security summit: “You can lock yourself out of your Azure tenant with Conditional Access. Ask me how I know — I’ve done it.” That is not a rare story. It happens whenever a policy is built with good intentions and turned on without a safety net.

Microsoft Entra Conditional Access is the policy engine behind Zero Trust security. It looks at signals like user identity, device health, location, and risk level, then decides whether to allow, block, or challenge access. Used well, it is one of the strongest security tools an organisation has. Used carelessly, it can shut out your entire IT team in seconds.

This guide walks through Conditional Access best practices in plain language: what a solid baseline looks like, how to roll out policies without breaking anything, how to protect your admin accounts, and the mistakes that cause the most damage.

What Is Microsoft Entra Conditional Access?

Conditional Access is Microsoft’s Zero Trust policy engine. It brings together signals about a sign-in — who the user is, what device they are using, where they are, and how risky the sign-in looks — and applies rules based on those signals.

At its simplest, a Conditional Access policy is an if-then statement. If a user tries to sign in to Microsoft 365, then they must complete multi-factor authentication (MFA). If a device is not compliant, then access is blocked. This is the core idea behind Zero Trust: never trust a sign-in by default, and check it every time instead.

A key detail many admins miss: if more than one Conditional Access policy applies to the same sign-in, the user must satisfy all of them. Passing one policy is not enough on its own. This is why a user can complete MFA and still get blocked by a separate device-compliance policy.

Why Conditional Access Matters for Zero Trust in 2026

• Identity is now the real security perimeter: With organizations running hundreds of cloud apps and supporting remote and hybrid workers, the old idea of a trusted internal network no longer applies. Identity, not network location, is what Zero Trust protects.

• Legacy risk policies are being retired: Microsoft will retire legacy Entra ID Protection risk policies on October 1, 2026. Any organisation still using the old risk-policy setup needs to migrate to Conditional Access before that date.

• Legacy MFA and SSPR policies are also being phased out: Deprecation of legacy per-user MFA and self-service password reset (SSPR) policies began on September 30, 2025, in favors of the newer Authentication Methods policy.

• Zero Trust now extends to AI agents, not just people: Microsoft’s Entra Agent ID gives AI agents their own identity, so Conditional Access can apply the same guardrails to agents that it applies to human users — blocking risky agents and enforcing least-privilege access.

• Apple’s move from Keychain to Secure Enclave affects device-based policies: A May 2026 update flagged real deployment issues for device-based Conditional Access on iOS, iPadOS, and macOS. Organizations relying on device state for Apple devices should review this before it causes silent failure

Step 1: Build a Baseline Before Anything Advanced

Most Conditional Access programs fail not because they are too simple, but because they skip the basics and jump straight to complex rules. A realistic 2026 baseline usually includes about ten core policies

• Require MFA for all users, rolled out gradually rather than all at once
• Require phishing-resistant MFA for all administrator accounts
• Block legacy authentication protocols, which do not support modern MFA
• Require a compliant or hybrid-joined device, or MFA, for standard users
• Use App Protection Policies (MAM) to secure mobile access on unmanaged devices
• Limit sign-ins from locations where your business has no legitimate reason to operate
• Reduce session exposure with sign-in frequency and persistent-browser-session controls
• Block device code flow by default, allowing it only for specific, documented, low-risk cases
• Require MFA for security information registration, to stop unauthorized method changes
• Block access for users flagged with insider risk, where Microsoft Purview is available
  

Step 2: Use a Naming Standard You Can Actually Read

• Give every policy a sequence number: This makes it easy to reference a specific policy in conversation or documentation without opening the admin centre.

• Make the name describe the policy, not just the app: A good name states who the policy targets, what it requires, and under what condition — for example, a policy requiring MFA for marketing staff accessing a CRM app from outside the office network.

• Keep policies organized as your tenant grows: Without a naming standard, Conditional Access setups become hard to audit. A structured framework keeps overlapping or duplicate policies from piling up unnoticed.

Step 3: Roll Out Every Policy in Report-Only Mode First

This is the single most important habit in this entire guide, and it is the one most often skipped under time pressure.

•  Test in report-only mode for at least a week: Report-only mode shows you what a policy would have done, without actually blocking anyone. Microsoft recommends at least one week of testing before enforcement.

• Review sign-in logs before flipping the switch: Look for legitimate users, service accounts, or applications that would be blocked. Report-only mode does not always perfectly match real behaviors, so this review step matters.

• Use a real pilot group, not just admins: Test with a representative group of actual users and a dedicated test account, not just the IT team, since admin sign-in patterns rarely reflect how the rest of the company works.

• Communicate before you enforce: Tell users what is changing, when it changes, and how to get help. A silent policy change is what turns a small hiccup into a flood of help desk tickets.

• Watch for legacy accounts that fail silently: Service accounts like Microsoft Entra Connect sync accounts can break quietly when MFA is enforced incorrectly, stopping directory sync or password resets without an obvious error.

Step 4: Protect Admin Accounts and Break-Glass Access Separately

• Require phishing-resistant MFA for every admin: SMS codes and app-based push notifications can be phished. Admin accounts should use FIDO2 security keys, Windows Hello for Business, or passkeys instead.

• Use Privileged Identity Management (PIM) for just-in-time access: Following the Zero Trust principle of least privilege, admin roles should be activated only when needed, not assigned permanently.

• Keep at least two cloud-only emergency access accounts: These break-glass accounts should use the.onmicrosoft.com domain, phishing-resistant authentication different from your other admin accounts and must be excluded from every Conditional Access policy.

• Build a disabled backup policy for emergencies: Keep a secondary, currently-disabled policy ready as a resilient fallback in case of an outage or lockout, so recovery does not depend on fixing the broken policy under pressure.

Not Sure Your Conditional Access Setup Would Survive a Real Test?

NG Cloud Security reviews Conditional Access policies against Zero Trust best practices, tests changes safely in report-only mode, and makes sure your break-glass accounts actually work when you need them

Step 5: Add Risk-Based and Device Signals the Right Way

• Move risk-based policies into Conditional Access, not Entra ID Protection alone: Legacy risk policies retire on October 1, 2026. Moving to Conditional Access also gives you report-only mode, Graph API support, and better diagnostics in the sign-in logs.

• Tune risk thresholds carefully: Setting risk levels too aggressively causes MFA fatigue, where users get so many prompts they start approving them without thinking. Balance security with a reasonable user experience.

• Pair user risk with sign-in risk: User risk flags a likely compromised identity. Sign-in risk flags a specific suspicious sign-in attempt, such as impossible travel between two distant cities within an hour. Using both together closes more gaps than either alone.

• Require device compliance for sensitive resources: Pairing Conditional Access with Intune-managed device compliance verifies not just who is signing in, but whether the device itself is healthy enough to trust.

Step 6: Control Sessions, Locations, and Legacy Protocols

• Block legacy authentication protocols entirely: Protocols like IMAP and older Exchange ActiveSync connections cannot support modern MFA and remain one of the most common ways attackers bypass it.

• Avoid blanket country blocking: Blocking every country except your own sounds strong, but it breaks down the moment employees travel, or you serve international customers. Require stronger authentication from unusual locations instead of blocking them outright, and reserve full blocks for regions where your business truly never operates.

• Set sign-in frequency and persistent session controls: Sessions that never expire are a gift to an attacker holding a stolen token. Users should not have to sign in every ten minutes, but sessions should not last indefinitely either.

• Block device code flow unless you have a documented reason not to: This flow exists for devices with limited input, like shared displays or signage, but it is also attractive to attackers. Block it by default and allow it only for specific, justified, and documented cases.

• Retire the “require approved client app” control: Microsoft is moving away from this control in favors of App Protection Policies. Review any policy still using it

Tools for Building and Testing Conditional Access Policies

• Microsoft Entra admin centre: The primary console for creating, testing, and reviewing Conditional Access policies, including the Coverage tab that shows which apps have policy coverage.

• Conditional Access templates: Pre-built policy templates for secure foundations, remote worker protection, admin protection, and agent protection, available directly in the admin centre.

• Conditional Access Optimization Agent: Built on Microsoft Security Copilot, this agent suggests new policies or changes to existing ones based on Zero Trust principles, and can apply suggestions with one click. Requires Entra ID P1 and security compute units.

• Sign-in logs: The primary source for testing report-only policies, diagnosing unexpected blocks, and confirming a rollout is behaving as expected before enforcement.

• Microsoft Graph API: Used to create and manage policies at scale, and to build automated reporting outside the admin centre.

• Named locations: Custom IP address ranges and country/region definitions used to make location-based decisions more precise than relying on default geolocation alone.

The Most Common Conditional Access Mistakes

• Turning on a new policy without testing it in report-only mode first — the single most common cause of accidental lockouts

• No break-glass accounts, or break-glass accounts that are accidentally caught by the same policies as everyone else

• Blanket country blocking that breaks the moment someone travels or a customer signs in from abroad

• Admin accounts still protected by SMS-based MFA instead of phishing-resistant methods

• Exceptions and exclusions with no expiration date and no assigned owner, quietly piling up for years

• Assuming one satisfied policy is enough, when Conditional Access actually requires every applicable policy to pass

• Ignoring the October 1, 2026 deadline to migrate legacy risk policies out of Entra ID Protection

• Leaving policies stuck in report-only mode indefinitely and never actually moving to enforcement

How NG Cloud Security Helps with Conditional Access and Zero Trust

Conditional Access looks simple until you are the one who has to test it safely, tune it for real users, and make sure it does not lock out the CEO. NG Cloud Security builds and reviews Conditional Access programs so your Zero Trust foundation is solid from day one.

•      A baseline policy set built around the ten core protections every organisation needs

•      Safe, structured rollout using report-only mode, pilot groups, and clear user communication

•      Admin and break-glass account protection that is tested, not just configured

•      Risk-based policy migration ahead of Microsoft’s legacy retirement deadlines

•      A naming and governance framework that keeps your policies auditable as your tenant grows

•      Ongoing quarterly review to catch exception sprawl before it becomes a real gap

How Often Should You Review Conditional Access Policies?

• Review policies quarterly at minimum, checking for outdated exceptions and unused rules.

• Review immediately after major changes — mergers, acquisitions, new applications, or a shift to remote work.

• Review every exception on a set schedule, and close or renew it rather than letting it run indefinitely.

• Review ahead of Microsoft’s published deprecation dates, including the October 1, 2026 legacy risk policy retirement.

Benefits of Getting Conditional Access Right

• Closes the legacy authentication gap attackers rely on most often

• Protects admin accounts with authentication that cannot be phished

• Reduces the risk of a self-inflicted outage from an untested policy change

• Extends Zero Trust protections to AI agents, not just human users

• Gives your organization a real, auditable Zero Trust foundation instead of a patchwork of one-off rules

Frequently Asked Questions

What is Microsoft Entra Conditional Access?

Conditional Access is Microsoft’s Zero Trust policy engine. It looks at signals such as user identity, device compliance, location, and sign-in risk, then decides whether to allow, block, or challenge a sign-in attempt. It works as an if-then rule: if a condition is met, then a specific access control, such as requiring MFA, is enforced.

What are the most important Conditional Access best practices for Zero Trust?

Start with a baseline of about ten core policies covering MFA, legacy authentication blocking, device compliance, and admin protection. Roll out every new policy in report-only mode before enforcing it. Protect admin accounts with phishing-resistant MFA and just-in-time access through PIM. Maintain at least two properly excluded break-glass accounts. Review policies quarterly and document every exception with an owner and an expiration date.

How do you safely roll out a new Conditional Access policy?

Create the policy in report-only mode and leave it there for at least a week. Review the sign-in logs to see who would have been blocked, using a real pilot group rather than just IT staff. Communicate the change to users before enforcing it. Only move to enforcement once the report-only logs look clean and any necessary exclusions have been added.

What baseline Conditional Access policies should every organisation have?

A realistic 2026 baseline includes requiring MFA for all users, requiring phishing-resistant MFA for admins, blocking legacy authentication, requiring compliant or hybrid-joined devices, using App Protection Policies for mobile access, limiting sign-ins from unnecessary locations, controlling session length, and blocking device code flow by default except for documented exceptions.

How do you protect admin accounts with Conditional Access?

Require phishing-resistant multi-factor authentication, such as FIDO2 security keys or Windows Hello for Business, for every administrator. Use Privileged Identity Management so admin roles are activated only when needed rather than standing permanently. Maintain at least two cloud-only emergency access accounts on the *.onmicrosoft.com domain, using different authentication than your other admins, and exclude them from every Conditional Access policy.

What is the most common Conditional Access mistake?

Turning on a new or changed policy without testing it in report-only mode first. This is the leading cause of accidental lockouts, including admins locking themselves out of their own tenant. A close second is having no properly configured break-glass account to recover with if that happens.

Does Conditional Access apply to AI agents, not just employees?

Yes. Microsoft’s Entra Agent ID gives AI agents their own identity within Entra, which lets Conditional Access apply the same Zero Trust guardrails to agents that it applies to human users — including blocking risky agents and enforcing least-privilege, just-in-time access to resources.

Final Thoughts

Conditional Access is one of the most powerful tools in a Zero Trust strategy, and one of the easiest to get wrong. The difference between a strong setup and a costly outage usually comes down to one habit: testing every policy in report-only mode before turning it on.

Organisations that build a solid baseline, protect their admin accounts properly, and review their policies on a regular schedule get real security value from Conditional Access. Organisations that skip the testing step usually find out the hard way — by locking themselves out.

Zero Trust is not a product you buy once. It is a discipline you keep practising, one tested policy at a time.

Ready to Build a Zero Trust Foundation That Actually Holds Up?

Talk to our identity security specialists about Conditional Access policy design, safe rollout, admin protection, and Zero Trust strategy tailored to your organization.