Getting started with Conditional Access: 5 must-have Entra ID policies

Prerequisites and limitations

Before rolling out CA policies in Entra ID, ensure you meet the following prerequisites and understand the scope and limits of this feature. If you’re already set up in Entra ID, skip right to our recommended policies.

Licensing requirements

• You’ll need an appropriate Entra ID (Entra ID) license. At minimum, a Premium P1 license is required to create custom Conditional Access policies; risk-based policies (Identity Protection) will require a P2 license. 
• If your organization has Microsoft 365 Business Premium, it already includes P1 features. 
• Make sure each user targeted by CA policies is licensed accordingly. (Entra ID doesn’t technically block you from applying a policy to an unlicensed user, but doing so violates terms and those users won’t get the intended protection or reporting.)
  

Appropriate admin role

Only certain admin roles can create Conditional Access policies. You should be signed in as a Global Administrator or Conditional Access Administrator in the Entra admin center. 

Plan for a privileged emergency access or “break glass” account that is excluded from all blanket policies (note that multifactor authentication is now required for all admin access, including emergency accounts). This account is only used if admins get locked out by a bad policy. Microsoft specifically recommends excluding at least one emergency admin account from CA policies to prevent accidental lockout.

Identity infrastructure

Conditional Access is a cloud-based capability of Entra ID. If you have a hybrid environment (on-prem AD synced to Entra ID), ensure Entra ID Connect is set up and that all users sign in through Entra ID. 

For risk-based policies to remediate user risk (like forcing password resets), you must enable Self-Service Password Reset (SSPR) for users and, if passwords are synced from on-premises, enable password writeback. When in doubt, always check the docs.

Microsoft will add some of these policies to new Entra ID tenants by default (you still have to go enable them), and they will also message (read: nag) you if you don’t have what they consider to be “basic level” of security policy settings enabled. Before you go whipping these up from scratch, make sure to look through the policy templates in the Entra ID CA policy builder, most of these policies can be created directly from a template or from editing a default template.

Client/app considerations 

Conditional Access kicks in after the first-factor (password) authentication is completed. It works for modern authentication methods—OAuth/OpenID Connect (OIDC), Security Assertion Markup Language (SAML), etc.—and supported client apps. 

Legacy authentication protocols (like IMAP, POP3, SMTP, and older Office clients) cannot satisfy Conditional Access requirements like multi-factor authentication (MFA), so they will simply be blocked if a CA policy is set to block or require MFA for them. 

