Exclude Break-Glass Accounts from Conditional Access

Conditional Access policies can lock every administrator out of your Microsoft Entra tenant.

Before you begin

  • An Atlas AVD administrator account (creating and editing Conditional Access policies is limited to administrators)
  • The Global Administrator or Privileged Role Administrator role in Microsoft Entra ID to create the break-glass accounts themselves
  • Microsoft Entra ID P1 or P2 licensing, which Conditional Access requires

Why Conditional Access can lock you out

Conditional Access policies are enforced by Microsoft Entra ID for every sign-in they match, administrators included. Atlas AVD creates and edits ordinary Entra policies, so once a policy is enabled, Microsoft enforces it whether you sign in through Atlas, the Azure portal, or the Entra admin center.

Common ways a policy locks people out:

  • A Block access policy that targets All users, or a group your administrators belong to.
  • A policy that requires a compliant or hybrid-joined device when your administrators sign in from devices that are neither.
  • A location rule that only allows trusted locations, signed in to from somewhere else, or with the named location defined incorrectly.
  • A requirement for multifactor authentication before your administrators have registered a method.

If every administrator is locked out and no excluded account exists, the only way back in is a Microsoft support case to regain access to the tenant, which can take days. A break-glass account turns that into a five-minute fix: sign in with it and turn the policy off.

What a break-glass account is

A break-glass account (Microsoft calls it an emergency access account) is a highly privileged account you keep for exactly this situation. Following Microsoft's guidance, set up break-glass accounts like this:

  • Create at least two, so losing the credential for one does not leave you stranded.
  • Make them cloud-only accounts on your tenant's .onmicrosoft.com domain, not synced from on-premises Active Directory and not federated, so they still work when your identity provider or sync is down.
  • Assign the Global Administrator role permanently, not as an eligible role that must be activated.
  • Do not tie them to a person: no mailbox in daily use and no personal phone as the only sign-in method.
  • Protect them with phishing-resistant authentication, such as a FIDO2 security key or passkey stored in a safe, or certificate-based authentication. Microsoft now requires multifactor authentication to sign in to the Azure portal and admin centers, so a password alone is no longer enough for these accounts either.
  • Alert on every sign-in. These accounts should never be used day to day, so any sign-in is worth investigating.
  • Test them on a schedule (Microsoft suggests at least every 90 days) to confirm the credentials and security keys still work.

Designate your break-glass accounts in Atlas

Tell Atlas which accounts are your break-glass accounts once, and every Conditional Access change you make in Atlas is checked against them.

  1. In the left sidebar, open Security → Conditional Access.
  2. In the Break-glass accounts card, select Manage.
  3. Add each break-glass account under Break-glass accounts, or the group that holds them under Break-glass group, then select Save accounts.
  4. Check each account in the card. Atlas marks an account it could not find, a disabled account, one synced from on-premises, one outside your .onmicrosoft.com domain, and one that is not a permanent Global Administrator. Fix anything it flags in the Microsoft Entra admin center.

If you designate a group, make it role-assignable. Only Global Administrators and Privileged Role Administrators can change the members of a role-assignable group, so nobody else can exempt an account from all of your policies by adding it to the group. Atlas flags a break-glass group that is not role-assignable.

Exclude them from the policies you already have

Exclusions belong on every policy, not just new ones. Once your break-glass accounts are designated, the Break-glass accounts card lists every policy that can block sign-ins and does not exclude them, including report-only policies, so you fix them before they are switched on.

Select Add exclusions to add your break-glass accounts to all of those policies at once. Atlas only adds the exclusions; nothing else in the policies changes, and excluding accounts can never lock anyone out. You can also do it one policy at a time: open the policy, select Edit Policy, add the accounts under Users Excluded (or their group under Groups Excluded), and select Save Changes.

