What is an Entra emergency access account?

It is an exceptional administrative account designed to remain usable when normal access paths fail.

The emergency account, sometimes referred to as a “break glass” account, is neither a day-to-day support account nor a shortcut for bypassing controls. It is used solely to regain control of the tenant when an identity outage, a misconfigured policy, the loss of MFA methods or a governance error prevents all usual administrators from accessing it. Its privilege level is high because it must be able to correct the incident; its use must therefore be rare, visible and immediately reviewed.

Microsoft recommends two or more accounts that are cloud-only and based on the .onmicrosoft.comdomain, without relying on local federation. The Microsoft documentation, updated on 5 June 2026, also specifies that these accounts must be reserved for emergencies, monitored and regularly validated. Redundancy is essential: a single lost key, disabled account or configuration error must not eliminate the last recovery path.

For a Belgian organisation, the issue goes beyond technology. It is necessary to decide who can authorise activation of the emergency mechanism, where authentication methods are kept, how a multi-site team can access them if a building is unavailable and what evidence is retained. The securing identities with Microsoft Entra must incorporate this continuity from the outset, rather than adding it after a lockout.

In which scenarios should this account work?

The right model starts with concrete failure scenarios and genuinely independent dependencies.

First scenario: federation or the local directory is unavailable. An account synchronised from Active Directory may then be unusable precisely when the cloud configuration needs to be changed. A cloud-only account reduces this dependency. Second scenario: the usual MFA method becomes unavailable, for example due to a mobile outage, a third-party service failure or lost smartphones. The emergency mechanism must not share the same failure mode.

Third scenario: a Conditional Access policy accidentally blocks all administrators. A rule requiring a compliant device, a named location or a misdeployed authentication strength can create a collective lockout. Fourth scenario: all holders of privileged roles must activate PIM, but no active approver remains available. Fifth scenario: a cyber incident requires sessions to be revoked or a configuration to be corrected while the normal accounts are suspected of being compromised.

Turn each scenario into an acceptance test: from which device should you sign in, with which key, through which internet connection and to perform which minimum action? Avoid vague scenarios such as “Microsoft outage”. The aim is to identify common dependencies: the same phone, the same digital vault, the same identity provider, the same network, the same person or the same building. An emergency architecture is only resilient if it can withstand at least one plausible failure of each of these elements.

How do you design a reliable emergency architecture?

Create two separate cloud-only accounts, separate their authentication methods and document a minimal usage path.

Assign each account a non-personal and non-obvious identity, record its object ID in the security register and place it in a dedicated group for controlled exclusions. Microsoft requires the Global Administrator role to remain permanently active for these accounts, unlike ordinary human accounts, which benefit from using PIM and least privilege. This exception must remain limited to these emergency identities.

Use a phishing-resistant method. Microsoft recommends FIDO2 passkeys and accepts certificate-based authentication where a sufficiently independent PKI exists. A hardware key is not a magic solution: each key must be registered, labelled, sealed, stored and tested. Provide a primary key and a backup copy without linking the account to an employee’s personal phone. Also check that there is no expiry or automatic clean-up due to inactivity.

Reserve a secure administration workstation or an equivalent environment. The browser, extensions, signed-in accounts and network must be controlled. The workstation must not become a shared computer used for everyday work. Define the minimum permitted action: restore a policy, activate a named administrator, revoke a compromise or restore an approval chain. Afterwards, the user leaves the emergency account and continues under a traceable named identity.

Normal account, PIM or emergency account: what is the difference?

These three mechanisms are complementary: the human account handles day-to-day work, PIM limits the duration of privilege and the emergency account handles a global lockout.

Confusing these roles leads to two opposite extremes. If the team uses the emergency account to save time, it loses individual attribution, normalises permanent privilege and masks governance issues. Conversely, if it requires the same dependencies as a normal account, the mechanism may be blocked along with the rest of the tenant. The table distinguishes the use, control and limitation of each option.

The Microsoft Entra RBAC best practices, updated on 1 June 2026, recommend least privilege, PIM for just-in-time access and two cloud-only emergency accounts permanently assigned to the Global Administrator role. The distinction is important: permanent privilege is a continuity exception, not a model to reproduce for all administrators.

How should Conditional Access exclusions be handled?

Exclude emergency accounts from policies that could block sign-in, then compensate for this exception with strong authentication, full monitoring and testing.

An exclusion is not a general pass. It is intended to prevent a compliant device requirement, location requirement, unavailable method or external service from preventing emergency access. Use a dedicated group and explicitly control its membership. Policies in report-only mode do not need this exclusion because they do not prevent sign-in. Document every policy that excludes the group and the reason for the decision.

Account authentication must remain phishing-resistant even without relying on a blocking policy. The Microsoft Entra authentication strengths explain how to distinguish between combinations of methods. In the emergency setup, protection comes primarily from controlled possession of the key or certificate, the secure workstation, immediate alerting and the two-person procedure.

