🛡️ Recipe · Security & Compliance
Investigate Conditional Access Sign-In Logs and Policy Configuration
Analyze Entra ID sign-in telemetry and CA policy posture to surface failures, gaps, and policy evaluation patterns
Complexity
Intermediate
Impact
security + compliance + access-control + audit
Context
Why This Matters
Conditional Access (CA) is the primary access control plane for Microsoft 365 and Entra ID. When users report being blocked, when you suspect risky sign-ins, or during a routine security review, you need visibility into two things at once: what the sign-in logs show (who signed in, from where, which policies fired, what results) and what is actually configured (custom CA policies vs. Security Defaults).
Run this recipe when:
- Users report unexpected MFA prompts, blocks, or access denials
- You are performing a monthly/quarterly security posture review
- You suspect a compromised account (risky sign-ins, unfamiliar locations)
- You are validating that newly deployed CA policies are firing as expected
- You are auditing a tenant that relies only on Security Defaults and want to understand exposure
The output is a consolidated picture: top policies by evaluation volume, policies with the highest failure rate, failed sign-ins with error codes and locations, and the list of configured CA policies (or confirmation that only Security Defaults is active).
Expected Outcomes
After completing this recipe you will have:
- A breakdown of recent sign-ins by
conditionalAccessStatus(success, failure, notApplied) - Per-policy statistics: how often each CA policy was evaluated and its success/failure rate
- A list of failed sign-ins with error codes, failure reasons, IP addresses, and geolocation
- An inventory of configured Conditional Access policies, their state (enabled / disabled / report-only), and enforced grant controls
- Clear indication of whether the tenant is protected by custom CA policies or only Security Defaults
- Actionable recommendations for policy gaps (e.g., missing MFA-for-admins, legacy authentication not blocked)
Risks & Considerations
Warnings and gotchas
- Read-only operation. This recipe only inspects data; it does not modify policies. Still, treat sign-in data as sensitive PII — it contains usernames, IP addresses, and geolocation.
- Licensing requirement. Full sign-in log access via Graph requires Entra ID P1 or P2. Tenants on the free tier will get limited or empty results.
- Security Defaults vs. CA. When Security Defaults is enabled, sign-ins typically show
conditionalAccessStatus: notAppliedbecause Security Defaults does not use the CA evaluation engine. That is not a misconfiguration — but it is a signal that you lack granular control. - Log latency. Sign-in events can take 5–15 minutes to appear in the audit log. Recent events may be missing.
- Data retention. Sign-in logs are retained 7 days (free), 30 days (P1/P2). For longer retention, stream to Log Analytics / Sentinel.
- Do not disable Security Defaults without first creating equivalent or stronger custom CA policies — you will leave the tenant exposed.
- PII handling. Exports from this recipe should be stored in compliance with your data retention and privacy policies.
Required Permissions
| Permission | Why It's Needed |
|---|---|
| AuditLog.Read.All | Read Entra ID sign-in logs including Conditional Access evaluation details |
| Policy.Read.All | Enumerate configured Conditional Access policies and their settings |
| Directory.Read.All | Resolve user, group, and application display names referenced by policies |
The fastest way to get this done: just ask Dex. Copy the prompt below and paste it into your Dex conversation.
For IT Admins
Paste into Dex Pro
For End Users
How an employee would ask Dex for help
Walkthrough: Entra admin center
Part 1 — Review sign-in logs
- Go to Entra admin center and sign in as a Global Reader, Security Reader, or Global Administrator.
- Navigate: .
- Set the time window (default is 24h). Use Date filter to widen to 7 or 30 days as needed.
- Click Add filters and add
Conditional Access. Filter by:- Success — policies evaluated and granted access
- Failure — sign-ins blocked by CA
- Not applied — no policy matched (or Security Defaults in use)
- Click any sign-in row to open the details pane. Select the Conditional Access tab to see which policies were evaluated and their result (Success / Failure / Not applied / Report-only).
- For failed sign-ins, check the Basic info tab for the error code (e.g., 53003 = blocked by CA, 50074 = MFA required, 50158 = external security challenge).
Part 2 — Review configured CA policies
- Navigate: .
- Review the list. For each policy, check:
- State: On / Off / Report-only
- Users: who is included / excluded
- Target resources: which apps
- Conditions: locations, device platforms, client apps, risk
- Grant controls: Require MFA, compliant device, etc.
- If the list is empty, the tenant is relying on Security Defaults. Check .
Part 3 — Use the What If tool
- Navigate: .
- Enter a user, target app, and condition (IP, device state) to simulate which policies would apply. Useful for validating coverage before a user reports an issue.
Graph API approach
Combine two endpoints: /auditLogs/signIns for sign-in telemetry and /identity/conditionalAccess/policies for the policy inventory.
1. Fetch recent sign-ins with CA details
GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$top=50&$orderby=createdDateTime descFilter to the last N days and to failures only:
GET /v1.0/auditLogs/signIns?$filter=createdDateTime ge 2026-02-01T00:00:00Z and status/errorCode ne 0&$top=100Filter for sign-ins where a specific CA policy fired:
GET /v1.0/auditLogs/signIns?$filter=conditionalAccessStatus eq 'failure'&$top=100Key response fields
conditionalAccessStatus— success, failure, notApplied, unknownFutureValueappliedConditionalAccessPolicies[]— array of{ id, displayName, enforcedGrantControls, enforcedSessionControls, result }status.errorCode/status.failureReason— sign-in error detailriskLevelDuringSignIn,riskState— Identity Protection signals (P2)location,ipAddress,deviceDetail— context
2. Enumerate configured CA policies
GET https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies?$select=id,displayName,state,conditions,grantControls,sessionControlsExample response (empty means only Security Defaults or nothing):
{
"value": [
{
"id": "a1b2...",
"displayName": "Require MFA for admins",
"state": "enabled",
"grantControls": { "builtInControls": ["mfa"], "operator": "OR" }
}
]
}3. Check Security Defaults status
GET /v1.0/policies/identitySecurityDefaultsEnforcementPolicyResponse contains isEnabled: true/false.
Required permissions (delegated or application)
AuditLog.Read.AllPolicy.Read.AllDirectory.Read.All
PowerShell approach using Microsoft Graph SDK
Uses the Microsoft.Graph PowerShell module to pull sign-in logs, enumerate CA policies, and produce a consolidated report.
Prerequisites
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "AuditLog.Read.All","Policy.Read.All","Directory.Read.All"Quick: last 24h of sign-ins with CA status
$since = (Get-Date).AddDays(-1).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "createdDateTime ge $since" -Top 200 |
Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, ConditionalAccessStatus, @{n='ErrorCode';e={$_.Status.ErrorCode}}, IpAddress |
Format-Table -AutoSizeEnumerate CA policies
Get-MgIdentityConditionalAccessPolicy |
Select-Object DisplayName, State, @{n='Grants';e={$_.GrantControls.BuiltInControls -join ','}}Check Security Defaults
(Invoke-MgGraphRequest -Method GET -Uri "/v1.0/policies/identitySecurityDefaultsEnforcementPolicy").isEnabledThe downloadable script below combines all three calls, computes per-policy statistics, highlights failures, and exports a CSV report.
Next steps