Microsoft Azure — Conditional Access & MFA

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers conditional access & mfa with production-ready configurations, best practices, and hands-on examples.

Why Conditional Access and MFA Are Non-Negotiable

In modern identity security, Conditional Access (CA) and Multi-Factor Authentication (MFA) form the backbone of Zero Trust architecture. Without them, a single compromised password can lead to lateral movement and data exfiltration. Azure AD Conditional Access evaluates signals—user, device, location, app, risk—to enforce policies like requiring MFA, blocking access from untrusted networks, or limiting session duration. MFA alone is insufficient; attackers bypass it via token theft, session replay, or social engineering. CA policies add context: require MFA only when risk is high, or block legacy authentication protocols that don't support MFA. Production environments must enforce CA policies globally, with break-glass accounts excluded via named locations. The cost of not implementing CA is measured in breach response hours and regulatory fines.

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess"

# List all Conditional Access policies
$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | Select-Object Id, DisplayName, State, @{N='Conditions';E={$_.Conditions.Applications.IncludeApplications}} | Format-Table -AutoSize

Planning Your Conditional Access Policy Hierarchy

CA policies are evaluated in order of priority, but all applicable policies are enforced. Design a hierarchy: start with baseline policies (block legacy auth, require MFA for admins), then add risk-based policies (require MFA for medium+ sign-in risk), then location-based (block non-compliant countries). Use 'Report-only' mode to test policies before enabling them. Avoid overlapping conditions that cause conflicts—e.g., two policies targeting the same app with different grant controls. Use 'Exclude' sparingly; prefer 'Include' with specific groups. Production tip: create a 'CA Emergency Access' group with break-glass accounts excluded from all policies. Monitor sign-in logs for policy failures using Azure Monitor workbooks.

