Skip to main content
Five Steps for Cloud Compliance Readiness·A practical playbook for security teamsDownload
Guide · Microsoft 365

How to set up break-glass accounts in Microsoft 365

  • Updated 18 Oct 2026

This guide shows how to create two emergency access (break-glass) accounts that can still sign in to your Microsoft 365 tenant when normal admin sign-in is broken. It is written for tenant administrators who need a safe way back in after a Conditional Access mistake, an MFA outage or a lost admin device.

Before you start

You need a Global Administrator account to create the emergency accounts, and a second person who can witness and store the credentials.

  • Role: Global Administrator (to create the users and assign the role).
  • Licences: none are required for the accounts themselves. Conditional Access exclusions need Microsoft Entra ID P1 or higher, which you already have if you use Conditional Access.
  • Tools: the Microsoft Entra admin center and the Microsoft Graph PowerShell module (Install-Module Microsoft.Graph -Scope CurrentUser).
  • Decide where credentials live: for example a sealed envelope in two separate safes, or a hardware passkey kept by two different people. Do not store them in a mailbox or password manager that depends on the tenant you are protecting.

Step by step

Microsoft recommends at least two emergency access accounts. Follow these steps for each one.

  1. Open the Microsoft Entra admin center, then Entra ID > Users > New user > Create new user.
  2. Use the initial .onmicrosoft.com domain for the user name, not a custom domain, so a federation or DNS problem cannot lock the account out. Pick a neutral display name such as Emergency Access 01.
  3. Make the account cloud-only. Do not synchronise it from on-premises and do not federate it.
  4. Set a long, random password (Microsoft suggests a very long password that never expires) and record it in the place you decided on.
  5. Open Entra ID > Roles & admins > Global Administrator > Add assignments and assign the role as a permanent active assignment. Do not make it eligible through Privileged Identity Management: the account must work even when PIM is unavailable.
  6. Register a phishing-resistant sign-in method for the account, either a FIDO2 passkey or certificate-based authentication. Admin portals require MFA, so a password alone will not be enough to use the account in an emergency. Use a different method or key for each account where you can.
  7. Exclude at least one of the accounts from every Conditional Access policy that could block it. Go to Entra ID > Conditional Access > Policies, open each policy, then Users > Exclude > Users and groups. Keep the exclusion limited to these accounts and compensate with the monitoring in the next step.
  8. Set up monitoring: create an alert that fires whenever either account signs in. Use Microsoft Entra sign-in logs sent to Azure Monitor / Log Analytics, or another alerting tool you already run. Any sign-in should be unusual and reviewed.
  9. Write a short runbook: who may retrieve the credentials, when it is allowed, and how the password is changed afterwards.

This changes your tenant. The commands below create a user and assign a role. Review and run them only in a change window, and use your own domain and values. The verification in the next section is read-only and can be run first, to see what you already have.

# CHANGE: creates a cloud-only user and assigns Global Administrator
Connect-MgGraph -Scopes "User.ReadWrite.All","RoleManagement.ReadWrite.Directory"

$password = Read-Host "Enter a long random password" -AsSecureString
$plain = [System.Net.NetworkCredential]::new("", $password).Password

$user = New-MgUser -DisplayName "Emergency Access 01" `
  -UserPrincipalName "ea01@yourtenant.onmicrosoft.com" `
  -MailNickname "ea01" -AccountEnabled `
  -PasswordProfile @{ Password = $plain; ForceChangePasswordNextSignIn = $false } `
  -PasswordPolicies "DisablePasswordExpiration"

# 62e90394-... is the built-in Global Administrator role template id
New-MgRoleManagementDirectoryRoleAssignment `
  -PrincipalId $user.Id `
  -RoleDefinitionId "62e90394-69f5-4237-9190-012177145e10" `
  -DirectoryScopeId "/"

Check it worked

These commands only read data. They list who holds a permanent Global Administrator assignment and which enabled Conditional Access policies exclude users, so you can confirm the emergency accounts appear in both places.

Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All","Policy.Read.All"

# 1. Permanent Global Administrator assignments (emergency accounts should be listed)
Get-MgRoleManagementDirectoryRoleAssignment `
  -Filter "roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'" `
  -ExpandProperty principal |
  ForEach-Object { $_.Principal.AdditionalProperties.userPrincipalName }

# 2. Conditional Access policies and the users they exclude
Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State,
    @{n="ExcludedUsers";e={$_.Conditions.Users.ExcludeUsers -join ", "}}

Then do a real sign-in test with each account in a private browser window, using the stored credentials, and confirm the sign-in raises your alert. Repeat this test on a schedule you set, for example twice a year.

Common mistakes

  • Only one account. A single account is a single point of failure. Create two and store them separately.
  • Using a custom domain or a synced account. A federation or sync failure then takes the emergency account down with everything else.
  • Making the role eligible in PIM. Emergency accounts need a permanent assignment so they work when PIM or MFA services are unavailable.
  • Forgetting MFA for admin portals. A password-only account may be unusable in practice. Register a passkey or certificate-based sign-in.
  • Excluding the account from Conditional Access but never alerting on it. An unmonitored exclusion is a hidden way into the tenant.
  • Never testing. Credentials that have been rotated, lost or blocked are only discovered during the outage.
  • Using the accounts for daily admin work. They are for emergencies only.

How ConfigCobra helps

ConfigCobra is read-only and never changes your tenant, so it cannot create these accounts for you. After you have set them up, a scan checks the related CIS benchmark controls, including the one for two emergency access accounts and the one for monitoring their activity. CIS marks the first as a control that needs manual verification. The Microsoft 365 inventory lists your admins and directory roles, and its relation graph shows how those accounts connect to roles and Conditional Access scope. For a failing control, remediation impact analysis shows what a fix would change in your environment before you apply it. Continuous scanning and drift detection alert you if a control regresses later.

See where your Microsoft 365 stands

A read-only assessment against the CIS benchmarks, prioritised so you know what to fix first.

Get in touch

Let's talk.

Whether you're evaluating ConfigCobra, running an audit, or managing a client fleet — we respond within one business day.

Free trial