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.

Status: accounts in place, monitoring and testing planned

Two accounts exist, with standing Global Administrator, and every Conditional Access policy excludes them. Sign-in alerting and a scheduled sign-in test are not yet in place.

The setup

Item Detail
Accounts Two, bg-admin-01 and bg-admin-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, permanent. Not through PIM.
Conditional Access Excluded from every policy
Owned by The tenant bootstrap deployment (human, PIM-elevated apply). The Conditional Access repository only reads the group by name.

Where the group is defined

The Conditional Access repository says the group and its role assignment come from azure-tenant-bootstrap (emergency-access.tf). That file isn't in the current checkout of the bootstrap repository. Confirm where the group is defined, and link to it here.

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.
  • 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, check Global Administrator is active, then sign out.
  3. Confirm the alert fired. A test that doesn't raise an alert has found a monitoring gap.
  4. 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 and check the FIDO2 key.
  3. Review every action taken in the session, using AuditLogs and AzureActivity.
  4. Bring Terraform state back in line with any portal changes.