Test an Entra emergency-access account before the real emergency

An emergency-access account is not an administrator's spare daily login. It is a recovery control for the moment when normal administrators cannot sign in, activate a role or satisfy an authentication requirement. If it is untested, tied to one person's phone, or silently included in a restrictive Conditional Access policy, it is not a recovery control at all.

This lab is for an authorised Microsoft Entra tenant. It tests the emergency path without changing production Conditional Access policies and without turning the account into routine admin access. Carry it out from a designated secure workstation during an agreed maintenance window.

What you need before the test

How to verify it: To carry this out, open Microsoft Entra admin center → Entra ID → Conditional Access → Policies → [exact policy name] and compare the relevant Assignments, Grant or Enable policy section with the change record; the expected result is the documented scope and state. Remove an incorrect unsaved selection with X, then choose Done or Cancel; the production rollback is Report-only followed by Save, then sign-in-log validation.

Locate the exact emergency objects

Go to Microsoft Entra admin center → Entra ID → Users → All users. Search for the approved emergency account's user principal name, select the matching user, and open Overview. Copy the displayed Object ID into the protected change record and compare it with the account register. Expected result: the UPN, display name, account type and Object ID identify one cloud-only account. Validate the source of authority: the user should not be an unexpected synchronised identity if the emergency design requires cloud-only recovery. To leave safely, use the breadcrumb back to All users; this view is read-only.

For membership validation, on the same user choose Groups, confirm membership in the dedicated emergency-access group, and select that group to inspect its Overview → Object ID. The expected result is the exact approved user and group IDs, not merely similar display names. If a membership is wrong, do not improvise removal during a live recovery test: record the discrepancy and follow the approved identity-change procedure. If an authorised correction is required, reverse it by reopening Users → [account] → Groups, removing only the documented membership, and confirming the result in the account overview.

Have at least two cloud-only emergency accounts using the tenant's .onmicrosoft.com domain. Microsoft recommends two or more accounts with permanently active Global Administrator assignments. They should not be synchronised from on-premises Active Directory or depend on a federated identity provider.

Before testing, identify:

• the named owner of the test and the person authorising it;
• the secured location of the authentication credential;
• the approved secure workstation;
• the emergency group excluded from blocking Conditional Access policies;
• the alert recipient for any emergency-account sign-in;
• the time limit for the test. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

Do not paste passwords, recovery codes or FIDO registration data into a ticket. If the account uses a FIDO2 key, collect it through the documented custody process and return it immediately after the test.

Confirm the policy boundary first

How to verify it: To carry this out, open Microsoft Entra admin center → Entra ID → Conditional Access → Policies → [exact policy name] and compare the relevant Assignments, Grant or Enable policy section with the change record; the expected result is the documented scope and state. Remove an incorrect unsaved selection with X, then choose Done or Cancel; the production rollback is Report-only followed by Save, then sign-in-log validation.

Confirm Conditional Access exclusion without relying on assumption

Go to Entra ID → Conditional Access → Policies, open each policy that can restrict administrators, then inspect Assignments → Users or workload identities → Exclude. Expected result: only the approved emergency group/accounts are excluded; report-only policies may not need an exclusion because they do not enforce. Validate by comparing Object IDs from the user/group lookup rather than trusting a copied display name. If the wrong object is excluded, remove it in the policy assignment, select Done, retain Report-only while reviewing, then Save. Do not broaden an exclusion to a department as a quick fix.

During the authorised test, sign in from the designated secure workstation and then go to Entra ID → Monitoring & health → Sign-in logs. Filter on the emergency UPN and test time, select the event, then choose Conditional Access. Expected result: the record shows which policies were evaluated and the emergency account's documented exclusion where applicable. Validate the correlation ID, resource and sign-in outcome in the test record. If the expected exclusion is absent or an unexpected policy applies, sign out, stop routine changes, and use the pre-approved recovery operator; do not repeatedly test credentials. Closing the detail pane or clearing the log filter changes no configuration.

In the Entra admin centre, review every Conditional Access policy that targets all users, privileged roles or administrative cloud applications. Confirm that the dedicated emergency-access group is excluded from policies that block or restrict sign-in. A report-only policy does not block the account and needs no exclusion.