# Create a policy to require MFA for all users except break-glass
$params = @{
    DisplayName = "Require MFA for all users"
    State = "enabledForReportingButNotEnforced"
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
            ExcludeUsers = @("break-glass@contoso.com")
        }
        Applications = @{
            IncludeApplications = @("All")
        }
    }
    GrantControls = @{
        BuiltInControls = @("mfa")
        Operator = "OR"
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Configuring MFA Registration and Authentication Strengths

Azure AD MFA supports phone call, text, OATH tokens, Microsoft Authenticator, and FIDO2 security keys. Authentication Strength allows you to require specific methods—e.g., passwordless (FIDO2) for admins, phone for standard users. Enforce combined registration: users register MFA and SSPR in one flow. Use 'Require reauthentication every X hours' to limit session tokens. Production reality: SMS is vulnerable to SIM swapping; prefer Authenticator or FIDO2. Configure 'Number matching' in Authenticator to prevent MFA fatigue attacks. Monitor MFA registration status via the 'Registration campaign' feature to nudge unregistered users.

# Get MFA registration status for all users
Connect-MgGraph -Scopes "User.Read.All", "AuditLog.Read.All"

$users = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName, StrongAuthenticationRequirements
$users | ForEach-Object {
    $mfaStatus = if ($_.StrongAuthenticationRequirements) { "Registered" } else { "Not Registered" }
    [PSCustomObject]@{
        UserPrincipalName = $_.UserPrincipalName
        MFAStatus = $mfaStatus
    }
} | Export-Csv -Path "MFAStatus.csv" -NoTypeInformation

Implementing Risk-Based Conditional Access with Identity Protection

Azure AD Identity Protection detects sign-in risk (anonymous IP, atypical travel, leaked credentials) and user risk (compromised account). Integrate with CA to auto-remediate: require MFA for medium+ sign-in risk, block high risk. Configure risk policies in Identity Protection first, then reference them in CA. Production tip: set user risk policy to 'Block access' for high risk, but allow self-service password reset (SSPR) to reduce friction. Monitor risk detections via the Identity Protection dashboard. Real failure: a policy requiring MFA for medium risk but not blocking high risk led to a breach where attacker used a compromised session token.

# Get recent risk detections
Connect-MgGraph -Scopes "IdentityRiskEvent.Read.All"

$riskDetections = Get-MgIdentityProtectionRiskDetection -All | Where-Object {$_.RiskLevel -ne "none"}
$riskDetections | Select-Object UserDisplayName, RiskEventType, RiskLevel, DetectedDateTime | Format-Table -AutoSize

Session Controls: Limiting Token Lifetime and App Enforced Restrictions

CA session controls let you enforce sign-in frequency, persistent browser session, and app-enforced restrictions (e.g., require compliant device). Set sign-in frequency to 1 hour for high-risk apps, 24 hours for low-risk. Use 'Persistent browser session' to prevent token reuse across browser restarts. For cloud apps, use 'Use app-enforced restrictions' to let apps like SharePoint enforce download restrictions. Production insight: long token lifetimes (default 90 days) are a security risk. Shorten to 8 hours for critical apps. Monitor token issuance via Azure AD sign-in logs.

{
  "displayName": "Require reauthentication every 1 hour for Office 365",
  "conditions": {
    "applications": {
      "includeApplications": ["Office365"]
    },
    "users": {
      "includeUsers": ["All"]
    }
  },
  "grantControls": {
    "builtInControls": ["mfa"],
    "operator": "OR"
  },
  "sessionControls": {
    "signInFrequency": {
      "value": 1,
      "type": "hours"
    },
    "persistentBrowser": {
      "mode": "never"
    }
  }
}

Blocking Legacy Authentication and Deprecated Protocols

Legacy authentication protocols (POP, IMAP, SMTP, ActiveSync) don't support MFA, making them a prime vector for password spray attacks. Create a CA policy to block all legacy auth for all users. Use the 'Client apps' condition: select 'Exchange ActiveSync' and 'Other clients'. Exclude service accounts that still need legacy auth, but migrate them to Modern Auth as soon as possible. Production tip: enable 'Security defaults' for small tenants, but for enterprises, create a dedicated policy. Monitor legacy auth attempts via Azure AD sign-in logs with filter 'Client app - Legacy Authentication'. Real failure: a company blocked legacy auth but forgot to exclude their on-premises mail flow connector—email delivery broke.

# Create policy to block legacy authentication
$params = @{
    DisplayName = "Block legacy authentication"
    State = "enabled"
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
        }
        Applications = @{
            IncludeApplications = @("All")
        }
        ClientAppTypes = @("exchangeActiveSync", "other")
    }
    GrantControls = @{
        BuiltInControls = @("block")
        Operator = "OR"
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Location-Based Policies: Named Locations and Trusted IPs

Named locations in Azure AD allow you to define trusted IP ranges (corporate offices) or block countries. Use CA policies to require MFA when accessing from untrusted locations, or block access from high-risk countries. Configure named locations with IPv4/IPv6 CIDR ranges. Production tip: use 'Mark as trusted location' for corporate IPs, but don't rely solely on IP—VPNs can spoof. Combine with device compliance. Real failure: a company blocked all non-US traffic, but their remote employees used VPNs with US exit points—policy didn't apply. Use 'Country' condition instead of IP ranges for geopolitical blocking.

# Create a named location for corporate HQ
$params = @{
    DisplayName = "Corporate HQ"
    IpRanges = @(
        @{ CidrAddress = "192.168.1.0/24" },
        @{ CidrAddress = "10.0.0.0/8" }
    )
    IsTrusted = $true
}
New-MgIdentityConditionalAccessNamedLocation -BodyParameter $params

Device Compliance and Hybrid Azure AD Join Integration

CA policies can require devices to be marked as compliant (Intune) or Hybrid Azure AD joined. This ensures only managed devices access corporate resources. Configure device compliance policies in Intune (require BitLocker, antivirus, OS version). Then create a CA policy: 'Require device to be marked as compliant'. Production tip: for BYOD, use 'Require approved client app' and 'Require app protection policy' instead of device compliance. Real failure: a company required Hybrid Azure AD join for all users, but contractors had unmanaged devices—they were locked out. Use separate policies for different user groups.

{
  "displayName": "Require compliant device for Office 365",
  "conditions": {
    "applications": {
      "includeApplications": ["Office365"]
    },
    "users": {
      "includeUsers": ["All"]
    }
  },
  "grantControls": {
    "builtInControls": ["compliantDevice"],
    "operator": "OR"
  }
}

Monitoring, Reporting, and Incident Response with CA Logs

Azure AD sign-in logs contain CA policy evaluation details: which policies applied, grant controls, and session controls. Use Azure Monitor workbooks to visualize CA impact. Set up alerts for 'CA policy failure' or 'Blocked sign-in' using Log Analytics queries. Production tip: export logs to a SIEM (Sentinel) for correlation. Real failure: a misconfigured CA policy blocked all users silently—no one noticed for 2 hours because alerts weren't configured. Create a 'CA health' dashboard with KQL queries. Monitor 'What If' tool to test policies before deployment.

SigninLogs
| where TimeGenerated > ago(1d)
| where ConditionalAccessStatus == "failure"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ConditionalAccessPolicies, StatusCode
| summarize FailureCount = count() by bin(TimeGenerated, 1h), AppDisplayName
| render timechart

Testing and Rollback Strategies for CA Policies

Never deploy CA policies directly to production. Use a phased approach: 1) Report-only mode for 7 days, 2) Enable for a pilot group, 3) Gradual rollout to all users. Use the 'What If' tool to simulate policy effects. Create a rollback plan: disable the policy or move users to an exclusion group. Production tip: maintain a 'CA Emergency Access' group with no policies applied. Document each policy's purpose and expected impact. Real failure: a policy requiring MFA for all users was enabled globally, but the MFA service had an outage—all users locked out. Rollback took 10 minutes because the policy was well-documented.

