Entra ID Conditional Access: tenant lockout, break-glass accounts and how to test policy safely

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Tenant lockout usually starts with an enforced policy that reaches every user and every resource, and has no tested exclusion. The defence has three parts: at least two cloud-only emergency access accounts that use a passkey or certificate, those accounts excluded from policies that block or restrict sign-in, and a fixed path from report-only through What If and a pilot group to enforcement.

An exclusion from Conditional Access no longer gives an account a password-only route into the admin portals. Mandatory multifactor authentication (MFA) applies to emergency accounts too, so password-only break-glass designs need rebuilding.

The commands and queries below come from Microsoft's published references, except where marked as written for this article. They were not run in a lab for this article.

Why it matters

Conditional Access is Microsoft Entra ID's policy engine for sign-in. Each policy says: if this identity reaches this resource under these conditions, then apply these controls. It needs Microsoft Entra ID P1, P2 or a trial licence.

A mistake here does not break one server. It can stop the people who would fix it from reaching the admin centre. Microsoft's troubleshooting page gives two ways back: another administrator who is not yet blocked, or a support request. Support reviews the case and, after confirming it, updates the policies that prevent access. An emergency account is how you avoid depending on that queue.

How evaluation produces a lockout

Three rules explain most surprises. The second comes from Microsoft's policy structure page and the third from its users and groups page.

• Every configured condition must match. Microsoft's report-only results class a policy as not applied when not all its configured conditions were satisfied.
• Every applicable policy must be satisfied. If one requires MFA and another requires a compliant device, the user needs both. A block control ends enforcement at once.
• Exclude beats include. A user who is both included and excluded is excluded from that policy.

The third rule works per policy. Excluding someone from one MFA policy does nothing about a second policy that also reaches them. Microsoft's deployment plan tells you to test exactly this, because other policies can still require MFA for an excluded user.

The resource side has its own traps. The service dependencies page explains that a policy on one service can affect an app that calls it. Enforcement is early-bound (before the calling app can be used) or late-bound (when the app requests a token for the downstream service). In the troubleshooting example, the application is the Azure portal but the resource is Azure Resource Manager.

A related change is live. For policies that target All resources and have a resource exclusion, enforcement of baseline scopes began rolling out on 15 June 2026. Sign-ins asking only for scopes such as openid, profile or User.Read were previously skipped and can now be challenged. Microsoft's examples are the Visual Studio Code desktop client and Azure CLI. This query from that page lists the policies concerned:

https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies?$filter=conditions/applications/includeApplications/any(a:a eq 'All') and conditions/applications/excludeApplications/any()&$select=id,displayName

Configurations that lock people out

The admin centre shows a warning when a policy is applied to all users and all apps, and offers to exclude the current user. An administrator can override that option. Treat it as a reminder, not a control.

Building break-glass accounts that still work

Microsoft's emergency access guidance calls for at least two accounts. The requirements that matter most are below.

Microsoft's first position is shared accounts not tied to a person. The same page offers an alternative: individual emergency access accounts for administrators, for accountability and for use from remote locations.

Mandatory MFA changes the old pattern

Mandatory MFA has rolled out in two phases. Phase 1, from October 2024, covers the Azure portal, Microsoft Entra admin center and Intune admin center, with the Microsoft 365 admin center following from February 2025. Phase 2, starting 1 October 2025, covers create, update and delete operations through Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools and REST endpoints.

Microsoft states that break-glass accounts must also sign in with MFA once enforcement begins, and recommends a passkey or certificate-based authentication. The same page says that exceptions or exclusions in a Conditional Access MFA policy no longer apply for this enforcement. A password in a safe is therefore not a complete emergency credential for these admin surfaces.

Do not read this as "stop excluding the accounts". Microsoft still says to exclude them from policies that block or restrict sign-in, because a policy needing a compliant device or another control could make them unusable in the emergency they exist for. The phishing-resistant credential protects the account.

Prove the exclusion is present

Microsoft recommends a dedicated security group, such as EmergencyAccess, excluded from the relevant policies. This check was written for this article from the published cmdlet and excludeGroups property. It is read-only and lists enforced policies that lack the group:

Connect-MgGraph -Scopes 'Policy.Read.All'
$group = '<EmergencyAccess group object ID>'
Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object { $_.State -eq 'enabled' -and $_.Conditions.Users.ExcludeGroups -notcontains $group } |
  Select-Object DisplayName, State

Review the output by hand. The check looks only at ExcludeGroups, so a policy that excludes the accounts directly through ExcludeUsers is listed as a false alarm. A policy that targets one small group, or applies only session controls, may correctly have no exclusion. An exclusion also depends on group membership, so treat changes to that group as a security event.

Monitor and rehearse

