How to find sign-ins blocked by Conditional Access

Before you start

Use an account in the Global Reader, Security Reader or Security Administrator role. Reports Reader can read the logs but not which policies applied. Conditional Access, and reading the logs with Microsoft Graph, need Microsoft Entra ID P1 or P2. The PowerShell example requests AuditLog.Read.All and Policy.Read.ConditionalAccess; without the second, the policies are left out of each sign-in. Your organisation may require administrator consent.

Know what failure covers. Each sign-in's Conditional Access status is success, failure or not applied, and failure means a policy that applied to it wasn't met. Entra ID keeps sign-ins for 30 days with P1 or P2. The examples read and export; they don't change any policy.

Option 1

Find sign-ins blocked by Conditional Access with PowerShell

Install the modules once, then connect and export the sign-ins of the last 7 days that failed Conditional Access. The filter runs in Microsoft Graph, so only those sign-ins come back.

# Install once, if the modules are not already installed.
Install-Module Microsoft.Graph.Authentication, Microsoft.Graph.Reports -Scope CurrentUser

$ErrorActionPreference = 'Stop'
$days = 7
$since = (Get-Date).ToUniversalTime().AddDays(-$days).ToString('yyyy-MM-ddTHH:mm:ssZ')
Connect-MgGraph -Scopes 'AuditLog.Read.All', 'Policy.Read.ConditionalAccess' -NoWelcome
try {
    $filter = "createdDateTime ge $since and conditionalAccessStatus eq 'failure'"
    $signIns = @(Get-MgAuditLogSignIn -All -Filter $filter)
    $report = @(foreach ($signIn in $signIns) {
        $failed = @($signIn.AppliedConditionalAccessPolicies |
            Where-Object { $_.Result -eq 'failure' })
        [pscustomobject]@{
            When      = $signIn.CreatedDateTime
            User      = $signIn.UserPrincipalName
            App       = $signIn.AppDisplayName
            ErrorCode = $signIn.Status.ErrorCode
            Reason    = $signIn.Status.FailureReason
            Policies  = @($failed.DisplayName) -join '; '
            Controls  = @($failed.EnforcedGrantControls | Sort-Object -Unique) -join '; '
            ClientApp = $signIn.ClientAppUsed
            Address   = $signIn.IPAddress
        }
    })
    if ($report.Count -eq 0) {
        Write-Output "No sign-in failed Conditional Access in the last $days days."
    } else {
        $path = './conditional-access-failures.csv'
        $report | Export-Csv -Path $path -NoTypeInformation -Encoding utf8
        $blocks = @($report | Where-Object { $_.ErrorCode -eq 53003 }).Count
        Write-Output "$($report.Count) sign-ins failed Conditional Access; $blocks were blocked."
    }
} finally {
    Disconnect-MgGraph | Out-Null
}

Each row is 1 sign-in, newest first. Policies names the policies whose result was failure and Controls what they required. Error 53003 is a block; 53000, 53001 and 53002 are a device that isn't compliant, a device that isn't domain joined and an app that isn't approved. To see one person only, add and userPrincipalName eq 'person@example.com' to the filter.

Option 2

Review blocked sign-ins in the admin centre

1. Sign in to the Microsoft Entra admin centre as at least a Security Reader.
2. Go to Entra ID > Monitoring & health > Sign-in logs.
3. Select Failure from the Status menu, and search by username or application to narrow the list.
4. Select a sign-in and read the Sign-in error code: 53003 means a policy blocked it.
5. Open the Conditional Access tab for the policies that applied and the result of each. Select the ellipsis beside a policy to see why it applied, then close the details without changing anything.

This suits 1 person who can't get in right now, as the tab shows exactly which condition matched. The log lists 1 sign-in per row, so for every blocked sign-in across a week, use PowerShell or a report.

Common questions

Why is Policies empty in the CSV?

Microsoft Graph leaves the applied policies out of each sign-in unless the signed-in account holds a role that can read Conditional Access, such as Security Reader, and the session has Policy.Read.ConditionalAccess or Policy.Read.All. Reports Reader alone gets the sign-ins without them.

How can I test a policy change before the person tries again?

Use the What If tool in Conditional Access, which shows the policies that would apply to a sign-in you describe. Microsoft Graph PowerShell has Test-MgIdentityConditionalAccess for the same check. Neither signs anyone in nor changes a policy.

How do I see every policy and its settings?

Export them as they are now; see how to export Conditional Access policies. Compare the policy named on a blocked sign-in with its targets and grant controls.