DraftAbdiRashid Jama7 min read

Conditional Access baseline for small Microsoft 365 tenants

A practical set of Entra ID Conditional Access policies that small organisations can roll out safely — with break-glass accounts, report-only testing and common pitfalls.

Draft for review. This article has not been published yet and may change. It is general guidance, not advice for a specific environment — always test in report-only / non-production first.

Conditional Access is the policy engine in Microsoft Entra ID that decides under which conditions a sign-in is allowed. For a small Microsoft 365 tenant, a handful of well-designed policies closes most of the common identity attack paths — password spraying, phishing of single-factor accounts and abuse of legacy protocols. This article describes a pragmatic baseline you can roll out in an afternoon and refine over time.

Before you start

Check licensing

Conditional Access requires Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium and in E3/E5 plans. Risk-based conditions (sign-in risk and user risk) require Entra ID P2. If you do not have Entra ID P1, use Security Defaults instead — it is far better than nothing. Security Defaults and Conditional Access cannot be used at the same time, so you disable Security Defaults when you move to Conditional Access.

Create emergency access (break-glass) accounts

Create two cloud-only accounts on the *.onmicrosoft.com domain with the Global Administrator role.
Protect them with strong credentials — ideally FIDO2 security keys or passkeys stored securely, or very long random passwords kept offline.
Exclude them from every Conditional Access policy (use a dedicated group, e.g. CA-Exclude-BreakGlass).
Alert on any sign-in by these accounts, and test them on a schedule.

Agree on a naming convention

Small tenants grow. A simple pattern such as CA001-AllUsers-AllApps-RequireMFA makes policies easy to review and audit later.

The baseline policies

#	Policy	Assignments	Control
1	Require MFA for all users	All users, all resources; exclude break-glass	Grant: require MFA
2	Block legacy authentication	All users; client apps: Exchange ActiveSync and other clients	Block
3	Phishing-resistant MFA for admins	Directory roles (Global Admin, Security Admin, Exchange Admin, etc.)	Grant: authentication strength “Phishing-resistant MFA”
4	Secure security-info registration	All users; user action: register security information	Require MFA, or a trusted location / compliant device
5	Require MFA for guests	Guest and external users, all resources	Grant: require MFA
6	Require a compliant device for admins (optional, needs Intune)	Admin roles	Grant: require device marked as compliant
7	Sign-in / user risk (optional, needs P2)	All users	High sign-in risk: require MFA; high user risk: require secure password change

Policies 1–5 form the core baseline. Policies 6 and 7 are worth adding once the basics are stable and licensing allows.

A note on Microsoft-managed policies

Microsoft may create Microsoft-managed Conditional Access policies in your tenant. Review them in the Conditional Access blade so they do not overlap or conflict with your own baseline.

Roll it out safely

Start in report-only mode. Create every policy as Report-only and let it run for one to two weeks.
Review impact. Use the sign-in logs (Conditional Access / Report-only tabs) and, if you send logs to a Log Analytics workspace, the Conditional Access insights workbook.
Use the What If tool to test specific users, apps and locations before switching on.
Communicate. Tell users when MFA registration is required and how to get help.
Enable in stages — a pilot group first, then everyone.

Common pitfalls

Locking yourself out — always keep break-glass accounts excluded, and verify they work.
Too many exclusions — every excluded user or app is a gap. Review exclusion groups regularly.
Forgotten service accounts — legacy scripts or devices (scanners, line-of-business apps) using basic authentication will break when legacy auth is blocked. Find them in report-only mode first.
Country blocking as the only control — location-based blocks can be useful but are easy to bypass with VPNs. Treat them as an extra layer, not a replacement for MFA.

Next steps

Once the baseline is enforced, look at Privileged Identity Management for just-in-time admin access, move users towards passwordless / phishing-resistant methods, and connect sign-in logs to Microsoft Sentinel or Defender XDR for monitoring.