Conditional Access: A Practical Guide

Conditional Access failures are almost always operational, not technical. The engine itself works reliably. The problems come from how policies are designed, rolled out, and maintained over time.

• Admin lockout: not maintaining emergency access ("break-glass") accounts excluded from Conditional Access policies. When a policy blocks all admins, nobody can fix it. Break-glass accounts should be created before any enforcement, secured with phishing-resistant Multi-Factor Authentication (MFA), and tested quarterly.
• Big-bang enforcement: flipping policies to "On" without report-only validation and staged rollout. A policy that blocks legacy auth sounds simple until you discover that a critical line-of-business app depends on it. Always run in report-only mode first.
• Too many policies: overlapping rules that are hard to reason about and harder to troubleshoot. When five policies all apply to the same user, figuring out which one actually blocked access requires careful log review. Keep policy sets clean and well-documented.
• Brittle conditions: heavy reliance on IP/location without understanding remote users, travel, and mobile carriers. A "block all non-US sign-ins" policy will lock out employees traveling internationally or using carrier-grade NAT on mobile networks.
• Legacy auth surprises: blocking legacy protocols without identifying dependencies first. Many orgs have at least one system that still uses IMAP, POP, or legacy SMTP. Find them before you block them.
• No change control: policies modified without documentation or rollback planning. Every policy change should have a reason, an owner, and a rollback path.

Conditional Access doesn't work in isolation. It sits on top of your identity foundation and adds context-aware decisions. Here's how it connects to the rest of the identity cluster:

• MFA is the first layer. Conditional Access policies often require MFA as a grant control. Without MFA enrolled and working, Conditional Access can't enforce second-factor requirements.
• Identity foundations provide the IdP infrastructure that Conditional Access runs on. Your device posture signals, user risk levels, and app registrations all depend on a well-configured identity core.
• RBAC determines who has privileged access. Conditional Access applies stricter policies to those roles (stronger MFA, compliant devices, no legacy auth). Clean role assignments make Conditional Access policies simpler.
• SSPR handles account recovery. Conditional Access policies need exceptions for recovery flows, and SSPR registration itself needs to work within your policy framework.

Each of these guides covers its topic in depth. Conditional Access is the policy layer that ties them together into adaptive access decisions.

Treat Conditional Access like code: design, test, stage, and monitor. Rushing to meet a compliance deadline usually creates more problems than it solves. A well-designed policy set protects accounts without constant lockouts and support tickets.

1. Prepare recovery: create and secure break-glass accounts; document the recovery procedure. These accounts are your safety net. They should use long, complex passwords stored offline, phishing-resistant MFA, and be excluded from all Conditional Access policies except the most basic hygiene controls.
2. Inventory apps and sign-in patterns: understand who uses what, from where, and on which devices. Look at sign-in logs for the past 30 days to identify real traffic patterns. This inventory prevents surprises when you start blocking legacy auth or requiring device compliance.
3. Start in report-only: run report-only for at least a week and validate impact in sign-in logs. Report-only mode logs what would have happened without actually blocking anything. It's the safest way to find dependencies you didn't know about.
4. Roll out baseline policies: require MFA for admins, block legacy auth, require MFA for risky sign-ins. These three policies address the most common attack vectors and are low-friction for most users.
5. Layer device posture: require compliant/managed devices for sensitive apps and data access. This is where Conditional Access gets powerful: you can say "access the finance system only from a managed, encrypted device" without blocking email from a personal phone.
6. Review and simplify: after each rollout, review the full policy set for overlap and redundancy. Consolidate where possible. Document each policy's purpose and owner.

Most organizations don't need dozens of policies. A small, well-documented set covers the majority of risk without creating an unmaintainable web of rules. Here's what a practical baseline looks like:

• MFA for all users: require MFA for every sign-in, or at minimum for all cloud app access and remote sessions. This single policy stops the majority of password-based attacks.
• MFA for admins (stronger): require phishing-resistant MFA for privileged roles. Standard push or SMS isn't enough for accounts that can modify policies, access sensitive data, or manage other users.
• Block legacy auth: disable IMAP, POP, and SMTP auth protocols that bypass modern authentication and MFA. This forces all apps through Conditional Access evaluation.
• Require MFA for risky sign-ins: use real-time risk detection to step up authentication when sign-ins look suspicious (impossible travel, unfamiliar device, anonymous IP addresses).
• Compliant device for sensitive apps: require managed, encrypted devices with current OS versions for access to high-value applications (email, file storage, admin portals, finance systems).
• Session controls for unmanaged devices: for users on personal or unmanaged devices, apply session restrictions (limited download, read-only access) rather than blocking entirely. This balances security with productivity.

The key insight: start with the policies that address the highest risk with the lowest user friction, then layer on stricter controls as your maturity grows.

Conditional Access isn't a "deploy and forget" control. Policies need ongoing attention as your environment changes: new apps, new user populations, new device types, and new threat patterns all require policy adjustments.

• Monitor sign-in logs: watch for unexpected failures, spikes in MFA prompts, and policy evaluation results. A sudden increase in blocked sign-ins often means a policy is too aggressive or a legitimate workflow was missed during testing.
• Change control: keep a simple log of policy changes and why they were made. When something breaks, you need to know what changed and when.
• Quarterly review: retire old policies, reduce overlap, and validate break-glass access. This is also the time to check whether new apps or user populations need policy adjustments.
• Evidence support: keep a short list of your enforced policy patterns (for vendor questionnaires and audits). Reviewers want to see that Conditional Access is actively enforced, not just configured.
• Test break-glass quarterly: verify that emergency access accounts work, that they can access what they need, and that the credentials are still secure and known to the right people.

Conditional Access is a feature of Microsoft Entra ID, available in Microsoft 365 E3 and E5 licensing tiers. Similar "context-aware access" capabilities exist in other identity providers (Okta, Google Workspace) under different names. The principles are the same regardless of platform: evaluate sign-in context, apply graduated controls, and maintain rollback capability.

Related: removing local admin rights and BYOD security address the device posture side of Conditional Access enforcement.