Break-Glass Accounts: Emergency Access Without Monitoring or Guardrails

Why this risk matters

Break-glass accounts are a legitimate and necessary part of any well-run Microsoft 365 environment. They exist to ensure that administrators can still access the tenant if all normal admin accounts are locked out — due to an MFA outage, a Conditional Access misconfiguration, or a federation failure.

But break-glass accounts are only safe when they are tightly controlled. Overe flags break-glass accounts that have weak or no MFA, are being used outside of genuine emergencies, are shared without clear ownership, or are not subject to active sign-in monitoring. An unmonitored account with Global Administrator access and no MFA enforcement is not a safety net — it is a standing vulnerability.

The most important thing about a break-glass account is not that it exists, but that its use is immediately visible and that its credentials are protected in proportion to the access it provides.

What happens if this is abused

  • Attacker obtains break-glass credentials — from a shared document, a credential store, or a phishing campaign — and gains unrestricted Global Admin access with no MFA challenge
  • Break-glass account used by an insider who knows about it but lacks formal access, bypassing all normal role and access controls
  • Credentials that are never rotated become stale and may have been exposed in a previous breach without anyone knowing
  • Account used routinely for daily admin work rather than genuine emergencies, increasing credential exposure and reducing the value of alerting
  • No sign-in alerting means break-glass account use goes unnoticed until significant damage has been done

When this is expected or acceptable

Break-glass accounts should exist. They are a recognised best practice and recommended by Microsoft. What makes them acceptable is the surrounding controls: credentials managed in a physical safe or a tightly controlled credential vault, at least two accounts for redundancy, cloud-only identities not synced from on-premises, excluded from Conditional Access policies with monitoring compensating for the exclusion, and immediate alerting on any sign-in.

A break-glass account that is used more than a handful of times per year should trigger a review — it may indicate that normal admin access is too restrictive or that the account is being used inappropriately.

Checks to perform before taking action

Before reviewing or modifying break-glass account configuration:

  • Confirm how many break-glass accounts exist and whether they are cloud-only identities not synced from on-premises
  • Check the MFA registration on break-glass accounts — ideally FIDO2 keys or phone numbers not associated with any named employee
  • Review when break-glass accounts last signed in and whether each sign-in was legitimate and documented
  • Confirm whether there is alerting in place for any break-glass account sign-in event
  • Check whether the accounts are held by named individuals or shared — shared credentials without clear ownership is a risk
  • Review the credential storage method — credentials shared in a document, email, or chat tool are exposed
  • Confirm whether the accounts are excluded from Conditional Access policies and whether that exclusion is explicitly documented

Safe remediation steps

  1. Ensure at least two break-glass accounts exist with separate credentials and owners
  2. Use cloud-only identities not synced from on-premises directories
  3. Configure FIDO2 security keys or another phishing-resistant MFA method — avoid phone numbers tied to named employees
  4. Set up immediate alerting on any sign-in from either break-glass account
  5. Rotate credentials on a defined schedule and store them in a physically secured or tightly access-controlled credential store
  6. Ensure accounts are excluded from Conditional Access policies with the exclusion explicitly documented and justified
  7. Review sign-in history and investigate any sign-in that was not formally authorised and documented

Where direct remediation is required, Overe provides links to the appropriate Microsoft admin controls to complete the action safely.

Related risks and follow-on checks

  • Conditional Access exclusions creating risk
  • Admins with risky MFA settings
  • Unprotected admin portals
  • Privileged role assignments without clear ownership
TBD CTA