Lost or replaced phone: move authenticator to new phone

This page is for the administrator or help desk who gets the call “I lost my phone and cannot sign in”. It covers the choices in order from the smallest to the largest, what each one does, who may do it, and what the audit log records. What the person can do on their own is in Sign in to SSOGEN, and what to do if you lose your phone.

Who can do this. A Super admin or a Directory admin can revoke a phone, clear a push pause and reset a person’s second factors. An Authentication admin and a Read-only admin can open the person’s Devices tab and see the phones but change nothing. If the person is themselves an administrator, only a Super admin can act on the account; others see “Only a Super Admin can change this account.”

What you need first. Confidence that you are talking to the right person. Every action on this page removes a proof of identity, and SSOGEN cannot tell a person from an impostor who has their password. The Reset MFA dialog says it plainly: “Make sure you are talking to the right person.”

The result. The lost phone can no longer approve sign-ins or produce codes, and the person is back in with a new phone or a new second factor, with every step recorded.

1. First ask: can the person help themselves?

The person still has	What they do, without you
A recovery code	On the sign-in page they choose Use another way, then Use a recovery code. Each code works once. Signed in, they open My Account > Authenticator, remove the old phone from the table of phones, and select Pair a phone for the new one.
The old phone, working	They open My Account > Authenticator, remove the old phone and pair the new one. In the app, Remove this phone also works while Allow people to remove their phone from the app is ticked under Settings > Authenticator.
Another second factor	A passkey, codes in another authenticator app, or an emailed or texted code where the policy accepts one, signs them in; then they pair the new phone under My Account.
An email address and a phone number that receive codes, and your realm allows lost-phone recovery	The sign-in page offers Lost your phone? with Use an email code and a text code: “Confirm it is you with two codes: one sent to your email address and one sent to your phone number. Both are needed.” This exists only when When a person loses their phone under Settings > Authenticator > Lost phone is set to Lost phone recovery: email code and text code both. The default is Strict (an enrolled second factor is required): “A person who lost their only phone asks an administrator to reset their second factors. The default.”

If none of these applies, continue below.

2. Revoke the lost phone

Do this when the person still has another way to sign in (a second phone, a passkey, codes in another app) or when you only need the lost phone out of the picture.

1. Open Identity > Users, open the person, and select the Devices tab. The table Paired phones lists each phone with its name, “Paired date”, the operating system, the app version, the Last seen time and its State.
2. Find the lost phone and select Revoke on its row.
3. The dialog “Revoke person’s phone name?” says: “The phone can no longer approve sign-ins and waiting requests are canceled. This is final: the person must pair it again.” Select Revoke phone.
4. The notice reads “Revoked name for person.” The row disappears.

What this does: the phone can no longer approve sign-ins, any request waiting on it is cancelled, and the sign-in codes that phone received stop working too. The person’s passkeys, recovery codes and codes in other authenticator apps are untouched. The lost phone’s own copy of the app still shows numbers, but SSOGEN no longer accepts them.

3. Clear a push pause

A person who denied a few requests from the lost phone, or whose phone was used by someone else who tapped This wasn’t me, may have push paused. The Devices tab then shows Push suspended and the line “Push suspended until time, after repeated denied or wrong-number sign-in requests” (or “… after the person reported a sign-in request as not them”), followed by “Sign-in offers this person other methods until then. Pairing a phone or Reset MFA also ends it.”

You rarely need to touch this: the pause ends on its own, and pairing the new phone ends it too. If the person has a second phone and needs push on it now:

1. On the Devices tab select Clear push suspension.
2. The dialog “Clear person’s push suspension?” says: “Push to person’s phones resumes now, not at time. It was suspended after denied or reported requests: clear it only if you know it is person signing in.” Select Clear push suspension.
3. The notice reads “Push suspension cleared for person.”

4. Reset every second factor

Do this when the person has nothing left: no phone, no recovery code, no passkey, no other app. It is the largest action on this page.

1. Open Identity > Users, open the person, open the Actions menu and choose Reset MFA.
2. Read the dialog “Reset multi-factor authentication for username?”. It says: “Their paired phones, authenticator apps, passkeys and all remaining recovery codes stop working immediately. At their next sign-in the sign-in policy that applies to them decides: if it asks for a second factor and offers set-up, they are offered to set one up after their first factor, for n hours after this reset; otherwise they are told to contact the help desk. Under a policy that asks for a second factor, the first factor by itself never signs them in. Make sure you are talking to the right person.”
3. Select Reset MFA.
4. The notice reads “Multi-factor authentication reset for username. n authenticator credential(s) revoked, m passkey(s) removed, and recovery codes cleared. They must enroll a new factor.”

What this does, all at once: every paired phone is revoked, every authenticator app and passkey is removed, the recovery codes are cleared, the person’s current sign-ins and remembered browsers are ended, and any sign-in that was waiting for a second step is cancelled. The person starts from zero at their next sign-in.

The hours in the dialog are Set-up window after a reset (hours) under Settings > Authenticator (1 to 720; 72 by default). Whether set-up is offered at sign-in is the policy’s choice under If the person has no second factor: Offer to set one up during sign-in and After a reset only both let the person set one up inside that window; Send them to the help desk does not. The policy page states the rule: “Once someone has held a second factor, only an administrator’s Reset MFA opens set-up again, for n hours.”