# Disable a CA policy by ID
$policyId = "00000000-0000-0000-0000-000000000004"
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -State "disabled"

Advanced Scenarios: Continuous Access Evaluation and Token Protection

Continuous Access Evaluation (CAE) is a Microsoft Entra feature that revokes tokens in real time when a user's risk changes or device is marked non-compliant. Enable CAE for critical apps (Exchange, SharePoint, Teams). Token Protection (coming soon) binds tokens to the device via cryptographically bound tokens. Production tip: CAE requires app support—most Microsoft apps support it, but third-party apps may not. Test CAE with a pilot group. Real failure: without CAE, a revoked user's token remained valid for up to 1 hour. With CAE, revocation is near-instant.

# Enable CAE for a CA policy (requires Graph beta)
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$policy = Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId "00000000-0000-0000-0000-000000000002"
$policy.SessionControls.ContinuousAccessEvaluation = @{Mode = "strict"}
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -BodyParameter $policy

Putting It All Together: A Production-Ready CA and MFA Architecture

A production-ready architecture includes: 1) Baseline policies: block legacy auth, require MFA for admins, require MFA for all users (with break-glass exclusion). 2) Risk-based policies: require MFA for medium+ sign-in risk, block high user risk. 3) Location-based: block high-risk countries, require MFA for non-trusted locations. 4) Device-based: require compliant device for corporate apps. 5) Session controls: sign-in frequency 4 hours, persistent browser never. 6) CAE enabled for supported apps. 7) Monitoring: Log Analytics alerts for policy failures. 8) Rollback: documented disable scripts. Production insight: this architecture stopped a real-world attack where an attacker used a stolen token from a non-compliant device—blocked by device compliance policy.

{
  "policies": [
    {
      "name": "Block legacy auth",
      "state": "enabled",
      "conditions": {
        "clientAppTypes": ["exchangeActiveSync", "other"]
      },
      "grantControls": {
        "builtInControls": ["block"]
      }
    },
    {
      "name": "Require MFA for all users",
      "state": "enabled",
      "excludeUsers": ["break-glass@contoso.com"],
      "grantControls": {
        "builtInControls": ["mfa"]
      }
    },
    {
      "name": "Require compliant device for Office 365",
      "state": "enabled",
      "conditions": {
        "applications": {
          "includeApplications": ["Office365"]
        }
      },
      "grantControls": {
        "builtInControls": ["compliantDevice"]
      }
    }
  ]
}

