Lost VPN Authenticator: Replace Without Disabling MFA

Someone loses a phone and the ticket arrives as VPN broken. That framing is wrong twice: the account still exists, and the gateway still trusts the identity provider, so the only broken part is one factor a person no longer holds. Treat it as recovery rather than as an outage: verify the requester, enroll a replacement, retire the lost method, then prove the account works. All of it assumes the plan was written before the loss, because inventing it during the call is how MFA ends up switched off for everyone.

Step 1: read the enrolled factors from a record, not from memory

The first question is not which device was lost, but what else the account can still use. An account may carry a password plus push, a time-based code, a hardware key and printed recovery codes, and losing one of those is a very different event from losing the only one. Read the method list from the identity system instead of asking the user to remember it, and in a Microsoft Entra tenant the query is one line:

Get-MgUserAuthenticationMethod -UserId [email protected]

Then write the recovery record while the account still works: account identifier, enrolled factors, where the recovery codes live, who can verify the requester independently, and which systems the account reaches. Keep it in the protected inventory the team already uses, never in a note that also holds live codes. Those five fields turn a panicky call into a checklist, and NIST's authenticator lifecycle guidance treats recovery as part of the credential rather than an exception to it.

Record the verification channel as its own field, because that is the part people skip. A phone number attached to the account is not an independent channel when the person asking also controls the phone.

Step 2: verify the requester off the failing path

Run the identity check through a channel that does not depend on the VPN, the mailbox or the lost device. A callback to a number from the HR record, or an in-person check with a manager already in the directory, both work; a chat message sent from the account under recovery does not. The check is about the person, not about their ability to answer questions about the account, because account details leak. Log who verified the request and when, since the next reviewer will want both.

When the request arrives with urgency and pressure to skip the check, that is the moment to slow down. Recovery fraud looks exactly like a helpful colleague in a hurry.

Step 3: enroll the replacement, then retire the old factor

Enroll the new authenticator through the normal enrollment flow, never through an administrative bypass. Then remove the lost method explicitly, because enrolling a replacement leaves the previous authenticator authorised until somebody retires it. If the old device may be in another person's hands, treat removal as urgent and follow the incident process instead of the recovery one. Revoke existing sessions in the same pass, since a session created before the change can outlive it:

Revoke-MgUserSignInSession -UserId [email protected]

Removing the factor for everyone else, or relaxing the gateway's certificate checks, trades one person's recovery for an outage that touches the whole deployment. Keep the change scoped to the single account and escalate if the evidence points at a wider compromise. Note in the ticket which factor was retired and which one replaced it.

Step 4: prove the account works in both directions

Log in once with the new factor through a supported client, then confirm the account still reaches the resources it did before the loss. Test one resource that needs the tunnel and one that does not, so a failure points at the right layer. Attempt a login with the retired factor and expect a rejection rather than a prompt, which proves the removal took effect. A challenge that fails from an existing enrolled device is a prompt problem, not a reason to re-enroll everything.

Then ask the user to complete the same login without coaching. Your successful test proves the configuration; their attempt proves the handover.

Close the ticket with the timestamp of the successful login and the name of the factor now in use. Update the recovery record in the same pass, so the next loss starts from an accurate inventory instead of a stale one.

Step 5: remove the condition that made this painful

Every recovery call is evidence about the enrollment design. If the account had exactly one factor, require a second for everyone in that group. If the recovery codes sat on the laptop that was lost, change where they live. If verification needed a manager who was on leave, name a deputy. Each fix takes an afternoon and removes the worst hour of the next incident.

Then re-read the record from step one against reality. Does it list the factors that actually exist, and does the verification channel still reach a human? A runbook nobody updates decays into a document people ignore during the call it was written for.