Conditional Access Best Practices: 10 Policies Every Microsoft 365 Tenant Needs

Conditional Access is the policy engine in Microsoft Entra ID that decides, at every sign-in, whether to allow access, require more proof, or block. Each policy combines who is signing in, to what, and under which conditions (device, location, risk, app) with a control such as “require MFA” or “require a compliant device”. The core best practices are: protect administrators first, require MFA for everyone, block legacy authentication, require healthy devices for corporate data, test every policy in report-only mode, and always keep two excluded emergency access accounts.

Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 E3, E5 and Business Premium. Risk-based policies require Entra ID P2 — see Entra ID P1 vs P2.

How a Conditional Access policy is built

10 baseline policies

1. Require phishing-resistant MFA for administrators — use authentication strengths for privileged roles (FIDO2 keys, Windows Hello for Business, passkeys).
2. Require MFA for all users — every user, every cloud app, with only break-glass accounts excluded.
3. Block legacy authentication — old protocols such as POP, IMAP and basic SMTP cannot perform MFA and are a favourite attack path.
4. Require MFA for Azure management — protect the Azure portal, CLI and PowerShell regardless of role.
5. Require compliant or hybrid-joined devices for access to email, SharePoint and Teams from desktops.
6. Require app protection policies on mobile — personal phones must use managed apps such as Outlook and Teams.
7. Block or challenge risky sign-ins (P2) — require MFA for medium sign-in risk and block high risk.
8. Require password change for high user risk (P2) — force secure remediation when credentials appear leaked.
9. Restrict access by location where it makes sense — block countries you never operate from, but do not rely on location alone.
10. Secure security-info registration — require trusted conditions to register MFA methods, so attackers cannot add their own.

Microsoft also deploys Microsoft-managed Conditional Access policies in many tenants. Review them rather than ignoring them — they often overlap with the baseline above.

A safe deployment process

1. Create two emergency access (break-glass) accounts, cloud-only, with strong credentials stored securely, excluded from all policies and monitored with alerts on every sign-in.
2. Use a naming convention, for example “CA01-Admins-RequirePhishResistantMFA”, so policies are easy to audit.
3. Target groups, not individuals, and keep exclusions in a documented, reviewed group.
4. Start in report-only mode and review the impact in sign-in logs and the Conditional Access insights workbook for one to two weeks.
5. Communicate before enforcing — users should already have registered MFA. Our guide to rolling out MFA without lockouts covers this.
6. Enforce in waves, starting with IT, then a pilot department, then everyone.
7. Review quarterly, including every exclusion.

Common mistakes that cause lockouts or gaps

• Enforcing a policy on “All users” without excluding break-glass accounts.
• Long-lived exclusions for executives or service accounts that are never reviewed.
• Relying on trusted IP ranges as a substitute for MFA — office networks are not a trust boundary in a Zero Trust model.
• Forgetting guests and external users, who often reach sensitive Teams and SharePoint content.
• Creating dozens of overlapping policies that nobody can reason about. Fewer, well-named policies are easier to troubleshoot.
• Leaving service accounts on passwords instead of moving them to managed identities or workload identity policies.

Troubleshooting a blocked sign-in

When a user is blocked, open the sign-in log entry in Entra ID and check the Conditional Access tab — it shows which policies applied, which were satisfied and which failed. The “What If” tool lets you simulate a sign-in for a given user, app, device and location before you change a policy.

Get your Conditional Access baseline right

M365 Enterprise Hub designs and deploys Conditional Access baselines through our Microsoft Entra ID service and identity and access management solutions, with privileged access management for admin accounts. New to the topic? Start with what IAM means in Microsoft 365, or ask us for a Conditional Access review.

Frequently Asked Questions

What licence is required for Conditional Access?

Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 E3, E5 and Business Premium. Risk-based Conditional Access policies require Entra ID P2.

What is report-only mode in Conditional Access?

Report-only mode evaluates a policy at every sign-in and logs what would have happened without enforcing it. It lets you see who would be blocked or prompted before switching the policy on.

What is a break-glass account?

A break-glass or emergency access account is a highly privileged, cloud-only account excluded from Conditional Access, used only if normal admin access is lost. Microsoft recommends at least two, with sign-in alerts.

Should I use security defaults or Conditional Access?

Security defaults provide basic MFA protection for tenants without Entra ID P1. If you have P1, Conditional Access is preferred because it gives granular control. The two cannot be used together.

How many Conditional Access policies should a tenant have?

There is no fixed number, but most organisations are well protected with roughly 10 to 20 clearly named baseline policies. Too many overlapping policies make troubleshooting difficult.

Can Conditional Access block access from specific countries?

Yes. Named locations let you block or require extra controls for sign-ins from selected countries or IP ranges. Location should complement MFA and device controls, not replace them.