A recovery procedure is a theory until someone follows it. A drill on a test account shows how long recovery takes, who must be reachable and what gets left behind.

Pick the lockout you will rehearse

"Locked out" covers several problems, and each has its own fix. A forgotten password needs a reset. A lost or replaced phone or security key needs a temporary way past the second sign-in step, then a new method registered and the old one removed. A sign-in challenge the person cannot pass, such as a Google login challenge, needs that challenge lifted briefly.

Rehearse the lost phone first, because it is the hardest case: you have to let the right person back in and shut out whoever may now hold the device. NIST's digital identity guidelines say a lost authenticator should generally be assumed stolen or compromised, and that compromised authenticators must be suspended, invalidated or destroyed promptly. A forgotten password can be your second drill.

Set the rules before the drill

Pick a low-risk test account with no admin role and no sensitive data. Microsoft gives the same advice for testing its self-service password reset, noting that administrator accounts are enabled for it by default and must use two methods.

Then write down, on one page:

  • Who approves a recovery, and who approves when that person is out
  • Who performs it, and which admin role or privilege that takes
  • How the requester's identity is checked, such as a call back to a number already on file
  • Which temporary credential is allowed for each kind of lockout
  • How the person is told afterwards, and whom they contact if they did not ask for it

Have another authorized person follow the procedure while you observe and time it. The author of a procedure tends to fill its gaps from memory, which hides them.

Make the identity check hard to fake

The identity check deserves the most attention. CISA's advisory on the Scattered Spider group describes attackers who posed as employees to get help desk staff to reset passwords and transfer multifactor authentication to devices the attackers controlled. It also describes them posing as IT staff to talk employees into sharing one-time codes, sending repeated sign-in prompts until someone pressed Accept, and persuading mobile carriers to move a victim's phone number to a SIM card in their possession.

Three rules follow. Call back on a number from your own records, never one the caller offers. Give the temporary code only on that verified call, not by email to the locked-out mailbox or by text to a new number. Tell staff that whoever handles your IT will never ask them to read out a code or approve a prompt they did not start. CISA also recommends continued staff training against voice phishing.

A lost-phone report needs one more safeguard. Calling the number on file may reach the missing phone itself, or an attacker who has moved that number to their own SIM. Name a second route in the procedure, such as the person's manager confirming them face to face or a call to their desk phone, and leave a familiar voice off the list.

Know the recovery controls in Microsoft 365

In Microsoft 365, an Authentication Administrator can give a user who lost a sign-in method a Temporary Access Pass, a time-limited passcode, from the user's Authentication methods page in the Microsoft Entra admin center. The path is Entra ID, then Users, then the user, then Authentication methods and Add authentication method. Issuing one to an admin takes at least the Privileged Authentication Administrator role, and neither role lets you issue a pass for your own account. Note the code before selecting OK, because Microsoft does not show it again.

The pass works only if the Temporary Access Pass policy, under Authentication methods then Policies, is enabled and includes that user; changing the policy takes the Authentication Policy Administrator role. Its default lifetime is one hour, within a permitted range of 10 minutes to 30 days. Each user holds one pass at a time, so a new one replaces the old. A pass can be set for single use, and Microsoft says a passwordless method such as phone sign-in must then be registered within 10 minutes of signing in.

The user signs in to Security info with the pass and registers a new method, such as Microsoft Authenticator on a replacement phone. Microsoft advises anyone who updates their methods after losing a device to remove the old ones. A pass does not replace the password, and a new pass can take a few minutes to be offered at sign-in.

The same Authentication methods page holds three more controls. Reset password assigns a temporary password that must be changed at the next sign-in. Require re-register MFA deactivates hardware OATH tokens, deletes phone numbers, Microsoft Authenticator apps and software OATH tokens, and asks for a new method at the next sign-in. Because whoever signs in next is the one asked, pair it with a password reset if the phone may be in someone else's hands.

