What Are Conditional Access Policies and Why Are They Important?

What Do Conditional Access Policies Actually Control?

At their core, conditional access policies sit between a sign-in attempt and the resource being requested. They don't replace a username and password, they decide what happens after those credentials are entered.

A policy might require MFA when someone signs in from an unfamiliar country. Another might block access entirely from devices that aren't compliant with company security standards. A third might allow access from a managed laptop but force a re-authentication if the same account tries to sign in from a personal phone an hour later.

This is the practical core of identity and access management. Rather than treating every sign-in the same way, conditional access policies apply different rules depending on context  which is also the foundation of zero trust security and risk-based access control.

They apply to anyone using cloud services connected to Microsoft Entra ID: employees, contractors, IT administrators, and increasingly, service accounts and AI agents that authenticate on an organisation's behalf.

Why Do Identity Attacks Keep Succeeding Without Them?

Microsoft reports that 97% of all identity-based attacks are either password spray or brute-force attacks. Microsoft Entra ID blocked roughly 7,000 password attacks per second across the past year, and identity-based attacks rose 32% in the first half of 2025 compared with the same period in 2024.

These aren't sophisticated, custom-built attacks. Most rely on stolen or reused passwords tried repeatedly against accounts that have no additional checks in place. Where conditional access policies are missing, a correct username and password is often all an attacker needs.

This is also why multi-factor authentication alone  without conditional access enforcing it consistently — leaves gaps. Phishing-resistant multi-factor authentication can stop over 99% of identity-based attacks, even when an attacker has the correct username and password. The figure only holds, though, when MFA is actually required at every relevant sign-in. Conditional access is the mechanism that makes that consistent.

What Do Regulators and Security Standards Require?

Conditional access is not just a Microsoft feature recommendation  it's now embedded in the security frameworks that organisations are increasingly expected to follow.

The U.S. National Institute of Standards and Technology (NIST), in its Zero Trust Architecture guidance (SP 800-207), defines identity-based, continuously evaluated access decisions as a core requirement of a zero trust security model. Conditional access policies are the practical implementation of that principle inside Microsoft 365 and Google Workspace environments.

Microsoft's own analysis found that more than 99% of password spray attacks use legacy authentication protocols — attacks that stop entirely once basic authentication is disabled or blocked through conditional access. Microsoft has begun rolling out managed baseline policies that block these protocols by default for organisations that haven't configured their own.

For organisations handling regulated data, auditors increasingly ask a direct question: can you demonstrate that access to email, files, and admin portals is conditional on device compliance and authentication strength, not just a password? Without conditional access policies in place, the honest answer is no.

Understanding what conditional access policies do is a useful first step. But knowing the concept exists and knowing how to configure, test, and maintain these policies inside a real Microsoft 365 or Google Workspace tenant are two different things. Our SaaS Security for Microsoft 365 and Google Workspace course walks IT and security teams through building these policies correctly  covering the configuration choices, common errors, and ongoing monitoring that a written explanation can't fully capture.

What Should Be on Every Conditional Access Checklist?

Most organisations don't lack conditional access policies entirely; they lack the right ones, configured consistently. The points below cover the gaps that show up most often.

The starting point is requiring MFA for all users, not just admins. Standard user accounts are the most common entry point for password spray attacks, and excluding them from MFA leaves the largest part of the organisation unprotected.

Closely related is blocking legacy authentication protocols. Protocols like IMAP, POP3, and SMTP can't support modern MFA prompts, which is why more than 99% of password spray attacks rely on them. Disabling legacy authentication removes this attack path almost entirely.

Access to sensitive data should also require a compliant or managed device. A policy that only allows sign-in from devices meeting compliance standards - encrypted, patched, enrolled in management — stops attackers using personal or unmanaged devices, even if they have valid credentials. This is closely tied to broader endpoint security practices.

Sign-in risk policies, powered by Identity Protection signals, add another layer. When a sign-in looks unusual, an unfamiliar location, an anonymised IP address, an impossible travel pattern — the policy should respond automatically, typically by requiring MFA or blocking the session outright.

Session controls matter too, particularly for sensitive applications. Limiting how long a session stays active, especially for admin portals and finance systems, reduces the window an attacker has if a token is stolen.

Privileged roles need stricter conditions than standard users. Global admins, security admins, and other high-privilege accounts should face shorter session lifetimes, mandatory phishing-resistant MFA, and access restricted to specific locations or devices.

Exclusions on every policy need regular review. Exclusion lists are often created temporarily for a migration, a test account, or a vendor -  and then forgotten. Each unreviewed exclusion is a gap an attacker doesn't need to work around.

Finally, policies should be tested before full enforcement using report-only mode. Microsoft Entra ID allows policies to run in a reporting mode that shows their effect without blocking anyone. Skipping this step is one of the most common causes of locked-out users and rushed rollbacks.

What Are the Warning Signs a Conditional Access Setup Isn't Working?

A few patterns tend to show up in tenants where conditional access policies exist on paper but aren't functioning as intended.

Sign-ins from countries the organisation doesn't operate in are succeeding without triggering any additional checks. This usually means a risk-based policy either isn't enabled or has an exclusion that's too broad.

Legacy protocols still appear in sign-in logs months after a "block legacy authentication" policy was supposedly applied. Often, a single app registration or service account was missed and continues to authenticate through an unsupported method.