Check the exclusion by group, not by memory. An individual-user exclusion can disappear when an account is replaced; a small documented group is easier to review. The group must contain only the emergency accounts. Adding normal administrators defeats the control.

A healthy result is a clear list of blocking policies with the emergency group excluded. A bad result is an account included in a policy requiring a compliant device, normal MFA method or a location condition that could fail during an incident. Stop and correct the policy before sign-in testing. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

Run the sign-in test

Safe test closure and rollback

After a successful test, sign out of the emergency browser session, return the physical credential to its documented custody location, and log the UTC time, operator, correlation ID and outcome. A successful sign-in proves access for that tested path only; it does not prove every Conditional Access policy, credential backup or future device path will work. If the test exposes a policy issue, first roll back the specific restrictive policy through Entra ID → Conditional Access → Policies → [policy] → Enable policy → Report-only → Save, then validate recovery in the sign-in log. Keep the policy for evidence and repair; do not delete it.

Test the account on the approved schedule, commonly at least every 90 days, and alert on its use. The goal is a recoverable administrative route, not a convenient daily bypass. Normal administration must remain within ordinary Conditional Access protections.

Use a private browser session on the designated workstation. Sign in as one emergency account to the Entra admin centre. Perform only these minimal checks:

1. Confirm the account can complete its intended authentication method.
2. Confirm access to the Entra overview and directory roles view.
3. Confirm the Global Administrator assignment is active, not merely eligible.
4. Open the sign-in log entry for the test.
5. Sign out completely. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

Do not create users, alter policies or access unrelated workloads merely to prove that Global Administrator is powerful. The test is about availability and observability, not about demonstrating blast radius.

Expected result: the account signs in from the approved workstation, the role is active, and the sign-in log identifies the account, time, IP or network context, authentication method and Conditional Access evaluation.

Suspicious result: a policy blocks sign-in; the role is eligible but cannot be activated; the account requires a personal device; or the log is missing. Treat any of these as a failed recovery test. Do not work around the failure by permanently weakening a broad policy. Restore the intended emergency design, then re-test.

Check monitoring while the evidence is fresh

Every emergency-account sign-in should create an alert for the security or identity team. During this test, verify both the Entra sign-in log and the downstream alert route. Record:

• account identifier;
• UTC and local test time;
• correlation ID;
• authentication method;
• evaluated Conditional Access policies;
• alert ticket or notification reference;
• tester and approver;
• pass/fail result.

The absence of an alert does not mean the account is safe; it means a high-value event is not being watched. Correct monitoring before accepting the control.

Test independence, not just success

How to verify it: To carry this out, open Microsoft Entra admin center → Entra ID → Conditional Access → Policies → [exact policy name] and compare the relevant Assignments, Grant or Enable policy section with the change record; the expected result is the documented scope and state. Remove an incorrect unsaved selection with X, then choose Done or Cancel; the production rollback is Report-only followed by Save, then sign-in-log validation.

A sign-in that works on the office network with a familiar browser does not prove resilience. Review whether the normal administrators and emergency account share a dependency:

• the same federation service;
• the same mobile device or telecom provider;
• the same password vault availability path;
• the same conditional-access device requirement;
• the same physical location for all credentials.

Emergency credentials should be held in secure, separate locations accessible to authorised staff. If the organisation uses passkeys or hardware keys, ensure the key does not expire or become subject to automated cleanup. Microsoft also recommends that the emergency account's strong authentication method differs from normal administrator methods where possible.

Quarterly schedule and exit criteria

Perform this test at least every 90 days, and after relevant staff, subscription or Conditional Access changes. Rotate custody access when an authorised person leaves. A test can be brief; repeatability matters more than drama. To carry this out, open Microsoft Entra admin center → Entra ID → Conditional Access → Policies → [exact policy name] and compare the relevant Assignments, Grant or Enable policy section with the change record; the expected result is the documented scope and state. Remove an incorrect unsaved selection with X, then choose Done or Cancel; the production rollback is Report-only followed by Save, then sign-in-log validation.

The control is complete when:

• two cloud-only emergency accounts are available;
• each is excluded only from the blocking policies necessary for recovery;
• an authorised sign-in succeeds from the secure workstation;
• the role is active and observable;
• sign-in and audit monitoring alerts;
• credentials are returned to their documented secure locations;
• the result is recorded with a next test date.

