Emergency access guidance

The five scenarios break-glass accounts exist for, including one pure PIM trap.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Emergency access accounts — Microsoft's guidance

Source: Manage emergency access admin accounts

· doc date 2026-06-04 · retrieved 2026-07-28

Read alongside (which is benchmark guidance-led) and

benchmark guidance-vs-microsoft-reconciliation.md for the differences.

Microsoft's security guardrails summary

Their own checklist, essentially verbatim in substance:

• Maintain at least two emergency access accounts for redundancy.
• Use cloud-only accounts on the .onmicrosoft.com domain with no dependency on

federated identity providers.

• Use phishing-resistant authentication methods (FIDO2 security keys or certificate-based

authentication) that are different from your normal admin accounts.

• Ensure credentials and devices don't expire and aren't subject to automated cleanup.
• In PIM, assign Global Administrator as permanent active, not eligible.
• Require a designated secure workstation or Privileged Access Workstation when using

these accounts.

• Store credentials in separate, secure, fireproof locations accessible to authorised

individuals.

• Exclude from Conditional Access policies that block or restrict sign-in.
• Monitor all sign-in and audit log activity with alerts.
• Validate account functionality at least every 90 days.

The five scenarios these accounts exist for

Microsoft names them, and they are useful for justifying the control to a sceptical customer:

1. Accounts are federated and federation is unavailable — cell-network break or IdP

outage. Entra redirects to the IdP and users cannot sign in.

1. Administrators registered through Entra MFA and **all their devices are unavailable, or

the service is** — e.g. a cell network outage where phone call and SMS were the only two

registered methods.

1. The person with the most recent Global Administrator access leaves. Entra prevents the

last GA account being deleted, but does not prevent it being deleted or disabled

on-premises.

1. Natural disaster — mobile or other networks unavailable.
2. **All GA and Privileged Role Administrator assignments are eligible (not active),

activation requires approval, and no approvers are selected** — or all selected approvers

were removed from the directory. Active GAs and Privileged Role Administrators are the

default approvers when none are selected; with none active, **nobody can approve

activation and tenant administration is effectively locked.**

Scenario 5 is a PIM configuration trap that produces total administrative lockout with no

policy misconfiguration involved at all. The agent should test for it whenever a customer

describes a fully-eligible admin model.

Setup sequence

1. Find existing accounts or create new cloud-only users and assign **Global

Administrator**.

1. Choose a passwordless method that satisfies the mandatory MFA requirement:

• Passkey (FIDO2) — recommended
• Certificate-based authentication if a PKI already exists

1. Register credentials for that method.
2. **Verify the accounts are excluded from any Conditional Access policy that blocks or

restricts sign-in.**

1. Store credentials safely.
2. Monitor sign-in and audit logs.
3. Validate regularly.

The report-only nuance — important, and it differs from benchmark guidance

Report-only policies don't block access and don't require an exclusion.

Microsoft scopes the exclusion requirement to policies that block or restrict sign-in.

benchmark guidance states the exclusion requirement against every policy without that qualifier.

Agent position: recommend excluding from all enforcing policies as mandatory, and note

that report-only policies are technically exempt but that excluding them anyway is the safer

operational habit — because a report-only policy is one toggle away from enforcing, and the

exclusion is what protects you at that moment. Present both, recommend the stricter.

Configuration requirements

• Don't associate the accounts with any individual. Store credentials in a known secure

location available to multiple members of the admin team. **Don't connect these accounts

to any employee-supplied device, such as a phone.**

• Microsoft notes an alternative: individual emergency access accounts per administrator,

which promotes accountability and allows remote use. A legitimate trade-off, not a

violation.

• Strong authentication that differs from normal admin accounts. Microsoft's example: if

normal admin accounts use Microsoft Authenticator, use a FIDO2 security key for the

emergency accounts. Explicitly: consider the *dependencies of the various authentication

methods* to avoid adding external requirements to the authentication process.

• The device or credential must not expire or fall into automated cleanup for lack of use.

This is a real failure — an unused credential silently aged out is discovered only during

the incident.

• In PIM, permanent active, not eligible.
• Use a Privileged Access Workstation or equivalent secure client environment when

interacting with these accounts.

Federation guidance

Keep the emergency access for on-premises systems and the emergency access for cloud

services distinct, with no dependency of one on the other.

Mastering or sourcing authentication for emergency-access accounts from other systems adds

unnecessary risk if those systems have an outage.

Conditional Access considerations

• Create a dedicated security group for the accounts — Microsoft's suggested name is

EmergencyAccess — and exclude that group from policies that block or restrict sign-in.

• **Regularly test — for example every quarter — that the accounts can sign in successfully

under the current Conditional Access configuration.**

• Create contingency Conditional Access policies that can be enabled during an outage to

restore access for critical users (see 04-resilience-and-contingency.md).

Monitoring with Azure Monitor

Microsoft's documented route where Defender for Cloud Apps is not in play. Prerequisite:

send Entra sign-in logs to Azure Monitor.

1. Get the Object ID of each emergency access account (Entra ID → Users → account).
2. Create an alert rule in Azure Monitor scoped to the Log Analytics workspace:

• Signal: Custom log search, query type Aggregated logs
• Threshold Static, operator Greater than, value 0
• Severity 0 – Critical
• Enable upon creation

1. Attach an action group with email/SMS/push/voice notification.

Sample KQL:

// Single account
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

// Multiple accounts
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

// By UPN
SigninLogs
| where UserPrincipalName == "user@yourdomain.onmicrosoft.com"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Add another or UserId == "ObjectGuid" per additional account.

Post-mortem after any use

Preserve logs from Entra and other workloads, then determine whether the use was:

• a planned drill to validate suitability,
• a genuine emergency where no administrator could use their regular account, or
• misuse or unauthorised usage.

Then examine the logs to establish what actions were taken and whether they align with

authorised use.

Validation drill — Microsoft's checklist

Perform at least every 90 days, and additionally when IT staff change (termination or

role change) or when the organisation's Microsoft Entra subscriptions change.

• Ensure security-monitoring staff know the check is happening.
• Review and update the list of individuals authorised to use the credentials.
• Ensure the break-glass process is documented and current.
• Ensure administrators and security officers who might act in an emergency are trained.
• Validate the accounts can sign in and perform administrative tasks.
• Ensure users didn't register MFA or SSPR to any individual's device or personal details.
• If registered to a device, ensure that device is **accessible to all administrators who

might need it, and that it can communicate over at least two network paths that don't

share a common failure mode** — e.g. facility wireless and a cell provider.

• Change safe combinations regularly and after anyone with access leaves.

The two-network-paths requirement is the sharpest detail here and almost never implemented.

Auditability and compliance

For regulated organisations, the monitoring and validation practices support auditability:

sign-in and audit log monitoring with alerts on every use; post-mortem review after any use;

validation drills at least every 90 days including review of the authorised-user list. For

HIPAA, Microsoft publishes guidance mapping emergency access accounts to HIPAA emergency

access procedure requirements.