Most tenants don't need fifty Conditional Access policies; they need six or seven good ones, deployed in the right order. In this post I'll walk through the baseline I recommend for a new or lightly protected Microsoft Entra tenant, how each policy maps to Microsoft's templates and Microsoft-managed policies, and the rollout sequence that keeps you from locking yourself out.
Prerequisites#
- Licensing: Conditional Access needs at least Microsoft Entra ID P1. The risk-based policies at the end need Microsoft Entra ID P2 (ID Protection).
- Role: Conditional Access Administrator is enough to create and manage policies; Reports Reader covers the sign-in logs.
- Security defaults off: security defaults and Conditional Access don't run side by side. Microsoft's guidance is to disable security defaults (Entra ID › Overview › Properties › Manage security defaults) and immediately replace them with Conditional Access, which is exactly what this baseline does.
- Two emergency access accounts: cloud-only, on the
onmicrosoft.comdomain, with a permanent (not eligible) Global Administrator assignment, protected by a passkey (FIDO2) or certificate-based authentication, stored securely and monitored. Put them in a dedicated security group so every policy can exclude the same group. - A legacy authentication inventory: in Entra ID › Monitoring & health › Sign-in logs, add the Client App column, filter on the legacy protocols and check both the interactive and non-interactive tabs. Anything that shows up (scanners, old mail clients, scripts) has to be fixed or excluded before you block.
Step 1: Check what Microsoft already created#
Open Entra ID › Conditional Access › Policies and look for policies with Microsoft in the Created by column. Microsoft-managed policies arrive in report-only mode and Microsoft turns them on no less than 30 days later unless you set them to Off. Their names include Block legacy authentication, Multifactor authentication for admins accessing Microsoft Admin portals, Multifactor authentication for all users and Multifactor authentication and reauthentication for risky sign-ins. You can't rename or delete them, but you can exclude users and change the state. Add your emergency access group to each one now and treat them as part of the baseline rather than duplicating them.
Step 2: Build the baseline#
Create each policy below in Report-only state. Every one of them includes All users (or the listed roles), excludes the emergency access group, and targets All resources unless the table says otherwise.
| Policy | Assignments and conditions | Grant / session control |
|---|---|---|
| Require MFA for administrators | Directory roles: at minimum Global, Application, Authentication, Billing, Cloud Application, Conditional Access, Exchange, Helpdesk, Password, Privileged Authentication, Privileged Role, Security, SharePoint and User Administrator | Require authentication strength: Phishing-resistant MFA once admins hold passkeys or Windows Hello for Business; otherwise Multifactor authentication |
| Require MFA for all users | All users; also exclude the Directory Synchronization Accounts role if you run Entra Connect or Cloud Sync | Require authentication strength: Multifactor authentication. Microsoft recommends no app exclusions on this one |
| Block legacy authentication | Conditions › Client apps: Exchange ActiveSync clients and Other clients only | Block access |
| Require MFA for Azure management | Target resource: Windows Azure Service Management API (covers the Azure portal, Azure PowerShell and Azure CLI) | Require multifactor authentication |
| Require a managed device for Microsoft 365 | Target resource: Office 365; start with a pilot group of users whose devices are enrolled | Require device to be marked as compliant or Require Microsoft Entra hybrid joined device (Require one of the selected controls) |
| Secure security info registration | User action: Register security information; exclude guests | Require multifactor authentication, optionally satisfied from a trusted named location, so a stolen password can't be used to add a new MFA method |
| Risk policies (P2) | Sign-in risk High and Medium; separately, user risk High | Sign-in risk: authentication strength Multifactor authentication plus sign-in frequency Every time. User risk: Require risk remediation (the strength is selected automatically and sign-in frequency Every time is mandatory) |
Watch out: Conditional Access enforces built-in directory roles only. A policy that targets roles isn't applied to custom roles or administrative-unit-scoped assignments, so give those admins MFA through the all-users policy.
Step 3: Use the templates to save time#
Go to Entra ID › Conditional Access › Create new policy from templates. The templates are grouped into Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats and AI Agents, and the Secure foundation group corresponds closely to the table above. Two behaviours matter: every template is created in report-only mode, and a template excludes only the account that created it. Open each new policy and swap that single exclusion for your emergency access group. You can also export a template's JSON and import it into another tenant with Upload policy file.
Step 4: Roll out in stages#
- Report-only for one to two weeks. In the sign-in logs, the Report-only tab of each sign-in shows what the policy would have done. The Conditional Access insights and reporting workbook aggregates the same data per policy.
- Fix what would break. Legacy clients get modern-auth replacements, scripts move to managed identities or service principals (Conditional Access user policies don't apply to service principals; use workload identity policies for those), and users who haven't registered MFA get a registration campaign or a Temporary Access Pass.
- Enable for a pilot group. Set the policy to On but include only a pilot group alongside the admins who own the rollout.
- Enable for everyone, one policy at a time. Start with block legacy authentication and MFA for admins, then MFA for all users, then the device policy, then the risk policies.
Verify#
- Sign in as a test user and open the sign-in event. On the Conditional Access tab every baseline policy should show Success or Not applied, and the Authentication details tab should show the MFA step satisfied.
- Run Entra ID › Conditional Access › Policies › What If for a guest, an admin and a legacy client to confirm the expected policies apply.
- Test one emergency access account end to end: it should sign in with its passkey and reach Entra ID › Conditional Access without an MFA prompt from your policies. Microsoft recommends repeating this at least every 90 days.
- Try a legacy protocol (for example an IMAP client) and confirm the sign-in log shows Failure with the block policy as the reason.
Tips & gotchas#
- External authentication methods and authentication strengths don't mix. If you use a third-party MFA provider as an external authentication method, use the Require multifactor authentication grant instead of a strength.
- Named locations are for narrowing, not for exempting MFA. Trusted IP ranges suit the registration policy and a block-by-country policy, but skipping MFA on the office network undermines the baseline.
- Risk policies block unregistered users. A risky sign-in from a user with no MFA methods ends with
AADSTS53004, because registration isn't allowed during a risky session. Get registration done first. - Device platform is user-agent based. Pair the platform condition with device compliance, or use it only in a block policy for unsupported platforms.
- Name policies consistently. A prefix such as
CA001-Admins-RequirePhishingResistantMFAmakes the sign-in log far easier to read.