Unit 9: Create and manage emergency access accounts

Organizations must plan for worst-case scenarios where normal administrative access to Microsoft Entra ID is unavailable. Microsoft Entra ID does not allow administrators to sign in as another user or elevate another account if all admins are locked out.

To prevent permanent lockout, Microsoft strongly recommends creating emergency access accounts, also called break-glass accounts.

Emergency access accounts are highly privileged cloud-only accounts that are used only during emergencies when standard administrative access fails.

What is an emergency access account?

An emergency access account is:

• A cloud-only Microsoft Entra ID account.
• Permanently assigned the Global Administrator role.
• Not associated with any single person.
• Excluded from normal access controls that could block emergency access.

These accounts exist solely to recover tenant access during critical outages or failures.

Why emergency access accounts are required

Organizations may need emergency access accounts in scenarios such as:

• Federation failure
• On-premises identity provider (AD FS or similar) is unavailable.
• Users cannot sign in because authentication redirects fail.
• Multifactor Authentication (MFA) outage
• All administrators rely on MFA.
• Phones, hardware tokens, or MFA services are unavailable.
• Loss of last Global Administrator
• The last GA leaves the organization.
• Account is disabled or deleted on-premises.
• Microsoft Entra ID prevents deleting the last GA but cannot prevent upstream failures.
• Major outages or disasters
• Natural disasters.
• Network or cellular service outages.
• Physical access to devices is unavailable.

Emergency access accounts ensure tenant recoverability in all these cases.

How many emergency access accounts should you create?

Microsoft recommends:

• At least two emergency access accounts

This reduces risk if:

• One credential is lost.
• One account is compromised.
• One authentication method fails.

Requirements for emergency access accounts

Emergency access accounts must meet strict design rules.

Account type requirements

• Cloud-only accounts.
• Use the .onmicrosoft.com domain.
• Not federated.
• Not synchronized from on-premises Active Directory.

Identity and ownership requirements

Emergency access accounts:

• Must not be tied to a specific individual.
• Must not use:
• Employee phone numbers.
• Personal email addresses.
• Employee-owned hardware tokens.

Any devices or credentials:

• Must be stored in secure, shared locations.
• Must be accessible to authorized staff during emergencies.

Authentication requirements

The authentication method must:

• Be different from normal administrator authentication.
• Not depend on the same failure path as standard admin accounts.

Examples:

• If admins normally use phone-based MFA, emergency accounts should not.
• If admins rely on Entra MFA, consider alternate mechanisms.

Role assignment requirements

• Emergency access accounts must have:
• Permanent Global Administrator role assignment.
• These accounts must not require PIM activation.

This ensures immediate access during emergencies.

MFA and Conditional Access exclusions

Exclude at least one account from phone-based MFA

While MFA is strongly recommended for all users:

• At least one emergency account must not depend on the same MFA method as other admins.

Important rules:

• Exclude emergency accounts from:
• Per-user MFA policies.
• Phone-based MFA enforcement.
• Use an alternate authentication approach if possible.

Exclude at least one account from Conditional Access policies

Conditional Access policies can:

• Block sign-ins.
• Require compliant devices.
• Enforce network location restrictions.

At least one emergency access account must:

• Be excluded from all Conditional Access policies.

This ensures no policy blocks emergency access.

Federation considerations

For organizations using:

• Active Directory Domain Services.
• AD FS or other federated identity providers.

You may:

• Use certificate-based authentication via federation.
• Have the identity provider assert MFA claims.

However:

• Federated emergency access is not sufficient alone.
• You must still maintain cloud-only emergency access accounts in case federation fails entirely.

Monitoring emergency access account usage

Emergency access accounts should be:

• Rarely used
• Heavily monitored

Recommended actions:

• Monitor sign-in logs.
• Monitor audit logs.
• Trigger alerts when emergency accounts sign in.

Use:

• Azure Log Analytics.
• Alerts via email or SMS to security administrators.

This ensures:

• Immediate awareness of account usage.
• Verification that access was legitimate.

Regular validation and testing

Emergency access accounts must be tested regularly, not only during real emergencies.

Validation checklist

Perform the following regularly:

• Confirm security teams are aware of testing activity.
• Verify emergency procedures are documented and current.
• Train administrators on how and when to use emergency accounts.
• Rotate credentials securely.
• Test sign-in and administrative access.
• Ensure no MFA or SSPR is registered to personal devices.
• Verify shared devices are accessible and functional.
• Confirm multiple network paths exist.

When to validate emergency access accounts

Validation should occur:

• At least every 90 days
• After IT staff changes (joiners, leavers, role changes)
• After subscription or tenant configuration changes

Exam-focused summary

• Emergency access accounts prevent tenant lockout.
• Create at least two cloud-only accounts.
• Use .onmicrosoft.com domain.
• Assign permanent Global Administrator role.
• Exclude from Conditional Access and standard MFA.
• Do not associate with individuals.
• Monitor sign-ins and audit logs.
• Test and validate accounts regularly.