For the next change, test a new Conditional Access policy in report-only mode with ordinary pilot users. Emergency access is the guardrail, not the pilot population.

A test that finds the awkward dependency

Take a tenant where normal administrators use Microsoft Authenticator on managed phones. The emergency account uses a FIDO2 key held in a separate safe. A quarterly test starts from a privileged workstation, not the administrator's usual laptop. The tester signs in, opens the directory roles page, checks that the role is active, opens the sign-in record, then signs out. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

That small sequence answers four different questions. The key works; the account is not accidentally federated; the permanent role is usable; and the sign-in is visible to monitoring. It does not prove that every admin control is safe, so avoid changing policies or creating users just to show that Global Administrator has power.

Example: the account works, but the control fails

A believable failure is more useful than a ceremonial success. Suppose sign-in succeeds, but no alert arrives. The identity team later finds that alerting was filtered on a normal administrator group and the emergency account was not included. The account can still rescue access, but its use may go unnoticed.

Record the correlation ID from the sign-in log, add the emergency-account monitoring rule, and re-run only the alert part of the test. A successful re-test includes a log event and an alert reference. Do not declare success merely because the browser opened the admin centre.

Another common failure is a Conditional Access policy requiring a compliant device. If the emergency account is in scope, do not solve this by excluding all administrators. Confirm the dedicated EmergencyAccess group exclusion, preserve the narrow policy scope, and retest from the authorised secure workstation.

What the test record should contain

A practical stop rule

Stop the test and escalate if sign-in requires an undocumented recovery action, a personal telephone, a normal administrator's help, or a broad policy exception. Those are dependencies the emergency path is supposed to avoid. Preserve the sign-in evidence first; then fix one dependency at a time and schedule a new test. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

A controlled recovery exercise

A quarterly emergency-access test is a controlled recovery exercise, not an invitation to discover the full blast radius of Global Administrator before coffee. Use only an authorised tenant, an agreed secure workstation, a named tester and an approver who knows the opening and closing time. Prove that the recovery path reaches the administration plane; do not reset ordinary users, alter policies or read unrelated workloads merely because the account can. To carry this out, open Microsoft Entra admin center → Entra ID → Users → All users, search for the approved UPN, select only the matching Object ID and check Overview; if the role must be confirmed, continue to Entra ID → Roles & admins → Global Administrator → Assignments. The expected result is an object matching the register and an active assignment; clearing Search or closing the pane safely reverts the view, but stop the test if they do not match.

Open a change record before beginning. Record aliases, not passwords; the two custody roles; workstation asset name; planned UTC and local time; alert destination; and a maximum duration. This record lets a different authorised administrator understand the test after staff turnover, when institutional knowledge has usually been archived beside the obsolete VPN diagram.

Reader check-point: can an independent authorised administrator find the custody procedure and alert owner without asking the normal tenant administrator? If not, the test has already found an operational dependency. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

Use a clean sign-in path

Start a private browser window or dedicated browser profile and clear every existing Entra session. A successful page visit is meaningless if the browser silently continues a normal administrator session. Browse directly to the Entra administration portal and sign in only as the nominated emergency account. Use the documented hardware key or other protected method; never register a personal phone, add a convenient authenticator, or create an alternate method during the test. Convenience is often an undocumented recovery path with better branding. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

Confirm only the minimum: authentication completes, Entra overview opens, the directory role is active, the sign-in appears in logs, and sign-out completes. A permanently active Global Administrator assignment is the common emergency design because an eligible role may require approval or an authentication step that is unavailable during an outage. The role should be cloud-only and use the tenant onmicrosoft.com domain, not federation or on-premises synchronisation.

Collect evidence from Entra logs

Before and after sign-in, open Identity, Monitoring and health, Sign-in logs, filter on the emergency account and keep the time range tight. Record the event time, correlation ID, client application, network context, authentication detail and Conditional Access result. A healthy event has the expected account and a success result. An unfamiliar location, client, failure code or missing event is not a reason to keep trying; preserve the details, sign out and investigate.

For a repeatable read-only collection, run the following on an administrator-controlled Windows PowerShell session with Microsoft Graph PowerShell installed and a consented AuditLog.Read.All scope. It changes no tenant configuration.

