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.

• 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 without triggering any audit trail
• Credentials that are never rotated become stale and may have been exposed in a previous breach without the organisation being aware
• Account used routinely for daily admin work rather than genuine emergencies, increasing credential exposure and reducing the value of sign-in alerting
• No sign-in alerting means break-glass account use goes unnoticed until significant damage has already been done
• Credentials shared informally — via a team document, a chat message, or a shared note — means multiple people hold them and the blast radius on any exposure is uncontrolled
• No credential rotation means a former employee or contractor who saw the break-glass password retains Global Administrator access indefinitely after departure

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.

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

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.

Microsoft: Manage emergency access accounts in Microsoft Entra ID - https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access

Microsoft: Monitor emergency access account sign-ins - https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access#monitor-sign-in-and-audit-logs

Microsoft: Conditional Access and break-glass accounts - https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-all-users-mfa

After reviewing break-glass account configuration, also check these related risk areas:

• Conditional Access Exclusions — break-glass accounts must be excluded from CA policies; confirm those exclusions are explicitly documented and that no other accounts are using the same exclusion pattern inappropriately
• Admins with Risky MFA Settings — break-glass accounts should use phishing-resistant MFA; if they rely on phone-based MFA or have no MFA registered, they represent the same weakness as a poorly secured admin account
• Unprotected Admin Portals — confirm whether break-glass account sign-ins reach admin portals without additional access controls beyond the account credentials
• Dormant Users — break-glass accounts are intentionally dormant; ensure they are distinguishable from forgotten dormant admin accounts and handled through dedicated monitoring rather than routine dormancy remediation
• CA MFA Bypass Paths — understand whether your break-glass accounts fall into any existing CA bypass paths, or whether they maintain their own clearly scoped, documented exclusion