Before making any major Conditional Access change, use report-only mode, assessment tools and a phased deployment. Specifically check the emergency accounts before moving the policy into production. After each change, perform a controlled sign-in with at least one account and confirm that the other retains an independent path. An exclusion that has not been retested is an assumption, not a guarantee.

Where should keys, secrets and instructions be stored?

Separate authentication methods, instructions and storage locations so that no single person or failure can control everything.

FIDO2 keys and any recovery codes should be placed in secure, separate physical locations that are accessible to authorised personnel. Microsoft refers to secure, fire-resistant safes in separate locations. For a multi-site organisation, this could mean keeping the primary method at headquarters and a second one at another controlled site. The inventory should record the serial number, associated account, seal, location, custodians and verification date, without exposing any secret in an ordinary ticket.

The procedure must remain available when Microsoft 365, the VPN or the headquarters network is unavailable. A sealed paper copy or an off-site repository outside the main dependency can supplement the governed version. Include the sign-in URL, authorised workstation, method, contacts, authorisation process, permitted actions and return-to-normal plan. Do not include a plaintext password in the same envelope as all the other elements if separation of custody is possible.

How should every use be monitored?

Any sign-in attempt involving the emergency account, whether successful or not, must become a visible event that is acted upon.

Send Entra sign-in logs to the chosen monitoring tool, then create a rule targeting the object IDs of the emergency accounts. The official Microsoft procedure provides an example using Azure Monitor, a query on SigninLogs, a threshold greater than zero and an action group. Microsoft Sentinel or another SIEM can apply the same logic. Also monitor changes to roles, authentication methods, exclusion groups and account status.

The alert must reach several people through a channel that does not rely solely on the affected tenant. At a minimum, it should contain the time, account, result, IP address, known context and test or incident number. Do not include unnecessary sensitive information in an SMS. The on-call person immediately checks whether the use corresponds to a planned exercise, a declared emergency or unauthorised activity.

The deployment of MFA suited to privileged accounts must include monitoring of registered methods and their lifecycle. GVISION can help align authentication, logs, Conditional Access and the operational procedure, without presenting simply possessing a key as a sufficient guarantee.

How can you conduct a quarterly test without creating risk?

Test the complete chain within a prepared window: authorisation, access, alert, benign action, closure and review.

Notify the monitoring team of the exercise without revealing all the details in advance. Check the seal and inventory, retrieve the equipment with two people, and use the secure workstation and designated network. Sign in, confirm receipt of the alert and perform a predefined non-destructive administrative action, such as viewing a setting or validating the ability to access the role page without modifying an assignment.

Check each of the two accounts separately. Success with the first proves nothing about the second. Also test an alternative network path where the plan provides for one. Record the time taken to obtain authorisation, access the equipment, sign in, receive the alert and close the exercise. These measurements are intended to improve the process, not to create a universal SLA. Document any deviation, such as a flat battery, an unrecognised key, an outdated workstation or an obsolete contact.

Microsoft requires validation at least every 90 days and after key changes, including changes within the IT team or subscription changes. At the end, sign out, reseal the equipment, preserve the logs and have the report approved. If the test reveals a serious defect, open a corrective action with an owner and deadline, then perform a targeted retest after the correction.

What evidence should be retained in a Belgian organisation?

Retain proportionate evidence showing that the mechanism exists, remains controlled and has been tested, without turning the article into a certification.

The useful register includes the creation decision, process owners, accounts and object IDs, roles, authentication methods, storage locations, justified exclusions, alerting rules and exercise results. Add authorisation changes, actual incidents and post-mortem actions. Restrict access to this information: security documentation that is too widely distributed can facilitate abuse.

For organisations subject to NIS2, sector-specific requirements, GDPR or ISO 27001, this documentation can support continuity, privileged access control and traceability. It does not by itself prove compliance and does not replace a comprehensive assessment or penetration test. The objective is to produce a verifiable chain of decision and execution: who authorised it, who used it, why, what actions were taken and how the situation was normalised.

Adapt governance to the organisation’s size and actual operating model. A school, non-profit organisation or small firm will need a short procedure and clearly authorised external deputies. A multi-site group or healthcare organisation will need to incorporate on-call arrangements, local roles, out-of-hours availability and critical dependencies. The principle remains the same: an emergency never removes accountability.

Which mistakes make the mechanism dangerous or unusable?

The most common failures stem from a shared dependency, everyday use or an account that has never been tested.

Avoid a single account, a synchronised identity, a method linked to one person’s smartphone, a key kept next to the workstation or a procedure available only in SharePoint. Every unnecessary use increases exposure and undermines the purpose of the mechanism.

Do not create a Conditional Access exclusion without an inventory or monitoring, and never modify both recovery paths simultaneously. A test does not stop at sign-in: the alert, benign action, sign-out, resealing and report collectively prove actual capability.