Revoke sessions invalidates the user's refresh tokens, forcing a fresh sign-in across active sessions and apps. Use it for a lost device, so apps already signed in there must sign in again. Use it at the end of the drill too, since Microsoft notes that a pass expiring does not retroactively end sessions already established.

If staff reset their own passwords through Microsoft Entra self-service password reset, its settings are under Password reset in the same admin center. Microsoft's tutorial sets Number of methods required to reset to 2. Require users to register when signing in prompts people to add their details, and Number of days before users are asked to reconfirm their authentication information keeps those details fresh. Microsoft warns that out-of-date contact details can stop someone from resetting their password when they need to.

Know the recovery controls in Google Workspace

In Google Workspace, open the user's Security page in the Admin console: Directory, then Users, then the user's name, then Security. Reset Password lets you keep Ask for a password change at the next sign-in turned on, and the 2-Step Verification section lets you generate backup verification codes. Generating new codes makes the previous set inactive, and only super administrators can generate backup codes for other admins.

The user then signs in as usual and enters one of the backup codes at the second sign-in step. Treat each code like a password and hand it over only on the verified call.

If a login challenge blocks a user who cannot verify their identity, the same Security page lets you turn off the login or verify-it's-you challenge for 10 minutes. Under Recovery information you can add a recovery email outside your organization or a recovery phone.

If a phone or laptop is lost, Sign-in cookies then Reset on the same page signs the user out of their Google Account across all devices and browsers, though Google says Gmail sessions can take up to an hour to end. Reset the password as well, since Google notes that resetting cookies without a password reset does not stop an Android device from creating a new automatic passkey. If you use a third-party single sign-on provider, end the session there first, because Google says it may still allow access.

Revoke any app passwords the lost device used, as Google advises. Remove a security key only when it is lost; for one left at home, Google suggests backup codes as a temporary workaround.

Run the drill step by step

With the rules written and the test account ready, run the lost-phone scenario in this order:

  • Start the clock when the test user reports the lost phone
  • Check identity by the route in the procedure and note the number you called
  • Get the approval and note who gave it and when
  • Issue a single-use Temporary Access Pass or a Google backup code and read it out on the verified call
  • Have the user register a new method on a replacement phone
  • Remove the lost phone's methods, revoke sessions or reset sign-in cookies, and reset the password
  • Have the user sign in again with the new password and only the new method
  • Send the recovery notice and stop the clock

The second sign-in is the real test. Until old sessions are ended and the user gets back in with nothing but the new method, the drill has shown only that the temporary code worked.

Check alerts and logs

NIST's digital identity guidelines say every account recovery must trigger a notification, with contact details in case the recipient did not request it. They also require a notice through a separate channel whenever a new sign-in method is added. Confirm the sign-in or recovery alerts you rely on arrived and reached the right person. Where an administrator did the work and nothing was sent automatically, a short note to the user and the approver serves the same purpose.

For self-service resets in Microsoft 365, set Notify users on password resets to Yes under Password reset then Notifications, so each reset emails the user. Setting Notify all admins when other admins reset their password to Yes covers administrator accounts.

To see what Microsoft logged, open Entra ID, then Users, then Audit logs in the Microsoft Entra admin center and set the Service filter to Self-service Password Management; an administrator's reset appears as Reset password (by admin). Microsoft's guide to these reports says data is collected only after someone has visited the Reporting tab or the audit logs at least once, so open them before the drill. In Google Workspace, the Admin log events report keeps a record of admin actions, including each security key revocation.

Mistakes the drill should catch

Watch for these while the drill runs, along with the sign that gives each away:

  • Turning off 2-Step Verification for a locked-out Google user instead of issuing a backup code, which Google advises against; the user's Security page shows it off
  • Setting one office number as every user's Google recovery phone, which Google blocks automatically; compare Recovery information across several users before the drill
  • Approving a reset because the caller sounds familiar, without the callback; the record has no number called
  • Waiting on a single approver who is out that day; the clock stalls at the approval step
  • The same person approving and performing the recovery; the record shows one name in both places
  • A pass set to last longer than the job needs; the user's Security info page shows its expiration time