Connect-MgGraph -Scopes 'AuditLog.Read.All'
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'breakglass1@contoso.onmicrosoft.com'" -Top 20 |
 Select-Object CreatedDateTime,AppDisplayName,Status,ConditionalAccessStatus,CorrelationId,IPAddress,ClientAppUsed

A useful result is a recent successful row and a correlation ID matching the portal. An empty result can mean retention, permission, delay or a filter mistake; it does not prove that the sign-in never happened. Check the portal before changing monitoring or declaring victory. The command also does not prove that every Conditional Access policy is correct; it proves only that an authorised reader can see this event.

Check identity independence

Inspect the account in the portal and confirm it is enabled, cloud-only and not synchronised. With User.Read.All and RoleManagement.Read.Directory, the following is a read-only confirmation from Graph PowerShell.

Connect-MgGraph -Scopes 'User.Read.All','RoleManagement.Read.Directory'
Get-MgUser -UserId 'breakglass1@contoso.onmicrosoft.com' -Property DisplayName,UserPrincipalName,OnPremisesSyncEnabled,AccountEnabled |
 Select-Object DisplayName,UserPrincipalName,OnPremisesSyncEnabled,AccountEnabled

The expected result is AccountEnabled True and OnPremisesSyncEnabled False. Resolve the directory role in the portal rather than treating a role-definition identifier as a human-readable answer. If the account is synchronised, federated, disabled or merely eligible, label the recovery design incomplete. Correct it under change control, not in the middle of a test.

Review Conditional Access narrowly

List policies that target all users, privileged roles or administrative applications, then inspect assignments and exclusions one by one. The dedicated emergency group should be excluded only from controls that could block recovery. A report-only policy does not block a sign-in, so it is evidence for a future rollout rather than an availability requirement. Use the What If tool to model a user, application, device platform and network condition, then use a real sign-in for proof.

Do not exclude every administrator because one test is awkward. Do not place everyday administrators in the emergency group. Both changes solve an immediate checkbox problem by enlarging a bypass that will age badly. For each exclusion record policy name, blocking control, account group, owner and reason. If the reason is simply that a previous administrator said it was necessary, it is a review task, not an architecture decision.

Prove monitoring reaches a human

Every emergency-account sign-in should make an appropriate monitoring route visible. Coordinate the test window with the identity or security owner without providing credentials. After sign-in, verify the Entra log first, then verify the downstream alert, incident or notification. Record its reference in the change record.

Where Entra sign-in logs are sent to Microsoft Sentinel, this read-only Kusto query can provide independent evidence.

SigninLogs
| where TimeGenerated > ago(2h)
| where UserPrincipalName =~ 'breakglass1@contoso.onmicrosoft.com'
| project TimeGenerated,UserPrincipalName,AppDisplayName,ResultType,ConditionalAccessStatus,CorrelationId,IPAddress
| order by TimeGenerated desc

A good result matches the portal event. No result may indicate connector delay, retention, a different table or a broken ingestion route; it does not justify more emergency logins. If the portal contains the event but no alert arrives within the documented interval, record a monitoring failure and repair that route separately. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

Avoid shared failure modes

Test two accounts but do not let them share one phone, one hardware key, one vault procedure, one custodian or one federated dependency. Account A might use a FIDO2 key in one controlled location; account B needs a separately controlled method and a different authorised custodian. The point is not variety for its own sake. It is avoiding a single unavailable person, device or building becoming the tenant's most powerful outage. To carry this out, open Microsoft Entra admin center → Entra ID → Users → All users, search for the approved UPN, select only the matching Object ID and check Overview; if the role must be confirmed, continue to Entra ID → Roles & admins → Global Administrator → Assignments. The expected result is an object matching the register and an active assignment; clearing Search or closing the pane safely reverts the view, but stop the test if they do not match.

A useful review asks five questions: are both accounts cloud-only; are credentials independent; can separate authorised roles obtain them; are exclusions documented and narrow; and has the alert route been tested for each account? If either account has become a routine spare administrator login, review its activity and credential path. Frequent ordinary use makes emergency events less exceptional and leaves more session residue than anyone enjoys finding during an incident.

Stop rules rollback and closure