The dialog also covers a case that is easy to miss. If the person signs in through an identity provider and their only email address and phone number came from that provider, no set-up code can be sent to them at sign-in, with or without the reset. The dialog says what to do instead: “add an email address or phone number to their account that the provider does not supply, or let them set up the SSOGEN Authenticator under My Account while a sign-in policy that does not ask for a second factor applies to them.”

After the reset

Tell the person what to expect at the next sign-in: after the password, the page Set up your second step with Use the SSOGEN Authenticator, and before it the proof the policy asks for (a code to their email address or phone number, for example). Once in, they should open My Account > Authenticator > Recovery codes and select Generate recovery codes; SSOGEN shows the set once with “Copy and store these codes now. They will not be shown again.” An administrator cannot generate or see a person’s recovery codes.

5. If the person is an administrator

SSOGEN refuses any change that would leave nobody able to enter the Admin Console. Reset MFA on the last administrator who can still sign in answers: “This is the only administrator who can still sign in to the admin console, and without their second factor nobody could. Nothing was reset. Give another administrator who can sign in to the admin console the Super Admin role first. If this administrator has lost their authenticator and recovery codes, use the break-glass recovery command on the server (installation guide, section 10, "Break-glass recovery of an administrator").” Revoking their only phone is refused the same way, and the refusal is itself audited. See Admin lockout protection and Break-glass recovery of an administrator.

What is audited

Everything above is in Monitoring > Audit. Open Advanced filters, enter the exact name in Event type (“Exact name, such as application.access_refused.”) and select Search; the What column writes it in words.

Event type	Shown as	When
authenticator.device_revoked	Authenticator device revoked	A phone was revoked, by an administrator or by Reset MFA.
totp.revoked	TOTP revoked	The codes of a revoked phone, or of a removed authenticator app, stopped working.
authenticator.push_suspension_cleared	Authenticator push suspension cleared	An administrator cleared a push pause.
mfa.reset_by_admin	MFA reset by admin	Reset MFA was run. One row for the reset, plus a row per phone and per passkey it removed.
webauthn.revoked	Webauthn revoked	A passkey was removed, by the person or by Reset MFA.
second_factor.removal_refused	Second factor removal refused	A reset or removal was refused because it would have locked every administrator out.
authenticator.push_reported	Authenticator push reported	Someone tapped This wasn’t me on a request for this person.
authenticator.enrollment_completed	Authenticator enrollment completed	The person paired a new phone.

The person’s own My Account activity shows the same events in friendlier words, for example “Phone removed”, “Passkey removed”, “Recovery codes rotated” and “Sign-in reported as not you on a phone”.

Check it worked

1. On the person’s Devices tab, the lost phone is gone. After a Reset MFA the tab reads “No phone paired” and the passkey list reads “No passkey”.
2. Ask the person to sign in. After the password they see Set up your second step (if the policy offers set-up) or the second-step page with their remaining methods.
3. Once they have paired the new phone, the Devices tab shows it with State Active and a fresh Paired date.
4. In Monitoring > Audit, search Event type mfa.reset_by_admin or authenticator.device_revoked with your own name under Who did it; the row is there with Result Succeeded.

Troubleshooting

What you see	What it means and what to do
Devices tab: “That phone was already revoked.”	Another administrator, the person, or a Reset MFA got there first. Reload the tab.
Devices tab: “Could not revoke the phone.”	The revoke was refused for a reason the tab does not spell out, for example the lockout protection in section 5 for an administrator’s only phone, or too many changes in a minute. Try again in a minute; for an administrator, give another account the Super Admin role first.
Devices tab: “Your role doesn’t allow this. Ask an administrator whose role can change this.”	Your role can see the phones but not revoke them. Ask a Super admin or Directory admin.
Devices tab: “Push is no longer suspended for this person.”	The pause already ended. Nothing to do.
Devices tab: “Too many changes in a short time. Wait a minute and try again.”	Clearing a pause is rate-limited. Wait a minute.
Reset MFA: “Could not reset multi-factor authentication.”	The reset did not run. Try again; if it continues, check Monitoring > System health.
Reset MFA: “This is the only administrator who can still sign in to the admin console … Nothing was reset.”	Lockout protection (section 5). Give another administrator the Super Admin role first, or use break-glass recovery.
Actions menu has no Reset MFA	The account is archived: an archived account offers only Restore account and Delete permanently. Restore it first.
Sign-in page, after the reset: “This sign-in needs a second step, and no method is set up for your account. Contact your help desk.”	The policy requires a second factor and its If the person has no second factor is Send them to the help desk, or the set-up window has passed. Change the policy choice, run Reset MFA again to open a new window, or let the person pair a phone under My Account while a policy without a second factor applies.
Sign-in page: “We could not send a code to address. Outgoing email may not be set up.”	Set-up at sign-in asks for an emailed code and mail is not working. Check Settings > SMTP and Monitoring > System health.
The person signed in but My Account says “This deployment does not use recovery codes”	Allow recovery codes is off under Settings > Security. People then rely on a second phone, a passkey, or you.