Skip to content

Break-Glass Accounts

Break-glass accounts are emergency access accounts for when normal administration fails: Conditional Access locks everyone out, PIM is down, MFA is broken or federation fails. They deliberately break the platform's "no standing privilege" rule, so they must be protected, watched and tested more closely than any other account.

The setup

Item Detail
Accounts Two, ea-adm-breakglass-01 and ea-adm-breakglass-02, on the tenant's initial *.onmicrosoft.com domain
Group grp-identity-emergency-access, a role-assignable security group
Role Global Administrator, assigned to the group, permanently active. Not through PIM.
Conditional Access Excluded from every policy
Owned by Nobody's pipeline. Created once by hand (see below). The Conditional Access repository only reads the group by name.

How it was created

The accounts, group, membership and role assignment were created once, by hand, by a Global Administrator running an Azure CLI / Microsoft Graph script. They are deliberately not in Terraform:

  • azuread_user stores the password in Terraform state. Anyone who could read the state would hold Global Administrator credentials.
  • FIDO2 keys can only be registered interactively, by signing in as the account with the key.
  • No pipeline should hold the rights needed to create Global Administrators.

The trade-off is no drift detection. If someone removes the role or a member, nothing flags it, so the quarterly test checks both.

The full runbook and script, including read-only Verify commands for the quarterly test, are in the Conditional Access repository at create-bg-accounts.md. The script is safe to re-run. It did the following:

  1. Create the two cloud-only users on the initial onmicrosoft.com domain (az ad user create).
  2. Create grp-identity-emergency-access with isAssignableToRole = true (Graph POST /groups; az ad group create can't set this flag, and it can only be set at creation).
  3. Add both users to the group (az ad group member add).
  4. Assign Global Administrator (62e90394-69f5-4237-9190-012177145e10) to the group at scope / (Graph POST /roleManagement/directory/roleAssignments). This is a permanent active assignment.
  5. Sign in as each account and register its FIDO2 keys.

Account rules

  • Cloud-only accounts on the onmicrosoft.com domain. They must work even if a custom domain or federation fails.
  • Phishing-resistant second factor (FIDO2 keys), kept with the credentials. No phone or Authenticator app. Being excluded from Conditional Access doesn't remove MFA: Microsoft requires MFA for every sign-in to the Azure portal, the Entra admin center and Azure CLI/PowerShell, so the key is required.
  • Password never expires, and is excluded from any rotation policy. Split the password across the safe so no single person holds all of it.
  • No other use: no mailbox, no other group membership, no everyday sign-in.
  • Two accounts so that losing one (a locked key, a forgotten part of the password) doesn't lose emergency access.

This is recorded as accepted exception EX-004 in the Exceptions Register.

Monitoring

Any sign-in by a break-glass account should raise a critical alert straight away. Legitimate use is rare and always announced. The detection query is in Threat Detection. Also alert on:

  • any change to grp-identity-emergency-access membership;
  • any change to either account (password reset, new authentication method, disabling).

Testing

Every quarter, sign in with each account:

  1. Announce the test to whoever receives the alerts.
  2. Sign in from a clean private browser with the FIDO2 key, check Global Administrator is active, then sign out.
  3. In the sign-in log entry, confirm every Conditional Access policy shows Not applied.
  4. Confirm grp-identity-emergency-access still contains exactly the two accounts, and still holds the active, permanent Global Administrator assignment. This replaces the drift detection that Terraform would otherwise give.
  5. Confirm the alert fired. A test that doesn't raise an alert has found a monitoring gap.
  6. Record the date and result, and return the credentials to the safe.

An untested break-glass account can't be relied on.

After use

  1. Record why, who, when and what was done.
  2. Reset the password of every account used, and check its FIDO2 key. Do this after any use.
  3. Review every action taken in the session, using AuditLogs and AzureActivity.
  4. Bring Terraform state back in line with any portal changes.