Conditional Access is the most powerful security feature in Microsoft 365 Business Premium, and the most dangerous to get wrong. It decides who can sign in, from what, and under which conditions. A good baseline stops most identity attacks. A bad one locks out the company.
This runbook covers the policies that make up a solid small-business baseline, and how they behave in cloud-only and hybrid environments.
How Conditional Access thinks
Every policy is if these conditions, then these controls:
- Assignments: which users, which apps, and conditions like location, device platform, or client app
- Grant controls: block, or require MFA, a compliant device, a hybrid-joined device, or an approved app
- Session controls: sign-in frequency, persistent browser sessions, app-enforced restrictions
All matching policies apply together. If one policy blocks, the sign-in is blocked, no matter what the others allow.
The baseline policy set
| # | Policy | Why it matters |
|---|---|---|
| 1 | Require MFA for all users | Blocks most password-spray and phishing takeovers |
| 2 | Block legacy authentication | Old protocols can't do MFA and are the favorite target of password spraying |
| 3 | Require phishing-resistant MFA for admins | Admin accounts are the keys to the tenant |
| 4 | Require MFA for Azure and admin portals | Protects management of the tenant itself |
| 5 | Require a compliant or hybrid-joined device for Microsoft 365 apps | Company data stays on company-managed devices |
| 6 | Require approved apps or app protection on mobile | Protects data on phones you don't manage |
| 7 | Block countries you never sign in from | Cheap, effective noise reduction |
| 8 | Sign-in frequency for unmanaged devices | Limits how long a stolen browser session stays useful |
Hybrid environments
If devices are domain-joined and synced to Entra ID, "hybrid Microsoft Entra joined" becomes a signal you can use:
- Policy 5 can accept either a compliant device or a hybrid-joined device. That lets existing domain PCs keep working while you move to Intune.
- Hybrid join must actually be working first. Check with the hybrid join diagnostic before relying on it in a policy.
- Accounts synced from AD follow the same policies. Your break-glass accounts should be cloud-only, so a sync or on-prem outage can't take them down.
Rollout order
- Break-glass accounts created, excluded, and monitored (how to set them up).
- Every policy in report-only mode first. Check the sign-in logs' Conditional Access tab and the Insights and reporting workbook for at least a week.
- Enable identity policies (MFA, legacy auth, admins) before device policies.
- Enable device policies last, after Intune enrollment and compliance are reliable. Otherwise you'll block every device that isn't enrolled yet.
- Use the What If tool before and after every change.
Troubleshooting a blocked sign-in
In Entra ID -> Sign-in logs, open the failed sign-in and look at the Conditional Access tab. It lists every policy that applied, whether it passed or failed, and why. The most common causes:
- Device shows as not compliant, often because the compliance state hasn't reported yet (compliance troubleshooting)
- Browser not passing the device identity: on Windows, use Edge signed in with the work profile, or add the Microsoft single sign-on extension for Chrome
- A policy scoped to "All resources" that caught something unexpected, like device registration or Intune enrollment itself