Microsoft Entra Conditional Access baseline policy set

A Conditional Access baseline in Microsoft Entra ID is five policies: block legacy authentication, require MFA for admin roles, require phishing-resistant MFA for admin roles, require a compliant or hybrid joined device, and challenge risky sign-ins. Create every policy in Report-only, exclude your emergency access group from all of them, check the results in sign-in logs and the What If tool, then switch each one to On. The end state is a tenant where legacy protocols cannot be used for password spraying, admins sign in with phishing-resistant MFA, and risky sign-ins get a fresh MFA challenge. For the design reasoning behind each policy, see the Conditional Access policies guide.

Before you start

Conditional Access needs Microsoft Entra ID P1 or P2, and Microsoft's deployment plan says P2 is required to use Identity Protection risk in a policy. Security defaults and Conditional Access are not meant to be combined: creating Conditional Access policies prevents you from enabling security defaults. A tenant holds at most 240 policies in any state.

Create a cloud security group, for example EmergencyAccess, holding your break-glass accounts. Microsoft recommends a dedicated group excluded from every policy that blocks or restricts sign-in. The break-glass accounts recipe covers building those accounts.

Every policy is created the same way: sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator, browse to Entra ID > Conditional Access > Policies, and select New policy.

1. Block legacy authentication

Microsoft states that more than 99 percent of password spray attacks use legacy authentication protocols (Learn). The Midnight Blizzard intrusion began with a password spray against a legacy test tenant account that had no MFA.

Users > Include: All users
Users > Exclude: Users and groups > EmergencyAccess
Target resources > Resources > Include: All resources
Conditions > Client apps > Configure: Yes
  [x] Exchange ActiveSync clients   [x] Other clients
Grant: Block access
Enable policy: Report-only

Check: Before enforcing, browse to Entra ID > Monitoring & health > Sign-in logs, add the Client App column, filter on the legacy protocols, and repeat on the User sign-ins (non-interactive) tab. Common failure: Multifunction printers and scripts using SMTP or POP break at enforcement. They show up in that filter; fix or exclude them before you flip the switch. Rollback: Set the policy back to Report-only or Off.

2. Require MFA for admin roles

Microsoft recommends at least these roles: Global Administrator, Application Administrator, Authentication Administrator, Billing Administrator, Cloud Application Administrator, Conditional Access Administrator, Exchange Administrator, Helpdesk Administrator, Password Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Security Administrator, SharePoint Administrator, and User Administrator.

Users > Include: Directory roles > (roles above)
Users > Exclude: Users and groups > EmergencyAccess
Target resources > Include: All resources
Grant: Grant access > Require multifactor authentication
Enable policy: Report-only

Check: Admin sign-ins show Report-only: Success or Report-only: User action required on the sign-in log Report-only tab. Common failure: Assuming the policy covers custom or administrative unit-scoped roles. Learn states Conditional Access is enforced for built-in roles only. Rollback: Turn the policy Off.

3. Require phishing-resistant MFA for admin roles

This is the target state; CA02 is the bridge while admins register methods. The built-in Phishing-resistant MFA strength accepts Windows Hello for Business or platform credential, FIDO2 security key, and multifactor certificate-based authentication (authentication strengths).

Users > Include: Directory roles > (same roles)
Users > Exclude: Users and groups > EmergencyAccess
Target resources > Include: All resources
Grant: Grant access > Require authentication strength > Phishing-resistant MFA strength
Enable policy: Report-only

Check: Every in-scope admin has a passkey (FIDO2) or certificate registered before you enforce. A Temporary Access Pass can bootstrap registration (Learn). Common failure: Enforcing before registration locks admins out, which Learn warns about explicitly. Also, Require multifactor authentication and Require authentication strength cannot be combined in one policy, so keep CA02 and CA03 separate. Rollback: Turn CA03 Off; CA02 still enforces MFA.

4. Require a compliant or hybrid joined device

Create an Intune compliance policy first; without one, this policy does not work as intended (Learn).

Users > Include: All users
Users > Exclude: EmergencyAccess; Directory roles > Directory Synchronization Accounts
Target resources > Include: All resources
Grant: [x] Require device to be marked as compliant
       [x] Require Microsoft Entra hybrid joined device
       For multiple controls: Require one of the selected controls
Enable policy: Report-only

The two-control grant is the one Microsoft documents for administrators; the all-users version uses compliance alone. Pick the one that matches your device estate. The control enforces device posture.

Check: Sign-ins from managed devices show Report-only: Success. Common failure: Report-only policies that require a compliant device can prompt macOS, iOS, and Android users to pick a device certificate. Microsoft suggests excluding those platforms from the report-only policy (report-only behavior). Rollback: Turn the policy Off.

5. Sign-in risk policy (Entra ID P2)

Users > Include: All users; Exclude: EmergencyAccess
Target resources > Include: All resources
Conditions > Sign-in risk > Configure: Yes > High, Medium
Grant: Grant access > Require authentication strength > Multifactor authentication
Session: Sign-in frequency > Every time
Enable policy: Report-only

Microsoft notes High and Medium is its recommendation and may differ per organization (Learn). See risk-based authentication.

Check: Risky sign-ins in the logs show this policy as Report-only: User action required. Common failure: Users not yet registered for MFA are blocked with AADSTS53004, because the policy prevents MFA registration during a risky session. Rollback: Turn the policy Off.

Create policies as code with Microsoft Graph

The create conditionalAccessPolicy API needs Policy.Read.All and Policy.ReadWrite.ConditionalAccess, plus the Security Administrator or Conditional Access Administrator role for delegated calls. The state value enabledForReportingButNotEnforced is report-only (resource type).

POST https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies
Content-type: application/json

{
  "displayName": "CA01 - All resources: Block legacy authentication - All users",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "clientAppTypes": ["exchangeActiveSync", "other"],
    "applications": { "includeApplications": ["All"] },
    "users": {
      "includeUsers": ["All"],
      "excludeGroups": ["<emergency-access-group-id>"]
    }
  },
  "grantControls": { "operator": "OR", "builtInControls": ["block"] }
}

In Microsoft Graph PowerShell, build the same body as a hashtable and pass it with New-MgIdentityConditionalAccessPolicy -BodyParameter $params.

Check: The response returns the policy id and "state": "enabledForReportingButNotEnforced". Rollback: Deleted policies can be restored within the 30-day soft-delete period.

Verify it works

1. Open Entra ID > Conditional Access > Policies > What If. Simulate an admin, the Office 365 Exchange Online app ID, Windows, and Exchange ActiveSync clients: CA01 should apply. Repeat with an EmergencyAccess member: none of the five should apply. What If evaluates only enabled and report-only policies (What If tool).
2. Leave all five in report-only for at least one week, as Microsoft's plan recommends, and review the policy impact view and the Report-only tab on real sign-ins.
3. Sign in as a test admin with only an Authenticator push. CA03 should log Report-only: User action required.
4. Enforce one policy at a time and confirm a break-glass sign-in still succeeds after each change.

Related

• Conditional Access policies guide
• Break-glass accounts in Microsoft Entra ID
• Phishing-resistant MFA and the MFA matrix
• Password spraying
• Migrate an app from AD FS to Microsoft Entra ID