Microsoft's guidance is to alert on every sign-in by these accounts through Azure Monitor or a similar tool, and to review each use afterwards. The published query shape needs the accounts' object IDs:

SigninLogs
| where UserId == "<object ID 1>" or UserId == "<object ID 2>"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

The guidance asks for validation at least every 90 days, and after staff changes or changes to Entra subscriptions. The drill confirms that authorised staff can reach the credential, that the account can sign in and do administrative work, and that the alert fires. Warn the security monitoring team first.

A safe order for testing a policy

1. Take a reference copy

The conditionalAccessPolicy resource has a state of enabled, disabled or enabledForReportingButNotEnforced. Export before you change anything. The -Depth default of 2 would truncate nested conditions, so set it explicitly. This combined command was written for this article.

Connect-MgGraph -Scopes 'Policy.Read.All'
Get-MgIdentityConditionalAccessPolicy -All |
  ConvertTo-Json -Depth 20 | Out-File .\ca-policies-before-change.json

The export is for comparison and contains tenant-specific object IDs. Protect it like other security configuration.

2. Create the policy in report-only

Report-only evaluates a policy without enforcing it. Templates default to report-only. To change an enforced policy, Microsoft advises creating a report-only copy with the proposed change and comparing the two.

Copies count. The limit is 240 policies per tenant in any state, including report-only and off.

Report-only has limits:

• Policies scoped to User Actions cannot be evaluated this way.
• Report-only policies requiring a compliant device can prompt macOS, iOS and Android users to select a device certificate, and the prompts can repeat. Microsoft's remedy is to exclude those platforms from such report-only policies.

Microsoft's emergency access page says report-only policies do not require an emergency exclusion. Its deployment plan says to verify the accounts are excluded from all policies before deployment. The editorial recommendation is to add the exclusion at creation, so it is already there on the day the policy is switched on.

3. Simulate with What If

The What If tool requires an identity, target resource, device platform and client app. For each policy that does not apply, it reports the first condition not satisfied. Run a case per user type: a normal user, an administrator, an emergency account, a guest and a service account if in scope.

Know what it cannot show:

• It does not test service dependencies. A Teams test ignores a policy on Exchange Online.
• Only enabled and report-only policies are evaluated. A draft left Off is invisible.
• Conditions you leave out cannot be evaluated. In Microsoft's example, a policy with a location and a sign-in risk condition shows as not applying until both are supplied.
• Application groups such as Office 365 or Microsoft Admin Portals do not match. Supply the App ID.

The same engine is available through the evaluate action in Microsoft Graph, which suits repeatable test cases. It needs Policy.Read.ConditionalAccess. This body is cut down from Microsoft's example. appliedPoliciesOnly set to false includes the policies that do not apply.

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

{
  "signInIdentity": { "@odata.type": "#microsoft.graph.userSignIn", "userId": "<user object ID>" },
  "signInContext": { "@odata.type": "#microsoft.graph.applicationContext", "includeApplications": [ "<application ID>" ] },
  "signInConditions": { "devicePlatform": "windows", "clientAppType": "browser", "country": "AU", "ipAddress": "<address>" },
  "appliedPoliciesOnly": false
}

Microsoft says a simulation does not replace an actual test run in a properly configured development environment.

4. Read real sign-ins for at least a week

Microsoft's plan suggests at least one week in report-only before enforcement. Results appear on the Report-only tab of each sign-in event.

Failures on administrators, service accounts and business applications are the first things to resolve. "User action required" is only safe if those users can actually complete the control, so confirm they have registered the required methods.

With sign-in logs in a Log Analytics workspace, this query summarises one policy. It was written for this article from the SigninLogs schema and the result values. It was not run, so check the field names in your own workspace first. It covers interactive user sign-ins only.

SigninLogs
| where TimeGenerated > ago(7d)
| mv-expand Policy = ConditionalAccessPolicies
| where tostring(Policy.displayName) == "<policy name>"
| summarize SignIns = count() by Result = tostring(Policy.result), AppDisplayName, ResourceDisplayName
| order by SignIns desc

Non-interactive, service principal and managed identity sign-ins are separate log types. Non-interactive sign-ins sit in the AADNonInteractiveUserSignInLogs table, where ConditionalAccessPolicies is listed as a string, so it would need parsing before mv-expand. Check those logs too, because service accounts and background application traffic are what this query under-reports.

The Insights and Reporting workbook needs a Log Analytics workspace, P1 licences, and at least Security Reader plus Log Analytics workspace Contributor. The policy impact view, a preview, covers interactive sign-ins only.

5. Pilot, then widen

Apply the policy to a group holding a non-admin test user, and compare expected and actual results from a written test plan. Include the exclusion cases.

