Category: Privileged Access

Emergency Access Account

Also known as: Break Glass Account, Break-Glass Account, Emergency Break Glass Account

Simply put

An emergency access account is a special, highly privileged account kept in reserve so administrators can regain control of an identity system when normal access fails, such as during a lockout or major outage. It is used only in rare, critical situations rather than for day-to-day work. Organizations are typically advised to maintain more than one such account to avoid a single point of failure.

Formal definition

An emergency access account (also called a break-glass account) is a highly privileged account provisioned in advance to preserve administrative access to an identity environment when standard authentication or authorization paths are unavailable, such as inadvertent lockout, federation failure, or loss of other admin credentials. In Microsoft Entra ID deployments, these accounts are commonly assigned the Global Administrator role so that operators can regain control of the tenant during an emergency. Microsoft's guidance recommends maintaining multiple emergency access accounts to reduce the risk of a single point of failure; exact configuration, credential handling, and monitoring controls vary by deployment and are out of scope for this definition. Note that such accounts pertain to privileged access recovery and should be governed under strict access controls and monitoring, though the specific safeguards depend on organizational policy.

Why it matters

Identity systems concentrate enormous operational risk: if the normal authentication or authorization paths fail, administrators can lose the ability to manage the very system that controls all other access. A misconfigured Conditional Access policy, a federation outage, an expired credential, or the accidental removal of the last privileged administrator can leave a tenant effectively ungoverned at precisely the moment control is most needed. Emergency access accounts, commonly called break-glass accounts, exist to preserve a recovery path when those standard paths are unavailable.

Because these accounts hold extraordinary privilege, in Microsoft Entra ID deployments they are commonly assigned the Global Administrator role, they are also an attractive target and a significant liability if left unmonitored. The same properties that make them valuable during an outage (broad authority, independence from normal sign-in dependencies) make them dangerous if compromised or misused. This tension is why Microsoft's guidance treats them as accounts to be provisioned deliberately, governed under strict controls, and reserved for rare, critical situations rather than day-to-day administration.

Who it's relevant to

IAM Engineers and Tenant Administrators

Those responsible for Microsoft Entra ID or comparable identity environments provision and maintain emergency access accounts as part of a recovery plan. They must ensure at least two such accounts exist to avoid a single point of failure and that the accounts remain functional and independent of the normal sign-in dependencies that might fail during an incident.

Privileged Access Management (PAM) Leads

Because these accounts typically hold the highest privilege available in the environment, PAM owners are concerned with how they are stored, invoked, and monitored. The specific safeguards depend on organizational policy, but the accounts fall squarely within privileged access recovery scope and warrant the strictest controls.

Security Architects

Architects designing resilient identity systems account for the scenario in which normal authentication or authorization paths become unavailable. Emergency access accounts are a deliberate design element for regaining control of a tenant, and their existence, count, and isolation should be part of the overall recovery architecture.

Compliance and Audit Officers

Given the elevated authority of these accounts, auditors are interested in whether their use is tightly governed and monitored. Any invocation of a break-glass account is an exceptional event, and demonstrating appropriate oversight of such accounts is relevant to controls around privileged access, though the exact requirements depend on the applicable framework and organizational policy.

Inside Emergency Access Account

Highly Privileged Credentials

An emergency access account (often called a break-glass account) typically holds broad administrative privileges, such as global administrator or root-equivalent rights, so it can restore access or manage systems when normal administrative paths are unavailable.

Restricted, Controlled Access to the Credential

The credential is usually stored under tight control, for example in a sealed physical envelope, a vault, or a privileged access management (PAM) system, so that it is not casually retrievable and its use requires a deliberate, authorized action.

Strong Authentication Requirements

Because the account is highly privileged, its use is typically protected by strong authentication such as MFA. Some deployments intentionally use factors that differ from routine administrative logins so the emergency account does not depend on the same systems that may be failing.

Monitoring and Alerting

Use of the account is typically instrumented with logging and real-time alerting, so that any sign-in triggers immediate notification to security or operations teams and generates an auditable record of the event.

Exclusion from Conditional or Access Policies

In many deployments the account is deliberately excluded from certain conditional access or automated lockout policies so that a misconfigured policy cannot itself prevent emergency recovery. The specific exclusions depend heavily on vendor and configuration.

