Set up break-glass accounts with a sign-in alert

Use the tenant's .onmicrosoft.com domain so the accounts don't depend on your custom domain, federation or on-premises sync. Give them names that don't advertise what they are, and generate a long random password for each.

Connect-MgGraph -Scopes "User.ReadWrite.All","RoleManagement.ReadWrite.Directory"
$domain = (Get-MgDomain | Where-Object IsInitial).Id
$pw = @{ Password = "<long random password>"; ForceChangePasswordNextSignIn = $false }
$ea1 = New-MgUser -DisplayName "EA 01" -UserPrincipalName "ea01@$domain" -MailNickname "ea01" -AccountEnabled -PasswordProfile $pw
# Run again with a different password for ea02

Don't license these accounts or give them a mailbox. They exist only to sign in when nothing else works.

Emergency accounts should hold an active, permanent assignment, not an eligible one in PIM, because PIM activation is one more thing that could fail during an outage. The ID below is the built-in Global Administrator role template.

New-MgRoleManagementDirectoryRoleAssignment -PrincipalId $ea1.Id `
  -RoleDefinitionId "62e90394-69f5-4237-9190-012177145e10" -DirectoryScopeId "/"

Mandatory MFA for Azure and admin portals applies to these accounts too, so they need a method that works without a phone. First check that Passkey (FIDO2) is enabled for these accounts in Entra admin center → Authentication methods → Policies. Then sign in as each account in a private browser window, go to https://aka.ms/mysecurityinfo and register a FIDO2 security key. Register a second key per account if you can, and store the keys in separate secure locations, such as two different safes.

Split the password: write it down in two halves, held by different people, or keep it in a vault that isn't itself protected by Entra ID.

In Entra admin center → Conditional Access → Policies, add both accounts (or a group containing just them) to the exclusions of each policy. Microsoft's guidance is to exclude emergency access accounts from every policy that blocks or restricts sign-in, so that a bad policy can't lock everyone out. The passkeys you registered are what protect them. Report-only policies don't need the exclusion, but adding it anyway means you won't forget when you switch them on.

Create a Log Analytics workspace if you don't have one. Then in Entra admin center → Monitoring & health → Diagnostic settings, add a setting that sends SignInLogs, NonInteractiveUserSignInLogs and AuditLogs to the workspace. Logs usually start arriving within 15 minutes.

In the Azure portal, open the workspace, select Logs and run this query with your two accounts' object IDs, which keep working even if an account is renamed. Then select New alert rule.

SigninLogs
| where UserId in ("<object ID of ea01>", "<object ID of ea02>")
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, ResultType, ResultDescription

Set the measure to Table rows, aggregation granularity and frequency of evaluation to 5 minutes, and the threshold to greater than 0. Create an action group that emails and texts at least two people, and give the rule a high severity. The rule should fire on failed attempts too, since those are worth knowing about.

Sign in as one of the accounts, check that you can reach the Entra admin center, and sign out. Within about 10 to 15 minutes you should get the email and text. If not, check that the sign-in appears in the SigninLogs table, then check the alert rule's history.

Record where the keys and password halves are, who holds them, and the steps to use them. Put a recurring reminder in the calendar, every three months or so, to sign in with each account, confirm the alert fires, and confirm the accounts are still excluded from new Conditional Access policies.