Widen in rings. The editorial recommendation is to change one policy at a time, have a second administrator outside the policy's scope ready, and sign in with a normal admin account straight after each change.

When someone is locked out

Work in this order.

1. Record the failing sign-in. More Details on the error page gives identifiers for finding it, and Microsoft support asks for the request ID, time and date.
2. Find the policy. The Conditional Access tab of the event shows which policy interrupted the sign-in. Common codes, shown with the AADSTS prefix, are 53000 DeviceNotCompliant, 53001 DeviceNotDomainJoined, 53002 ApplicationUsedIsNotAnApprovedApp, 53003 BlockedByConditionalAccess and 53004 ProofUpBlockedDueToRisk.
3. Identify an unaffected administrator or the authorised emergency-access process. Preserve the sign-in evidence before deciding what policy change, if any, is justified.
4. Review whether the identified policy needs a temporary change to disabled or report-only state. The update operation needs Policy.Read.All and Policy.ReadWrite.ConditionalAccess. It retains omitted properties; still preserve the complete original configuration before any approved change.

Disabling a policy is a security change. Before considering it, retain its complete configuration, verify the exact affected policy and scope, identify a working administrative identity and record how protection will be restored. A qualified tenant administrator should follow Microsoft’s current procedure under a reviewed recovery plan; this article supplies no executable disabling request.

5. Find what changed. Filter the audit log by the Conditional Access service and compare old and new JSON under Modified Properties. Audit data is kept for 30 days by default, unless sent elsewhere through diagnostic settings.
6. If no administrator can sign in, submit a support request.
7. Afterwards, preserve the logs and review the use of the emergency account.

Undoing a deletion or a bad change

A deleted policy or named location can be restored within a 30-day soft-delete period. The portal path is Conditional Access, then Deleted policies. The dialog offers report-only or the state at deletion, which might be On. Microsoft recommends report-only first. A restored named location comes back without its trusted mark, so review it before marking it trusted again.

A Graph restore call exists only on the beta endpoint, which Microsoft does not support for production applications.

Microsoft Entra Backup and Recovery adds backups taken once a day and retained for seven days, for tenants with P1 or P2. All Conditional Access policy properties are in scope. Run a difference report first, because recovery applies directly to the tenant and cannot be undone automatically. It can recover selected object types or up to 100 specific object IDs.

What to choose and why

These are editorial recommendations.

Risks and limits

Warning: Changing a Conditional Access policy to enabled, or disabling one, takes effect on live sign-ins. Disabling a policy that enforces security reduces your security posture while it is off. Any policy disable or re-enable belongs in an approved recovery or change plan with verification of both access and the restored security controls.

Warning: Recovering from Entra Backup and Recovery changes the tenant directly. Review a difference report first.

• Protected actions can catch emergency accounts. They attach a Conditional Access policy to permissions such as updating policies, independent of the role used. The inference is that a protected-action policy must also exclude the emergency group, or the account may sign in but be unable to change the policy. Test this in the drill.
• Emergency accounts do not solve a full authentication outage. During an outage the Backup Authentication Service does not grant access to new sessions. The inference is that a break-glass account that was not already signed in gets no help there.
• Leave resilience defaults on. Microsoft warns that disabling them on a policy assigned to a group or role reduces resilience for all users in the tenant, because membership cannot be evaluated in real time during an outage.
• Exclusions weaken coverage. An emergency account sits outside your normal controls, so its credential custody and alerting carry that risk.
• One recovery page is inconsistent. Microsoft's recovery page says object types other than a short list are hard deleted, while the same page gives steps for restoring soft-deleted policies. Confirm the Deleted policies view in your own tenant before relying on it.

Sources

Opened 10 November 2026. Sources behind the corrections reopened 10 November 2026.

• Plan a Conditional Access deployment
• Report-only mode
• What If tool
• Troubleshoot Conditional Access
• Troubleshoot policy changes with the audit log
• Building a Conditional Access policy
• Users and groups
• Target resources
• Service dependencies
• Resource exclusion enforcement
• Resilience defaults
• Insights and reporting workbook
• Emergency access accounts
• Protected actions
• Mandatory multifactor authentication
• Resilient access control strategy
• Recover from deletions
• Microsoft Entra Backup and Recovery
• Recover objects
• Supported objects and recoverable properties
• conditionalAccessPolicy resource
• conditionalAccessUsers resource
• Update conditionalAccessPolicy
• Restore conditionalAccessPolicy (beta)
• conditionalAccessRoot: evaluate
• appliedConditionalAccessPolicy resource
• Get-MgIdentityConditionalAccessPolicy
• ConvertTo-Json
• SigninLogs table reference
• AADNonInteractiveUserSignInLogs table reference
• Sign-in logs overview

This article was originally published on 10 November 2026.