Create a policy with the guided wizard

  1. Open Security → Conditional Access and select Create policy. The page opens with a warning that Conditional Access policies may lock you out.
  2. On the Protect step, name the policy and choose the cloud apps it governs.
  3. On the Who step, choose the users and groups the policy applies to. Your designated break-glass accounts are already filled in under Users Excluded and Groups Excluded; leave them there.
  4. Finish the Where, Device, and Requirements steps. Leave Roll-out mode on Report-only (recommended) for a new policy.
  5. On the Review step, check that Excluding lists your break-glass accounts, then select Create policy.

The safety review before you save

Whenever you create, edit, or import a policy that will be enforced and can block sign-ins, Atlas checks it before saving and shows a review if anything could lock administrators out:

  • No break-glass accounts designated. The policy applies to all users or to administrator roles, and the tenant has no break-glass accounts in Atlas.
  • Break-glass accounts are not excluded. One or more of your designated accounts or groups would be covered by the policy. Select Add break-glass exclusions to add them, then save again.
  • This policy applies to you. When you are a member of the tenant you are changing and the policy covers you, Atlas offers Exclude me from this policy. It is turned on for you when no excluded break-glass account stands behind you, so you are not the only way back in.

If a risk remains, Save policy stays unavailable until you tick the acknowledgement that the change could lock administrators, including you, out of the tenant. Atlas records that acknowledgement, and the version of its wording, in the audit log with the change. Atlas enforces this check on its server as well, so a change made through the Atlas API is held to the same rule.

Check report-only results before you enforce

  • Start in report-only mode. Atlas creates new policies as Report-only by default, so Entra records what the policy would have done without enforcing it.
  • Open the policy in Atlas to see its Report-only results: how many sign-ins in the last 7 days it would have blocked or prompted for more verification, and who. Administrators, your break-glass accounts, and you are listed first and flagged.
  • When you switch a report-only policy to Enabled, the safety review shows the same results, so you see who would be blocked before you save.
  • Use the What If tool in the Microsoft Entra admin center to check how a policy treats a specific user, including your break-glass accounts, before enforcing it.

Report-only results are read from your tenant's sign-in logs, which need the AuditLog.Read.All permission and Microsoft Entra ID P1 or P2.

Automatic rollback if nobody can sign in

When a change leaves a policy enforced and changes who it lets in, such as switching it to Enabled or changing its users or requirements, Atlas starts a 15-minute safety window. A banner on the Conditional Access page shows the policy and when the window ends.

Select I can still sign in to keep the change. Atlas asks you to sign in again first, so the confirmation proves you can still get in after the change. If the new policy blocks you, you cannot complete that sign-in, and when the window ends Atlas puts the policy back the way it was, or switches a new policy to report-only. You can also select Restore now to undo the change immediately.

Atlas makes the rollback with its own application credentials, which Conditional Access policies for users do not apply to, so it still works when no administrator can sign in. Every confirmation and rollback is written to the audit log, and the administrator who made the change is notified when Atlas restores a policy.

If someone changes the policy outside Atlas during the window, for example in the Entra admin center, Atlas leaves it alone rather than undo their change. If you manage this tenant from your own organization's directory, as many MSPs do, your fresh sign-in is to your own directory, not the customer's, so the confirmation is your word that you checked access rather than proof of it. Check with an account in the customer's tenant before you confirm.

If you get locked out

  1. Wait for the safety window. If the change was made in Atlas in the last 15 minutes, Atlas restores the policy on its own when the window ends.
  2. Otherwise, sign in to the Microsoft Entra admin center with a break-glass account.
  3. Open Conditional Access → Policies, find the policy that caused the lockout, and set it to Off or Report-only.
  4. Confirm your normal administrator accounts can sign in again, then fix the policy and re-enable it.
  5. Review the break-glass sign-in alert, and rotate or re-secure the account's credentials if your process requires it.

Policies you create through Atlas are ordinary Microsoft Entra policies, so you can always turn them off directly in the Entra admin center, even if Atlas itself is unavailable.

Next steps