By design, you can’t apply “allow” with conditions on legacy auth—the only real control is to block those outdated protocols (more on that in policy #1, below). Also, note that service accounts or scripts using legacy auth will fail if you blanket-block legacy protocols. Plan to modernize or exempt those if absolutely necessary (though avoid exemptions if at all possible). Entra ID’s security defaults (if enabled) already block legacy auth and require MFA for admins, so if you’re moving to custom CA policies, you’ll likely disable security defaults to avoid conflicts—but double check that your new policies provide equivalent or better protections.

Policy conflict and testing

Understand that CA policies act like if-then rules evaluated for each sign-in. Multiple policies can apply to a single login—for example, one policy might require a compliant device and another might require MFA. The user must satisfy all applicable grant controls (or if you use the “require one of the selected controls” option, at least one). Misconfigurations can lock out users (including admins), so plan carefully. 

Use “Report-only” mode for new policies initially. This logging-only mode lets you see in the sign-in logs what would have happened without actually enforcing the policy. It’s a safe way to catch unintended side effects before turning the policy on. You can also utilize the What If analysis tool in Entra ID to simulate a user/login against your policies to predict results.

Limits

Most organizations will never hit this but note that you can create up to 195 Conditional Access policies per tenant. Also, certain scenarios are out of scope for Conditional Access: It’s not designed as a first line of defense against distributed denial-of-service (DDoS) or network-layer attacks; it’s purely about access control at authentication time. 

Once a token is issued, CA won’t continuously monitor the session (though you can use session controls or Microsoft Defender for Cloud Apps integration for some real-time enforcement). We recommend enabling continuous access evaluation to inspect activities related to long running sessions. Keep in mind, CA is one piece of a zero trust strategy: Combine it with endpoint protection, continuous monitoring, and user education for phishing resistance.

1. Block legacy authentication

The problem

Legacy authentication protocols (Basic/NTLM authentication for SMTP, IMAP, POP, older Office applications, etc.) do not support MFA and are a favorite target for adversaries. Microsoft’s analysis shows that over 97 percent of credential stuffing and 99 percent of password spray attacks target legacy auth protocols. These protocols only require a username and password, making them highly susceptible to brute force and password spray attacks. In many tenants, legacy auth is the “weak link” allowing adversaries access, even if MFA is deployed for other apps.

The policy

Block all legacy authentication at the Entra ID level. This ensures that any attempt using older protocols is outright denied. Users will be forced to move to modern clients (which will then go through MFA and other controls). This one policy closes the door on a huge chunk of automated attacks.

How to implement 

In Conditional Access policy settings:

• Assignments
  • Users: Include All users (or at least all users with mailboxes or cloud access). Be sure to exclude your break-glass admin account and any service accounts that absolutely must use legacy protocols (although ideally, there should be none – if a third-party app uses IMAP, consider app-specific passwords or better, an OAuth method).
  • Resources: Include All Resources (you want to block legacy auth to any app).
• Conditions: Under Client Apps > Legacy authentication clients, check Exchange ActiveSync clients & Other clients.
• Access Control – Grant: Select Block access. Since legacy auth can’t do MFA or device compliance, blocking is the safe choice.
• Enable Policy: Set to Report-only initially. Monitor the Entra ID sign-in logs filtered for “Legacy Authentication” client app to see what would be blocked. Common legitimate things that show up might be older Office versions, older mobile email clients, or scripts. If you find service accounts or older devices still using legacy auth, you have a few options: update them to modern auth, replace them, or as a last resort, exempt them from this policy (by group or specific account). Aim to have zero exceptions if possible.
• Deploy: Switch the policy to On (enabled) once you’re confident it won’t cut off essential access. Communicate with users if you’re forcing them to update clients. Most tenants today can enforce this with minimal user impact, since Microsoft has deprecated basic auth for Exchange Online and other services already.

Real-world tip

Many organizations roll this policy out in stages; first target only Exchange Online to block basic auth, then expand to all apps. You might use Entra ID sign-in logs to identify the top offending legacy protocols in use. 

Why it matters

By blocking legacy auth, you ensure that adversaries can’t bypass MFA by using older protocols. Any sign-in must go through modern authentication, where further CA policies (like MFA or device checks) apply. This effectively shuts down an entire class of attacks overnight. This policy is so critical that Microsoft now includes it as a built-in security default and has even auto-enabled it for many tenants.

2. Require MFA for all users

The problem 

Stolen or guessed passwords are still an extremely common cause of breaches. Relying on just a password means a single phishing email or database leak can lead to account takeover. MFA is one of the most effective security measures available.

The policy 

Enforce MFA for all interactive users. Every user should register for and use MFA (at least one strong secondary factor, such as an authenticator app push, or a FIDO2 token). This policy prompts users for MFA when needed, drastically reducing the risk that a stolen password alone could be used. Even if you have a subset of users you think are “low risk,” it’s safer and easier to require MFA across the board (with few exceptions). Modern authenticator apps make it relatively seamless, and users can opt to have their device “remembered” for a period to reduce prompt frequency.

How to implement

There are a couple ways to do this but a straightforward method with Conditional Access includes:

• Assignments  
  • Users: Include All users. (Some organizations start with high-privilege or high-risk users and then expand to all – but with attacks hitting any random user via phishing, broad coverage is best.) Exclude your break-glass account from this blanket policy to prevent lockouts. You might also have to exclude certain service accounts that cannot do MFA (but if possible, convert those to “service principal” identities or use managed identities).
  • Resources: Include All Resources to enforce MFA universally. Alternatively, you can target specific critical apps (like require MFA for Office 365, Salesforce, VPN, etc.) but best practice is to cover all apps unless you have a reason not to.
• Conditions: You typically don’t need to set any condition – you want this to apply to all sign-in attempts. 
• Access Control – Grant: Select Require multi-factor authentication. This is the key setting that forces an MFA challenge. You can combine controls if needed (like “Require MFA OR device compliance”) but here we specifically want MFA every time unless other policies say otherwise.
• Session (optional): By default, the Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days, meaning users won’t be prompted for MFA every single time they sign in, only when the refresh period or risk conditions require it. If you want stricter re-auth (like for highly privileged roles), you could set a sign-in frequency control (for example, require fresh auth every 12 hours or “Every Time” for certain apps).

Why it matters

MFA is the single most significant safeguard for identity. It turns account takeover from a simple “steal password => login” event into a far more difficult challenge for adversaries. Even if credentials are compromised, the adversary is halted by the second factor. This policy, combined with blocking legacy auth, means every user login is verified by something more than a password. This should be table stakes for every identity security program.

3. Require MFA for risky sign-ins

The problem

Not all login attempts are equal – some sign-ins are inherently riskier than others. For example, a sign-in from a new country or unfamiliar location, or an impossible travel scenario (user logged in from New York an hour ago, now an attempt in Moscow), or known botnet IP addresses – these could indicate the account is being attacked or hijacked. Microsoft Entra ID’s Identity Protection analyzes each authentication in real-time and assigns a sign-in risk level (Low, Medium, High) based on detections. If we ignore these risk signals, a highly suspicious login might be treated like any normal login. We want to respond to risky logins automatically.

The policy 

Require MFA for any medium- or high-risk sign-in. This is a risk-based Conditional Access policy that layers on top of your general MFA requirement. In practice, if Identity Protection flags a sign-in as suspicious (e.g., unfamiliar location, malware-linked IP, etc.), the user must perform MFA even if they normally wouldn’t be prompted (say, if they already had a token or were in a remembered browser). This extra challenge helps ensure it’s really the legitimate user and makes life harder for an adversary using stolen credentials. This policy gives genuine users a chance to “prove” a risky login is actually theirs, without blocking them outright.

How to implement

This can be configured in two ways: via the Identity Protection > Sign-in Risk Policy blade (if you have Entra P2 licenses) or by creating a custom Conditional Access policy with the User risk or Sign-in risk condition. 

We’ll describe the custom CA approach here:

• Assignments  
  • Users: Include All users. (If you only have P2 for certain users, scope it to those groups.) Generally no need to exclude anyone except service accounts (which shouldn’t log in interactively anyway).
  • Resources: Include All Resources. You want this to trigger for any sign-in to any app, since a risky sign-in anywhere is a concern.
• Conditions – Sign-in Risk: Set Sign-in risk condition to Medium and High (the policy will apply when the real-time risk evaluated by Entra ID is medium or above). This matches Microsoft’s recommended configuration.
• Access Control – Grant: Select Require multi-factor authentication. This way, if the condition matches (risky sign-in), the user must do an MFA challenge immediately, even if they normally wouldn’t at that moment.
• Enable policy: Start in Report-only to see how often it would trigger. Identity Protection will log events for sign-in risks. Once you’re comfortable, turn it On.

Why it matters

Risk-based policies like this target attacks that can bypass basic MFA. For instance, if a user gets phished and unwittingly approves an MFA prompt (MFA fatigue attacks do happen), Entra ID might detect unusual behavior on the next login and increase the risk level. The policy can then step up security or even block the login, if needed. This adds a dynamic, adaptive element to your defenses. Compared to a blanket MFA (policy #2), this risk-driven MFA policy ensures that even “remembered” sessions or token reuses get interrupted if something seems off. Our goal, generally speaking, is to make life harder for adversaries who might somehow get a password or token.

4. Block or remediate compromised accounts

The problem

Sometimes an account itself becomes “high risk” because Microsoft has evidence the credentials have been compromised. Entra ID Identity Protection calculates a user risk level for each account, using signals like leaked credentials (found in breach databases), illicit consent grants, or multiple high-risk sign-ins. For example, if a user’s password appears in a known credential dump, that user’s user risk = High (their account is very likely compromised). We don’t want a known-compromised account to continue accessing resources freely. We need an automatic response to users with high risk to prevent breach or abuse.

The policy

Automatically protect or suspend compromised accounts. In practice, this usually means either blocking sign-in for high-risk users or forcing them to securely change their password. Microsoft Identity Protection provides a built-in User Risk Policy that can do this. The choice between block vs. password change depends on your organization’s risk tolerance. Microsoft recommends allowing the user to self-remediate by performing a secure password reset rather than outright locking them out. 

For example, require the user to do an MFA and change their password when their risk is high – this way if it’s a real compromise, the adversary is stopped and the user secures their account; if it’s a false positive, the user just changes their password and continues. In some situations, organizations may choose to block access for high-risk users and then manually investigate.

How to implement

Like the sign-in risk policy, this can be set in the Identity Protection blade if you have P2 licenses: User Risk Policy. Configuration is straightforward: “User risk level >= High” > action. 

If you choose to use a CA policy, here’s how:

• Assignments 
  • Users: Include All users (or all users with P2 licensing). Typically exclude admin break-glass accounts from this (you don’t want your only global admin to get automatically locked if flagged; those should be monitored separately).
  • Resources: Include All Resources 
• Conditions – User Risk: Set User risk = High. (We don’t recommend applying this for medium-risk, as medium might just mean one minor risk signal. “High” means multiple red flags or a confirmed leaked credential.)
• Access Control: Here you have two main options:
  • Hard-core option: Block access – Select Block. This means if an account is high risk, the user is immediately prevented from logging in to anything. This contains the threat but it can disrupt a legitimate user until admins reset their account.
  • Option B: Require password change – When a high-risk user tries to log in, Entra ID will force them through MFA (to verify identity) and then to the password reset page. They can only regain access by changing their password to a new one. This requires that SSPR is enabled for them (and password writeback if using on-prem AD).
  • Enable policy: Set it and monitor. There won’t be many hits unless accounts truly get compromised or you run Microsoft’s leaked credential reports.

Important note: For environments where the source of truth is an AD Domain Controller, also known as “hybrid-joined,” remember to enable “password writeback” so that passwords reset through Entra ID are updated at the source of truth on the DC as well. Roll back up to the prerequisites section for details!

Why it matters

Let’s say a public breach exposed an executive’s password (perhaps they reused their work password on another site that got breached). Microsoft’s detectors flag their Entra ID account as High risk due to “leaked credentials.” With this policy on, the next time that user tries to access any app, Entra ID will block them or prompt for remediation. If using the password change self-remediation, the executive will get a message that their account is at risk and will be guided to verify via MFA then set a new password. Until they do, they can’t get in. This ensures the potentially compromised password is immediately reset, cutting off any adversary who might have it. 

Another scenario: An account shows up with five high-risk sign-in events in an hour (maybe an adversary trying various methods). Identity Protection might elevate the user risk to High, meaning the account is probably under attack. The policy would then lock it down. In effect, the system is doing what a vigilant security operator would: noticing an account is likely owned by an adversary and taking it offline or forcing a credential reset. This can dramatically reduce the window of opportunity for adversaries. 

The combination of this policy with the sign-in risk policy is particularly effective: one protects against risky logins in the moment, the other against compromised identities over time. Together they can significantly reduce the chance of an adversary logging in with stolen credentials and persisting in your environment.