A Conditional Access change is meant to protect the tenant. But if every administrator is covered by a rule that depends on the same identity provider, device state or authentication method, one mistake or outage can also block the people who need to reverse it.
An emergency access account—often called a break-glass account—is a deliberately separate administrative route for that exceptional situation. It is not a spare everyday admin login. This guide explains what a UAE business should have its Microsoft 365 administrator verify, using Microsoft guidance checked on 12 October 2026.
Start with the failure the account must survive
Write down the situations in which normal administration might become unavailable. Examples include a misconfigured Conditional Access policy, failure of a federated identity service, loss of the usual administrator's authentication device, or an outage affecting the normal strong-authentication method.
The emergency route should not inherit the same single point of failure. Microsoft's emergency access account guidance recommends at least two cloud-only accounts using the tenant's .onmicrosoft.com domain, rather than accounts synchronized or federated from an on-premises system. Microsoft also recommends phishing-resistant authentication, such as FIDO2 passkeys or certificate-based authentication, chosen with the route's dependencies in mind.
These are highly privileged accounts. Creating them without secure custody, monitoring and testing replaces one availability risk with an access risk.
Keep emergency access outside blocking policies—carefully
Create a dedicated group for the emergency accounts and exclude that group from Conditional Access policies that could block or restrict sign-in. Check every relevant policy, including newly created rules. A broad exclusion such as “all administrators except…” is easier to audit when the exception is explicit and narrowly populated.
Do not treat the exclusion as a reason to weaken authentication. Microsoft recommends using an authentication method different from normal admin accounts and ensuring the credential does not expire or disappear through automated cleanup. Store credentials and hardware securely, with access available to authorised people even if one office, individual or device is unavailable.
Before changing a live rule, use Microsoft's Conditional Access report-only mode where it applies. Report-only policies are evaluated and recorded in sign-in logs but do not enforce their controls. Review the results for representative users, devices, locations and applications; report-only is evidence for a rollout decision, not a guarantee that every future sign-in will behave identically.
Test a recovery action, not only the password
A green sign-in result is necessary but incomplete. From a designated secure workstation, an authorised tester should confirm that the account can reach the Entra admin centre, inspect the relevant policy and perform a harmless, pre-approved administrative check. Do not change production controls merely to prove privilege.
- Notify the named observers and open the test record.
- Retrieve one emergency credential through the documented custody process.
- Sign in from the approved secure workstation using the independent authentication method.
- Confirm the expected Global Administrator assignment and access to the policy area needed for recovery.
- Sign out, return the credential to secure storage and review the sign-in and audit logs.
- Record the date, tester, result, exception and next review date without recording the secret itself.
Microsoft currently recommends validating emergency access accounts at least every 90 days and monitoring their sign-in and audit activity. An unexpected use should generate an investigation, because normal daily work should not require these identities.
If your tenant has no documented emergency route, ITZ's business cybersecurity service can help scope the account, policy, authentication and monitoring review. Plan Your Emergency Access Review with your tenant type, administrator count and current Conditional Access approach—never send credentials through the form.
Define who may declare an emergency
A short runbook should state who can approve use, who retrieves each credential, which secure workstation to use, what evidence to collect and how to return to normal administration. Keep an offline or independently accessible copy; a runbook stored only inside the unavailable tenant is not useful during a lockout.
For a smaller company, two named senior people might jointly authorise use while an IT administrator performs the recovery. A larger organisation may separate the credential custodian, operator and observer. The exact process should match the organisation's risks and staffing, but no single absent employee should make recovery impossible.
Emergency accounts are not a substitute for separate day-to-day admin accounts, least privilege or prompt employee offboarding. They are one resilience control inside a wider identity administration process.
Review dependencies after every major identity change
Recheck the route when you change domains, federation, authentication methods, device-compliance rules, privileged access tooling or administrator ownership. Confirm that both emergency accounts still have distinct usable credentials and that neither has been swept into a blocking policy.
Do not use the test account to browse email, install applications or perform routine maintenance. Keep its activity rare, expected and reviewable. Also avoid publishing account names or credential locations in a broadly accessible document.
Plan your emergency access review
Tell ITZ whether your identities are cloud-only, synchronized or federated; which Conditional Access controls are active; how administrative credentials are stored; and when the route was last tested. We can discuss a defined review covering account design, policy exclusions, authentication dependencies, monitoring and a practical validation runbook.
