Conditional Access deployment checklist

Before you start

• 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.com domain, 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.

Checklist

1. 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.

2. 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.

3. 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.

4. 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-RequirePhishingResistantMFA makes the sign-in log far easier to read.