A small set of well-tested Conditional Access policies does more than dozens of complicated ones. Here is the baseline we start from, how to roll it out without locking anyone out, and what license you need.
Key Takeaways
- Conditional Access requires Entra ID P1. Risk-based policies require P2.
- Exclude two monitored emergency access accounts from your policies.
- Test every policy in report-only mode, and check the sign-in logs before you enforce it.
Before you create a policy
Check your license. Conditional Access requires Entra ID P1, included in Microsoft 365 Business Premium, E3, and E5, or available as an add-on. Risk-based conditions require Entra ID P2.
Create emergency access accounts. Keep two cloud-only accounts, excluded from your Conditional Access policies, with long random credentials stored securely. Alert on any use and test them periodically. They are what gets you back in if a policy locks out everyone else.
Decide what happens to security defaults. Security defaults and Conditional Access can’t run together, so plan the change in order to avoid a gap in MFA coverage.
A baseline policy set
For most small teams we’d start with these, each one scoped to all users unless noted, with emergency accounts excluded:
- Require MFA for all users, on all cloud apps.
- Require phishing-resistant MFA for admins, using authentication strengths.
- Block legacy authentication, which can’t perform MFA.
- Require a compliant device for sensitive access, once your laptops are enrolled in Intune.
- Restrict device code flow, a method attackers abuse, unless you have a documented need for it.
- Block or limit access from countries where you don’t operate, as a useful extra layer, though not a strong control on its own.
- Add risk-based policies for risky sign-ins and users, if you have Entra ID P2.
How to roll it out safely
- Create each policy in report-only mode.
- Review the results in sign-in logs for at least a week, and look for service accounts, shared devices, and older apps.
- Use the What If tool to test specific users and scenarios.
- Enforce on a pilot group first, then widen it in stages.
- Tell people what’s changing and who to contact before it reaches them.
Common mistakes
Excluding people and forgetting them. Every exclusion is a gap. Use a named group, document the reason, and review it regularly.
Scoping policies to selected apps. Coverage is much stronger when policies target all cloud apps, with narrow exceptions.
Writing too many overlapping policies. Use a clear naming convention and a small set you can explain to an auditor.
Stopping at MFA. Stolen session tokens can get past basic MFA, which is why device compliance and phishing-resistant methods matter. Read more in why MFA alone isn’t enough.