Two emergency access accounts have been defined

Conditional Access misconfigurations, an MFA service outage or a lost phone can lock every administrator out at once. Without a way in you wait on a support case while the tenant stays broken. Emergency accounts are the planned answer to that day.

Microsoft documents the pattern in Manage emergency access accounts in Microsoft Entra ID, including why the accounts should be cloud-only, use the tenant's own onmicrosoft.com domain and be excluded from at least some policies. This is a manual check: the dataset marks it Manual, because an account is only an emergency account by intent, which a script cannot read.

In the Microsoft Entra admin center open Identity > Roles & admins > Global Administrator and review the assigned users. Look for two accounts that are clearly named for the purpose, use the onmicrosoft.com domain and are not tied to a person. Then open Protection > Conditional Access > Policies and confirm the accounts are handled deliberately in each policy (excluded, or covered by a phishing-resistant method).

Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All"
$role = Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'"
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id -All | ForEach-Object {
  Get-MgUser -UserId $_.Id -Property DisplayName,UserPrincipalName,OnPremisesSyncEnabled,AccountEnabled
} | Select-Object DisplayName,UserPrincipalName,OnPremisesSyncEnabled,AccountEnabled

This only lists candidates. You decide whether two of them really are emergency accounts.

1. Create two cloud-only users on the onmicrosoft.com domain with non-obvious names that do not reveal their role.
2. Give each a long random password, store the two halves in separate secure locations such as a safe, and do not tie the account to a person's phone.
3. Assign the Global Administrator role permanently to both (an eligible-only assignment would defeat the purpose).
4. Register a phishing-resistant method, for example a FIDO2 security key, and keep it with the password.
5. Decide your Conditional Access handling and document it. Many tenants exclude these two accounts from every policy except one that requires a phishing-resistant method.
6. Create an alert on any sign-in by either account, and test the sign-in on a schedule you set.

Follow the full steps in Microsoft's guide. ConfigCobra itself never changes your tenant; it reports the gap and you create the accounts.

Day to day, nothing changes for users: the accounts are never used for normal work. For administrators, you take on two duties: protecting the credentials and responding when the alert fires. Because the accounts sit outside normal policy, any sign-in that is not a test should be treated as a possible incident. After creation, review the accounts whenever you change Conditional Access, so a new policy does not lock them out by accident.