Defined Usage Procedure

An emergency access account is generally accompanied by a documented procedure describing when it may be used, who may authorize its use, and the steps for post-use review and credential rotation.

Common questions

Answers to the questions practitioners most commonly ask about Emergency Access Account.

Is an emergency access account the same as a shared service account that admins use for routine work?

No. An emergency access account (often called a break-glass account) is intended for exceptional, last-resort use when normal authentication or authorization paths are unavailable, not for day-to-day administration. Using it routinely defeats its purpose and undermines the heightened monitoring and controls typically placed around it. Service accounts, by contrast, are provisioned for regular automated or application workloads and are governed through standard lifecycle and access processes.

Does exempting an emergency access account from MFA make it inherently insecure?

Not necessarily, though the tradeoff must be understood. In some deployments a break-glass account is deliberately excluded from certain conditional access or MFA policies so it remains usable if the MFA infrastructure itself fails. This does not mean the account is unprotected; compensating controls such as a long, high-entropy stored credential, physical or split-knowledge custody, strict monitoring, and alerting on any use are typically applied. Whether MFA is retained or intentionally bypassed depends on the failure modes you are designing against, and the decision should be documented rather than assumed.

How many emergency access accounts should an organization typically maintain?

Practice varies, but many deployments provision more than one to avoid a single point of failure, for example if one account's credential is lost or the account is itself locked out. The exact number depends on the environment, the platforms being protected, and organizational policy. The goal is availability under failure conditions balanced against the added attack surface each account represents.

How should the credentials for an emergency access account be stored and controlled?

Credentials are typically stored so that no single individual can use them unilaterally, often through split-knowledge or dual-control arrangements, a sealed physical safe, or a privileged access management vault with check-out workflows. The specific mechanism depends on tooling and policy. The intent is to keep the credential retrievable during a genuine emergency while ensuring retrieval is deliberate, authorized, and leaves an auditable trail.

What monitoring and alerting should be applied to emergency access accounts?

Because legitimate use is rare, any authentication or activity involving these accounts is typically treated as a high-priority security event. Deployments commonly configure real-time alerts on sign-in, on credential retrieval from the vault, and on privileged actions performed by the account, routing notifications to security operations. Correlating these events with an approved incident or change record helps distinguish authorized break-glass use from potential misuse.

How should emergency access accounts be handled in access reviews and governance processes?

These accounts are typically included in periodic access certification and reviewed for their standing privileges, credential age or rotation status, custody arrangements, and evidence of any use since the last review. Governance processes should confirm the accounts still exist, remain correctly scoped, and that stored credentials have been rotated after any use. This keeps them subject to identity governance oversight even though they sit outside normal runtime workflows.

Common misconceptions

Emergency access accounts are just spare administrator accounts that anyone on the team can use when convenient.

They are intended strictly for break-glass scenarios where normal access is unavailable. In most deployments their use is tightly controlled, deliberately inconvenient, monitored, and subject to after-the-fact review, rather than a routine alternative login.

Because emergency accounts must remain usable during outages, they should be exempt from security controls like MFA and logging.

Exclusion from some policies (such as certain conditional access rules that could cause lockout) is common, but this does not mean removing all protection. These accounts are typically among the most heavily monitored and are usually still protected by strong authentication; exclusions should be scoped narrowly and intentionally.

One emergency access account is enough to guarantee recovery.

Relying on a single account creates a single point of failure; if that one credential is lost, compromised, or itself blocked, recovery may be impossible. Many deployments provision more than one break-glass account to reduce this risk, though the exact number depends on the environment.

Best practices

Store the emergency credential under strict control, such as a sealed record in a physical safe or a dedicated privileged access management vault, and limit who can retrieve it.

Enable comprehensive logging and real-time alerting so that any sign-in with the account immediately notifies security and operations teams and produces an auditable record.

Protect the account with strong authentication, and where feasible use factors that do not depend on the same systems that would fail during an outage, so the recovery path remains available.

Provision more than one emergency access account where appropriate to avoid a single point of failure in recovery scenarios.

Document a clear break-glass procedure covering authorized use cases, approval steps, and mandatory post-use review, and rotate the credential after each use.

Scope any exclusions from conditional access or lockout policies narrowly and intentionally, reviewing them regularly rather than broadly exempting the account from all controls.