Admin accounts can sign in from personal devices with no compliance check. This is frequently the result of an admin role being added after the original device-compliance policy was scoped, without the policy being updated to include it.

Users routinely bypass MFA prompts using "remember this device for 30 days," and that setting was configured once and never revisited. Over time, this can mean a large share of sign-ins are effectively running with MFA disabled.

Conditional access policy changes aren't logged or reviewed by anyone outside the IT team that made them. Without a second set of eyes, a policy can be quietly disabled — intentionally or by mistake — and stay that way for weeks.

Each of these is observable in Microsoft Entra's sign-in logs and policy reports. None of them require advanced tooling to spot; they require someone to look, on a schedule, with a clear sense of what "normal" should look like.

What Should Security Teams Know Versus What End Users Need to Know?

Conditional access policies affect everyone who signs in, but the responsibilities split differently depending on the role.

For security and IT teams, the work centres on configuration and ongoing review. This means defining which conditions trigger which responses, testing policies in report-only mode before enforcement, and reviewing sign-in logs and exclusion lists on a set schedule - monthly at minimum for privileged accounts. It also means keeping policies aligned as the organisation changes: new admin roles, new applications, new remote-work arrangements, and new device types all need to be reflected in existing policies, not left for the next major review.

Role-based access control (RBAC) plays a direct role here. Conditional access policies are often layered on top of RBAC; a user's role determines which resources they can request, while conditional access determines the circumstances under which that request is granted.

For end users, the experience is simpler but still requires understanding. Most will encounter conditional access as an MFA prompt, a message that their device doesn't meet compliance requirements, or a sign-in blocked from an unfamiliar location. Staff should know that these aren't errors to work around - using a personal device to "get past" a compliance block, for example, defeats the purpose of the policy and should be reported to IT rather than bypassed.

Passwordless authentication and single sign-on (SSO) are increasingly part of this picture too. As organisations move toward phishing-resistant authentication methods, security keys, certificate-based authentication, or platform credentials - the sign-in experience for end users often becomes faster, not more restrictive. Conditional access policies are what make that shift secure rather than just convenient.

If you are responsible for identity and access management in your organisation, structured security awareness training is the most reliable way to reduce risk from misconfigured or untested conditional access policies. Our SaaS Security for Microsoft 365 and Google Workspace course walks IT and security staff through real configuration scenarios — including the exclusions, legacy protocols, and session controls covered above - in a format built for busy professionals.

Frequently Asked Questions

What licence is required for conditional access policies in Microsoft Entra ID?

Conditional access policies require a Microsoft Entra ID P1 licence at minimum, which is included in Microsoft 365 E3, Business Premium, and several other bundles. Risk-based conditional access policies that respond to sign-in risk or user risk signals from Identity Protection require a P2 licence, included in Microsoft 365 E5.

Organisations on lower-tier plans without P1 can still use Microsoft's security defaults, which provide a basic, non-customisable level of identity protection including MFA for all users. However, security defaults don't allow the granular, role-specific, or device-based rules that most organisations need, which is why moving to P1 or P2 is usually a priority once conditional access becomes part of the security strategy.

Can conditional access policies lock users out of their accounts?

Yes, and this is the most common concern when organisations first configure conditional access policies. A misconfigured policy — for example, one that requires a compliant device for all sign-ins before device enrollment is complete — can block legitimate users, including administrators, from accessing their own accounts.

This is why Microsoft Entra ID includes a report-only mode, which shows exactly how a policy would affect sign-ins without enforcing it. Running every new policy in report-only mode first, reviewing the results, and keeping at least one emergency access account excluded from all policies are standard precautions that prevent this scenario.

What is the difference between conditional access and multi-factor authentication?

Multi-factor authentication is one possible outcome of a conditional access policy — but the two aren't the same thing. MFA is the additional verification step itself, such as a code from an authenticator app. Conditional access is the rule engine that decides when MFA (or another control) is required.

Without conditional access, MFA can be applied uniformly to everyone or not at all, with no ability to adjust based on risk, location, or device. Conditional access allows MFA to be required selectively — for example, only when a sign-in looks unusual — which keeps the security benefit while reducing how often low-risk users are prompted.

Do conditional access policies work the same way in Google Workspace as in Microsoft 365?

Not exactly. Conditional access, as a named feature with that level of granularity, is part of Microsoft Entra ID. Google Workspace has its own equivalent, context-aware access, which serves a similar function: restricting access based on signals like device security status, IP address, and user identity.

Organisations running both Microsoft 365 and Google Workspace need to configure these controls separately in each platform, since policies don't transfer between them. The underlying principles of device compliance, risk-based restrictions, session controls — are consistent across both, but the configuration steps and available signals differ.

How often should conditional access policies be reviewed?

There's no single regulatory mandate dictating a review frequency, but a quarterly review of all policies, combined with a monthly check of exclusion lists for privileged accounts, is a common baseline among organisations following zero trust security principles.

Reviews should cover whether exclusions are still necessary, whether new applications or roles have been added without corresponding policy updates, and whether sign-in logs show any patterns — such as legacy protocol usage or unexpected locations — that suggest a policy isn't functioning as intended. Significant organisational changes, such as mergers, new remote-work arrangements, or a shift to new device types, should trigger an off-schedule review.