Clean up and record the result

Before you close the drill:

  • Delete the Temporary Access Pass from the user's Authentication methods
  • Remove the method for the phone treated as lost, as Microsoft advises after a lost device
  • Generate new Google backup codes if any were shared, which makes the old set inactive
  • Record the result, time taken, owner and next drill date

Leave production emergency accounts untouched during this exercise. Microsoft's guidance gives them their own validation drill at least every 90 days. Its first step, making sure security-monitoring staff know the check is under way, is worth copying here.

A worked example

Imagine a ten-person accounting office on Microsoft 365. The office manager approves recoveries, the senior bookkeeper approves when she is out, and an outside administrator with the Authentication Administrator role performs them. The Temporary Access Pass policy is enabled for a small group that includes the test account.

At 9:00 the test user reports a lost phone. The administrator calls back the mobile number on the staff list and reaches a stranger, because the user changed numbers last year. Following the second route, the office manager confirms the user in person and approves, and the administrator calls the user's desk phone.

At 9:08 the administrator issues a single-use pass with the default one-hour lifetime and reads it out on that call. The pass is not offered at the first attempt, the short delay Microsoft warns about. At the second attempt the user signs in to Security info, adds Microsoft Authenticator on a replacement phone and removes the old phone's entries.

The administrator deletes the pass, resets the password, reads the temporary password out on the same call and selects Revoke sessions. The user signs in again with the temporary password and the new Authenticator app, chooses a new password and gets in. The administrator then emails the user and the office manager a note saying what was done and whom to call if any of it was unexpected.

The office manager records 25 minutes end to end, an out-of-date callback number to fix and the next drill date. She adds one more finding: the bookkeeper has never read the procedure, so the bookkeeper will approve the next drill.

What to do this week

Work through this list before the week is out:

  • Write the procedure on one page, including the backup approver and the second identity route
  • Check each callback number on the staff list against the phone that person carries today
  • In Microsoft 365, confirm the Temporary Access Pass policy includes the right people and note who holds Authentication Administrator and Privileged Authentication Administrator
  • In Google Workspace, confirm at least two people hold super administrator rights and check for shared recovery phone numbers
  • Turn on reset notifications if staff use self-service password reset
  • Open the Microsoft Entra audit logs once so reset events are collected
  • Create or choose the test account and book the drill with the approver and the person who will follow the procedure

Short answers to common follow-up questions

Plan for the administrator being the one locked out. Nobody can issue a Temporary Access Pass to their own account, and only super administrators can make backup codes for other admins, so name a second person who can recover each administrator and keep that person's role assigned.

Self-service reset is not in every Microsoft 365 plan. Microsoft's licensing page ties password reset to certain plans, and Microsoft Entra ID Free is not among those that include it for forgotten passwords, so check your plan before you count on it.

A phone number is a weak anchor for recovery, given the SIM swaps described above. CISA recommends phishing-resistant MFA, such as FIDO/WebAuthn or PKI-based methods, which it says are not susceptible to push bombing or SIM swap attacks.

Your IT provider's process still needs your approver. When an outside administrator performs recoveries, the approval, the second identity route and the notice to the user remain your office's decisions, and the drill is how you check that they are followed.

Repeat the drill when the people in it change. A new approver, a departing administrator or a new IT provider each changes who must be reachable, and Microsoft's emergency access guidance likewise calls for a fresh check after a change in IT staff.

Emergency access accounts are a separate check. Microsoft recommends two or more cloud-only emergency accounts, not connected to any employee's phone and protected with a passkey (FIDO2) or certificate-based authentication.

Where ALCO can help

ALCO USA Inc is an IT services company headquartered in Caldwell, Idaho, with technicians serving businesses across Idaho. Its services include Microsoft 365, Google Workspace, cybersecurity and compliance, and user training. If a drill turns up a gap, ALCO's help desk is staffed 24 hours a day, including holidays, and calls are answered by a person.

Sources