Azure Conditional Access Policies: The Settings That Actually Matter for Security

Break-glass accounts are emergency admin accounts excluded from all Conditional Access policies. If you misconfigure a policy that blocks all admin access, break-glass accounts let you recover without a Microsoft support ticket.

# Create two break-glass accounts in the tenant
# PowerShell with Microsoft.Graph module:
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.ReadWrite.All"

$breakGlass1 = New-MgUser -DisplayName "Break Glass 01" \
  -UserPrincipalName "breakglass01@yourdomain.onmicrosoft.com" \
  -AccountEnabled $true \
  -PasswordProfile @{
    Password = (New-Guid).ToString() + (New-Guid).ToString()  # Very long random password
    ForceChangePasswordNextSignIn = $false
  } \
  -PasswordPolicies "DisablePasswordExpiration"

# Assign Global Administrator role
New-MgDirectoryRoleMemberByRef \
  -DirectoryRoleId $(Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id \
  -OdataId "https://graph.microsoft.com/v1.0/users/$($breakGlass1.Id)"

Break-glass account requirements:

• Use the .onmicrosoft.com domain (not federated: available even if federation breaks)
• No MFA registered: these accounts need to bypass MFA if MFA is broken
• Passwords stored in a physical safe, not a password manager (which may also be inaccessible during an incident)
• Monitor any sign-in to these accounts immediately: their use indicates an emergency or a breach
• Create a named location for the specific IP of the physical office safe location (optional but useful)

Create a break-glass exclusion group: Add both break-glass accounts to a group named "CA-Exclusion-Break-Glass" and exclude this group from every Conditional Access policy you create.

This is the highest-impact policy in any Entra ID tenant. Deploy it in Report-Only first.

Portal path: Entra ID > Protection > Conditional Access > New policy

Policy: Require MFA for All Users
State: Report-only (switch to On after review)

Assignments:
  Users: All users
  Exclude: CA-Exclusion-Break-Glass group
  Exclude: Directory Synchronization Accounts (service accounts for AD Connect)
  Cloud apps: All cloud apps
  Conditions: (none: apply to all sign-ins)

Access controls > Grant:
  Grant access
  Require multifactor authentication: Checked
  Require all selected controls

Session: (leave default)

PowerShell alternative:

$policyParams = @{
  DisplayName = "Require MFA for All Users"
  State = "enabledForReportingButNotEnforced"  # Report-only
  Conditions = @{
    Users = @{
      IncludeUsers = @("All")
      ExcludeGroups = @($breakGlassGroupId)
    }
    Applications = @{
      IncludeApplications = @("All")
    }
  }
  GrantControls = @{
    Operator = "OR"
    BuiltInControls = @("mfa")
  }
}
New-MgIdentityConditionalAccessPolicy @policyParams

Review report-only sign-in logs before enforcing:

Entra ID > Sign-in logs > Filter: CA policy = Require MFA for All Users > Result = Report-only: would fail

For each failure:
- Identify the user and app
- If it is a service account → add to exclusion group with justification
- If it is a legitimate user with no MFA registered → initiate MFA registration campaign
- If it is a shared mailbox → shared mailboxes should use app-only authentication, not user passwords

Legacy authentication protocols (SMTP AUTH, IMAP, POP3, older ActiveSync, older Office clients) cannot perform MFA. Attackers use credential-stuffing tools that specifically target these endpoints because even accounts with MFA can be compromised via legacy auth.

Policy: Block Legacy Authentication
State: Report-only (then On after 1-2 weeks of review)

Assignments:
  Users: All users
  Exclude: CA-Exclusion-Break-Glass
  Cloud apps: All cloud apps
  Conditions:
    Client apps:
      Exchange ActiveSync clients: Checked
      Other clients: Checked
      (Leave Browser and Mobile apps/Desktop apps unchecked: these support modern auth)

Access controls > Grant:
  Block access

Identify legacy auth usage before blocking:

# Find all sign-ins using legacy auth protocols in the last 30 days
Connect-MgGraph -Scopes "AuditLog.Read.All"
$startDate = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogSignIn -Filter "createdDateTime ge $startDate and clientAppUsed ne 'Browser' and clientAppUsed ne 'Mobile Apps and Desktop clients'" \
  -Top 200 | 
  Group-Object UserPrincipalName, ClientAppUsed | 
  Select-Object Count, Name | Sort-Object Count -Descending

Common legacy auth sources to investigate:

• Printers and MFPs sending scan-to-email via SMTP AUTH
• Legacy line-of-business applications using Exchange
• Old mobile devices using Basic Auth for Exchange
• Scripts using EWS with username/password

For each: migrate to app passwords, OAuth client credentials, or modern auth before enforcing the block.

Policy 3: Require Phishing-Resistant MFA for Admins

Admin accounts should use stronger MFA than regular users: hardware FIDO2 keys or Windows Hello for Business, not SMS or TOTP apps:

Policy: Require Phishing-Resistant MFA for Admin Roles
State: Report-only → On

Assignments:
  Users:
    Include: Directory roles:
      Global Administrator, Privileged Role Administrator,
      Security Administrator, Exchange Administrator,
      SharePoint Administrator, Compliance Administrator,
      Conditional Access Administrator, Application Administrator
  Exclude: CA-Exclusion-Break-Glass
  Cloud apps: All cloud apps

Access controls > Grant:
  Grant access
  Require authentication strength: Phishing-resistant MFA
  (Options: Windows Hello for Business, FIDO2 security keys, Certificate-based auth)

Policy 4: Require Compliant Device for Sensitive Apps

Policy: Require Compliant Device for Microsoft 365
State: Report-only → On

Assignments:
  Users: All users
  Exclude: CA-Exclusion-Break-Glass
  Cloud apps:
    Select apps: Office 365, Microsoft Azure Management
  Conditions:
    Device platforms: Windows, macOS, iOS, Android

Access controls > Grant:
  Require device to be marked as compliant (Intune) OR
  Require Hybrid Azure AD joined device
  Require one of selected controls

Policy 5: Block High-Risk Sign-Ins (Requires Entra ID P2)

Policy: Block or Require MFA for Risky Sign-Ins
State: Report-only → On

Assignments:
  Users: All users
  Exclude: CA-Exclusion-Break-Glass
  Cloud apps: All cloud apps
  Conditions:
    Sign-in risk: High (block), Medium (require MFA)
    User risk: High (require password change + MFA)

Access controls:
  For High sign-in risk: Block access
  For Medium sign-in risk: Require MFA
  For High user risk: Grant access + Require MFA + Require password change

Sign-in risk signals include:

• Anonymous IP address (Tor, known VPN exit nodes)
• Atypical travel (impossible travel: logged in from London and New York within 2 hours)
• Malware-linked IP address
• Unfamiliar sign-in properties (new device, new location)
• Leaked credentials (MSFT monitors breach databases for matching credentials)

Deployment sequence summary:

1. Create break-glass accounts and exclusion group
2. Deploy all policies in Report-Only
3. Review sign-in logs for 1-2 weeks, fix service accounts and legacy auth
4. Enable Block Legacy Auth → monitor 1 week
5. Enable Require MFA for All Users
6. Enable Admin policies
7. Enable device compliance (after Intune enrollment is complete)
8. Enable risk-based policies (if P2 licensed)