Stop the test if sign-in is unexpectedly blocked, a credential is missing, an unfamiliar sign-in appears, an unintended workload is reached, or progress requires a broad policy exception. Preserve the correlation ID and exact policy name, sign out and notify the accountable identity owner. Do not disable Conditional Access wholesale. That is rollback by demolition.

If a new policy blocks recovery, use a separate authorised recovery route to change only the policy scope or the documented exclusion. Capture the prior configuration and remediation, then re-test with report-only evaluation or a small pilot before enforcement. If no legitimate recovery route exists, follow the incident process rather than improvising account recovery in chat.

Completion means more than a browser opened: two independent cloud-only accounts are available; intended permanent access and narrow exclusions are known; Entra and monitoring evidence agree; credentials have returned to custody; and the next test date is assigned. The next operational task is to test risky Conditional Access changes with ordinary pilot users. Emergency accounts are guardrails, not crash-test dummies.

Make the procedure repeatable rather than heroic

A recovery test becomes dependable when the same small decisions are recorded every time. Before the next scheduled exercise, review the previous record with the identity owner: who held custody, what browser and network were used, which alert was expected, what evidence was retained and which correction remained open. The review should distinguish a passing login from a passing control. A login can pass while the alert is absent, the account depends on federation, the second account shares the same key, or the role cannot be activated without an unavailable person. Those are different failures with different owners.

Use a simple sequence: announce the window, obtain the authorised credential through the custody procedure, start a fresh private session, authenticate, open only the agreed administrative views, collect the sign-in correlation ID, wait for the alert, sign out, return the credential and record the outcome. Each action should have an observer or artefact. The record is not bureaucracy for its own sake; it is how the organisation proves that its last-resort access does not rely on optimism and a remembered telephone number.

Check the time boundary as well. A key that works in a familiar office during business hours may still reveal a reliance on local access, a locked cabinet process or a single custodian. Do not simulate a crisis by bypassing physical controls. Instead, ask whether the documented authorised route would work when the normal administrator is unavailable. Where the answer is unclear, create a specific improvement task with an owner and date.

Interpret common outcomes carefully

A success event in Entra confirms that the account completed that observed sign-in. It does not prove that every application will remain accessible, that every policy is safe, or that the account is safe from misuse. A Conditional Access result of notApplied can be expected for a narrowly excluded emergency account, but it should make the reader ask which policies were bypassed and whether the exception is still necessary. An unexpected success through a normal device-compliance rule can indicate that the browser still had a session or that the policy did not target the test as assumed. To carry this out, open Microsoft Entra admin center → Entra ID → Monitoring & health → Sign-in logs, use Add filters with the exact UPN and time window, open the event and select Conditional Access; the expected result is a correlation ID and policy outcome to compare with the test record. Clear filters or closing the details pane safely reverts only the view and changes nothing.

A failure caused by an authentication method should be classified before fixing it. Missing hardware, an expired or unregistered method, a PIN issue and a policy requirement are separate causes. Capture the error code and the authentication details. Do not add a personal SMS method because it makes the error disappear; that changes the recovery design and may add a dependency on a phone, number or person that was never approved.

An alert arriving without a matching log event is also suspicious. Confirm the account address and time zone, then check whether an earlier test event was delivered late. Alert systems have delay and suppression behaviour, and an alert can be technically present while routed to an unattended queue. Record the complete path: source log, analytics rule or workflow, destination and acknowledgement. The desired outcome is a responsible team noticing emergency access in time to validate or investigate it.

Containment when the account looks wrong

If a test reveals an unexpected device, location or application, do not treat the planned window as proof that the event was harmless. End the test, retain correlation IDs and timestamps, and notify the identity or incident owner. They can determine whether the event belongs to the planned activity or represents a separate sign-in. Avoid password resets, credential deletion or policy changes until evidence has been preserved and a responsible owner decides the response. Emergency accounts are high-value identities; casual remediation can remove the very access needed to contain a wider problem.

If compromise is suspected, the priority is controlled containment: determine the account's recent activity, preserve relevant Entra audit and sign-in logs, review role assignments and authentication methods, then rotate or revoke access through the approved incident process. Do not publish the account identity, key serial or recovery location in a ticket visible to broad audiences. The emergency account should remain exceptional even when the paperwork is not.