Conditional Access Optimization Agent with Security Copilot

The Conditional Access Optimization Agent uses AI (Microsoft Security Copilot) to analyze your tenant's sign-in patterns and suggest new policies or changes to existing ones based on Zero Trust principles. It identifies gaps like missing MFA enforcement for high-risk apps, overly permissive exclusions, and suboptimal session control settings. With one click, you can apply the suggestion to create or update a policy. For production, use the Optimization Agent as a continuous improvement tool — review its suggestions weekly, test in report-only mode, and apply after validation. It requires Microsoft Entra ID P1 and security compute units (SCUs). The agent respects existing policies and won't suggest conflicting rules.

# Requires Microsoft Graph beta endpoint
Connect-MgGraph -Scopes 'Policy.Read.All'

$suggestions = Invoke-MgGraphRequest -Method GET `
  -Uri 'https://graph.microsoft.com/beta/identity/conditionalAccess/optimizationSuggestions'

$suggestions.value | Select-Object displayName, description, policyType, confidenceLevel | Format-Table

Custom Authentication Strengths with Advanced Options

Authentication strengths let you require specific MFA methods beyond the built-in levels. Custom strengths support advanced options: AAGUID filtering for FIDO2 security keys (e.g., require YubiKey from a specific manufacturer), certificate issuer constraints (require smart cards from your corporate CA), and policy OID binding for certificate-based authentication. For production, create custom authentication strengths for different sensitivity levels. For example, require FIDO2 with AAGUID from approved vendors for Global Administrators, but allow Authenticator app with number matching for standard users. This granularity is essential for compliance frameworks that mandate specific authentication methods.

# Create a custom authentication strength requiring specific FIDO2 key
Connect-MgGraph -Scopes 'Policy.ReadWrite.AuthenticationMethod'

$params = @{
    displayName = 'Phishing-Resistant with YubiKey'
    description = 'Requires FIDO2 from Yubico only'
    allowedCombinations = @('fido2')
    combinationConfigurations = @(
        @{
            '@odata.type' = '#microsoft.graph.fido2CombinationConfiguration'
            allowedAAGUIDs = @(
                '2fc0579f-8113-47ea-b116-555a8e1986b2',
                'b35e5a3f-8a1f-4b7d-ae8e-7b4b6f8b2c4d'
            )
        }
    )
}
New-MgIdentityAuthenticationStrengthPolicy -BodyParameter $params

Preparing for Mandatory MFA Enforcement in 2026

Microsoft is enforcing mandatory MFA for all users accessing Azure portal, Entra admin center, and Azure CLI/ PowerShell. This enforcement rolls out through mid-2026. If you already have Conditional Access policies requiring MFA, these take precedence. If not, Microsoft will enforce MFA directly. To prepare: audit users without MFA registered, ensure service principals and break-glass accounts are excluded, and test your existing CA policies against the new baseline. If you rely on security defaults, they already enforce MFA. For production, use this enforcement as a catalyst to implement risk-based CA policies that go beyond basic MFA, such as requiring phishing-resistant MFA for admins and device compliance for sensitive apps.

# Find users without MFA registered
Connect-MgGraph -Scopes 'User.Read.All', 'AuditLog.Read.All'

# Get all users and their MFA status
$users = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName, SignInActivity
$mfaMethods = Get-MgUserAuthenticationMethod -UserId $user.Id -ErrorAction SilentlyContinue

$unregistered = foreach ($user in $users) {
    $methods = Get-MgUserAuthenticationMethod -UserId $user.Id -ErrorAction SilentlyContinue
    if ($methods.Count -eq 0) {
        [PSCustomObject]@{
            UserPrincipalName = $user.UserPrincipalName
            DisplayName = $user.DisplayName
            MFARegistered = $false
        }
    }
}

$unregistered | Export-Csv -Path 'MFA-Unregistered-Users.csv' -NoTypeInformation
Write-Host "Found $($unregistered.Count) users without MFA"