Evidence and retention

Keep only the evidence needed for the control: date and time, approved participants, account alias or internal reference, correlation ID, evaluated policies, alert reference, result and remediation owner. Protect it as security operational data. Screenshots can be useful where portals do not preserve a convenient export, but redact tenant-specific addresses, network information and unrelated users before sharing outside the authorised team.

Review evidence retention with the organisation's logging and privacy rules. A quarterly test should not create a private archive of privileged activity on an administrator's desktop. Store the record in the approved change, ticketing or evidence system and link the follow-up work there. The practical target is that an auditor or replacement identity owner can confirm the control without learning how to misuse it.

Final reader check-point

Before closing the task, answer these questions plainly. Could two separately authorised people obtain separate emergency credentials? Does each account sign in without on-premises, federation, personal-device or normal-admin dependency? Is the assignment active when it is needed? Can an authorised reviewer find the event and its correlation ID? Did monitoring reach an accountable destination? Were exceptions narrow, reviewed and documented? Were credentials returned and the next exercise scheduled?

A no answer is useful output. It turns a vague concern into a bounded change: remove a synchronisation dependency, repair an alert rule, separate custody, or narrow a policy exclusion. A test that finds a flaw before an incident has done its job. The systems may be indifferent, but the recovery plan should not be.

Turn the test into a recovery control

An emergency-access test should answer a recovery question, not celebrate that a privileged account can open a portal. Use a written test card with a named authoriser, tester, observer, time limit, secure workstation, credential custody reference and pass/fail criteria. The observer records evidence while the tester works; the account password, recovery material and key registration details do not belong in that record. To carry this out, open Microsoft Entra admin center → Entra ID → Users → All users, search for the approved UPN, select only the matching Object ID and check Overview; if the role must be confirmed, continue to Entra ID → Roles & admins → Global Administrator → Assignments. The expected result is an object matching the register and an active assignment; clearing Search or closing the pane safely reverts the view, but stop the test if they do not match.

Before the sign-in, review the account object and its dependencies. It should be cloud-only in the tenant's .onmicrosoft.com domain, have a permanently active Global Administrator assignment where that is the design, and use a credential kept separately from ordinary administrator devices. Check the membership of the emergency-access group and every Conditional Access policy that targets all users, privileged roles or administration portals. The desired result is narrow, documented exclusions from blocking controls, not a blanket “ignore this account” arrangement.

Use a private browser session on the designated workstation. Sign in once, confirm the Entra overview and directory role view, inspect the active assignment, open the sign-in event, and sign out. Record the correlation ID, UTC time, client, network context, authentication method and evaluated Conditional Access policies. A test that succeeds only in a familiar browser profile is not proof of an independent recovery path; it may simply be a token wearing a reassuring hat.

Validate the alert path as well as the login

The event is not fully validated until monitoring sees it. Confirm that the expected identity or security alert reaches a human or monitored queue and that the alert contains enough context to distinguish an authorised exercise from suspicious use. If the sign-in log exists but the alert does not, the account remains valuable but the control is incomplete. Correct the alert rule, run a short authorised re-test, and attach the alert reference to the record.

Test one realistic counterexample. For instance, an emergency account may sign in successfully but be prompted for an ordinary mobile authenticator because its FIDO2 key was not registered correctly. The successful password step does not prove recovery. Stop, return the key through custody, correct the registration using the approved process, and repeat the minimal sign-in test. Do not “solve” it by adding the emergency account to a wide policy exclusion that normal users can inherit.

Another awkward result is a sign-in blocked by a newly added location or compliant-device policy. First identify the exact policy result in the log. If the documented exclusion is missing, restore the narrow exclusion and re-test. If it is present but the account is still blocked, investigate a second policy, group nesting, or a condition that affects the application differently than expected. Preserve evidence before changing scope. A fast rollback without evidence is a very tidy way to schedule the same failure for next quarter.

Containment, rollback and repeatability

If the account appears compromised, has an unknown authentication method, or cannot be accounted for in the custody register, treat that as a security event rather than a laboratory inconvenience. Stop the test, notify the incident owner, revoke or protect the affected credential according to the approved procedure, and do not attempt a creative recovery in the same session. Use the second emergency account only under its documented authorisation path.

A clean rollback from a failed exercise is modest: sign out, close the private session, return the hardware key or sealed credential, confirm that no policy was changed, and record the failed criterion and owner for remediation. If a temporary policy change was explicitly authorised, reverse only that change, verify its previous state in the portal and logs, then record who performed it and when. Emergency access should be boring enough that a tired administrator can repeat it correctly.

A quarterly schedule is a sensible default, plus a test after Conditional Access redesigns, key rotation, changes to federation, privileged-role changes or staff custody changes. Rotate the tester and observer occasionally; a control understood by one person is a dependency, not resilience. Retain concise evidence: test ID, date, accounts tested without secrets, correlation IDs, policy evaluation, alert reference, result, exceptions and next test date.

Independence is the test's difficult claim

The second emergency account must be more than another username in the same drawer. Confirm it has a different credential, documented custody route and usable sign-in path. A pair of accounts dependent on one phone, one person, one federation service or one unmonitored location is a pair of labels attached to the same failure mode. During the exercise, do not sign into the second account merely for symmetry unless the approved test requires it; preserving it as a recovery option is often the safer design.

Review the alert after it fires. The record should identify the event without exposing credential material, reach a named monitored destination, and be actionable outside the original tester's mailbox. A successful sign-in with an alert sitting in an unowned queue is evidence of a monitoring gap, not a pass. The containment decision is simple: stop the drill, retain the sign-in correlation ID, fix the alert path, and retest only the alert validation after approval.

At closure, record whether the outcome was pass, pass with follow-up, or fail; name the owner and due date for every follow-up. This makes the next quarterly test a comparison against evidence rather than a ritual with expensive hardware.

Evidence, not assumptions

Perform every emergency-access test action within the same evidence chain. To find the account, open Microsoft Entra admin center → Entra ID → Users → All users, enter the approved UPN in Search, select the exact object and open Overview. The expected result is the account UPN and Object ID; compare both with the protected emergency-account register. If the name matches but the Object ID does not, stop the test and do not use that account. Clearing the Search filter or closing the pane is a safe rollback and changes nothing.

To check an exclusion, open Entra ID → Conditional Access → Policies, open every policy that includes All users, privileged roles or the administrative cloud app, then open Assignments → Users or workload identities → Exclude. The expected result is only the documented emergency-access group or registered objects; validate the group Object ID against the register, not merely its display name. If the exclusion is wrong, remove the incorrect object with X, choose Done, leave the policy in Report-only pending review and select Save. Where this could affect production, only the approved Conditional Access administrator performs it; the safe rollback is restoring the previously documented object and validating the policy summary again.

To review the test sign-in, open Entra ID → Monitoring & health → Sign-in logs → Add filters → User, select the emergency UPN and test time interval, open the event and the Conditional Access tab. The expected result is the correlation ID, resource, authentication method and each policy result, including the intended exclusion. Record these fields in the test protocol; if the result is unexpected, Sign out immediately, close the browser session, stop routine changes and hand the correlation ID to the recovery operator. Clear filters or closing the details pane reverses only the view. For export, select Download → Download (CSV) in the sign-in-log list, verify the time window and store the export in the approved evidence location; do not use the export as a reason to delete the original Entra logs.

Perform the sign-in only from an approved secure workstation: open a private browser window, go to https://entra.microsoft.com, enter only the registered emergency UPN and use the documented separately stored authenticator. The expected result is the Entra landing page and active role information; validate that at Entra ID → Roles & admins → Global Administrator → Assignments, where the account must be active, not eligible. After the test select the profile menu → Sign out, close the private window and physically return the credential to its documented storage location. This is the safe rollback: no users are created, policies changed or unrelated workloads opened.

For read-only automation, use Microsoft Graph with an approved read-only scope to compare the user Object ID, role and sign-in correlation ID with the test protocol. The expected result is the same information as the portal; a mismatch means stopping the test and checking the permissions or object, not ignoring the difference. Writing Graph changes are not an emergency-test shortcut and are never made without an approved change and clear rollback path.

References

• Microsoft: Emergency access accounts
• Microsoft: Conditional Access report-only mode
• Microsoft: What If tool
• Microsoft: Sign-in logs
• Microsoft: Authentication strengths