Second-Factor Problems: New Phones, Lost Devices and Lockouts

Monday, 08:10, at Acme. Lena got a new phone on Saturday, and the shop moved everything across for her, which took forty minutes and a great deal of reassurance. The authenticator app is on the new phone. It opens. It shows nothing, or rather it shows a cheerful screen inviting her to add an account. The VPN client on her laptop is waiting for a six-digit code that no longer exists anywhere on earth. The old phone was traded in on Saturday afternoon and is, by now, in a box. Farid, on the desk, has had four of these this month, all on a Monday. The ticket in front of him says "MFA broken, please reset, urgent, I have a client call at nine".

A second factor is the second proof the sign-in asks for after the password: usually something the person has rather than something they know. In practice that means a phone with an authenticator app, a hardware key, or a code sent by text. On most sign-in screens it is labelled MFA, for multi-factor authentication, which is the same idea with a longer name. The whole point of it is that a password alone is no longer enough. The whole trouble with it is that the factor lives on a device, so every change of device is a change of factor. Second-factor problems are the tickets that follow from that: the new phone, the lost phone, the backup codes nobody wrote down, and the code that is refused. This article is part of our VPN & Remote Access Tickets series. This article is written entirely from the desk's side. Its one hard rule is that nobody gets a new second factor until the desk is sure who is asking.

This article covers why the second factor is a device problem, then the four tickets and their first questions. Next come the new phone with no authenticator on it, the lost device, and backup codes. We cover verifying identity before any re-enrolment, then refused codes and lockouts. We finish with what the enrolment runbook must contain, a short war story, and the re-enrolment runbook to copy.

The Second Factor Is a Device Problem

When a user enrols an authenticator app, the identity service and the app agree on a secret that lives only in that app on that phone. Every code the app shows is computed from that secret and the time. Nothing about the user's account changes; the account merely now expects codes from that secret. Move to a new phone and the secret does not come with the user unless something carried it. Some apps can move their accounts to a new device if the user does it before the old one is wiped. Some identity services let a user re-enrol themselves while they still hold a working factor, and some arrangements carry nothing at all. The shop that moves "everything" moves photos, contacts and apps. It cannot move what the app was never designed to let out.

A hardware key, the small device that plugs in or taps the phone, has the same property more visibly. The secret is in the key, the key is in a drawer, and the user in a hotel without it has no factor. A text message code is tied to the phone number rather than the device, which makes a new phone painless and a lost one worse. That is because whoever has the phone has the number until the carrier is told. The desk does not need to know which method the organisation uses in detail. It needs to know which one, written on the internal page, and what the user can do for themselves before the desk gets involved.

The desk's role across all of this is narrow and important. It is the place a user comes to when they can no longer prove who they are by the normal route. The desk must prove it another way before handing them a new route. That is the same job the password reset does, with higher stakes, because a second factor given to the wrong person defeats the only control that was still standing after the password. Treat every second-factor ticket as a password reset that matters more, and most of the rest of this article follows.

The Four Tickets and Their First Questions

Four shapes cover nearly every second-factor ticket a small desk sees, and each has a first question that sorts it from the others in a minute. The table gives the four, the words the requester tends to use, the question, and what the first move is. The sections that follow take each in turn. Note that two of the four are sorted by a question that has nothing to do with the phone. That question has everything to do with whether the user still holds any working factor at all. That is because that one fact decides whether the user can fix it themselves or the desk must verify them first.

The question "do you still have a working factor" is the hinge, and it is worth asking twice. Take a user who has the old phone in a drawer, or a hardware key at home, or one unused backup code in a notebook. They can usually re-enrol a new phone themselves through whatever self-service the identity service offers, in five minutes. No verification is needed from the desk because the existing factor is the verification. A user with none of those is asking the desk to vouch for them, and that is a different ticket with a different pace. Most users do not know which of the two they are. The question tells them.

The New Phone With No Authenticator on It

The ideal version of this ticket never reaches the desk. Before wiping or trading in the old phone, the user moves the authenticator's accounts across using the app's own transfer. Or they sign in on the new phone with the old one still working and enrol it as a second device, then remove the old one. Most identity services allow a user who holds a working factor to add another. The setup guide should say so in a section called "before you change your phone", visible to everyone. That is because the users who most need it are the ones about to do the wiping. The article on Enrolment and Setup Without a Visit covers the first-time setup on a phone; this section is only about the second phone.

The common version is Lena's: the old phone is gone, the new one has an empty app, and the user has no backup codes they can find. There is no self-service route left, because every self-service route needs a working factor to prove the request is genuine. That is the whole reason the desk exists for this ticket. The desk verifies the person by a route that does not depend on the lost factor. It removes the old enrolment so that the secret in the traded-in phone can never be used again. It issues a fresh enrolment, watches the user complete it, and confirms with a real sign-in. The procedure is the runbook at the end of this article. The verification is the section below it, and it is not optional because the user has a client call at nine.

The version that fools people is the half-moved app. The user moved the app to the new phone, the app shows an account with the organisation's name on it, and the codes are refused. Some transfer methods copy the app but not its secrets, so what the user has is an entry that looks right and computes codes from nothing. The first question still sorts it, because the user does not have the old phone and does not have a working factor, whatever the screen says. That ticket goes down the verified route. Tell the user plainly that the app on the new phone is empty of anything useful and that this is not their fault. The transfer offered to move it and did not say what it could not carry.

The Lost Device

A lost phone is a security event before it is a second-factor ticket. The first hour belongs to containment rather than to getting the user back in. The phone may be in a taxi, a café, or a stranger's pocket. Until it is known to be wiped or locked, whatever it holds is potentially in someone else's hands. That includes the authenticator and its secrets, the mail app with its saved session, the VPN client if one was installed, and the saved passwords in the browser. The desk first revokes the phone's enrolment as a second factor, so that the codes it produces stop working. It signs the account out of every session the identity service lets it see, so that whoever has the phone is not already inside the mailbox. It resets the password if the phone could have had it saved. All three are done before the user is re-enrolled. All three are done on the user's say-so, because removing access from an account is safe to do on a report and adding it is not.

The wider runbook for a lost or stolen device covers the lock-or-wipe decision and who makes it, and the carrier. It also covers the organisation's rules on a police report and the discretion the user is owed. That runbook lives in Lost and Stolen Devices: The First Hour. The second-factor article adds only one thing to it: the re-enrolment comes last, and it is verified like any other. A user who has just lost a phone is also a user whose normal proof of identity has just gone. The desk should say so kindly and then do the verification anyway. "I know this is the last thing you need this morning; I have to confirm it is you by another route before I can give you a new sign-in, and here is how we do that."

Say nothing that sounds like blame, in the ticket or on the call. Phones get lost; the organisation's arrangements are supposed to survive it. A user who is made to feel foolish for reporting a loss will report the next one later, which is the one outcome that actually causes harm. The found phone, which turns up in the car the next day, gets a line in the note and nothing else. Nobody re-enables anything on a phone that spent a night somewhere unknown.

Backup Codes

Backup codes are a short list of one-time codes, issued at enrolment, each of which can stand in for the second factor exactly once. They exist for precisely the morning this article is about. A user with one unused backup code can sign in, enrol a new phone, and generate a fresh list without the desk being involved at all. The organisation's setup guide should say where to keep them, in plain words. The guide should say to keep them printed with other important papers, or in a password manager if the organisation provides one. It should say never to keep them in the mail app on the same phone they are meant to replace. Lena was issued ten. They are in a message she sent herself, on the phone that is in a box.

The desk's rule for backup codes is short: the desk never sees them, never stores them, never reads one out, and never writes one down. When the runbook issues a new list at the end of a re-enrolment, the list is generated on the user's screen and the user keeps it. In that case, the ticket records that codes were issued and how many, and nothing else. If you run QuerySolv, the internal note on a ticket is hidden from the requester, not from every colleague who can open the ticket. It is still not a place for a code. The note says what was done, and a secret is never what was done. Any help desk tool with an internal note has the same property, and the rule is the same in all of them.

The same rule covers everything else of the kind. A temporary code the identity service generates for an enrolment goes to the user by a route the desk has verified. It never goes into a reply the whole ticket thread can read. A desk that gets this right can hand a ticket to a security reviewer a year later without wincing. A desk that gets it wrong has a search index full of codes.

Verifying Identity Before Any Re-Enrolment

Re-enrolling a second factor is a password reset with higher stakes, and the verification before it is at least as strict. The standard itself, the routes that count as proof, and the manager-vouches path are set out in Verifying Identity Before You Reset Anything. That article also sets out what to do when the user cannot meet the standard, and how to say all this to someone in a hurry. This article leans on that standard rather than restating it. What this article adds is the reason the stakes are higher. A reset password can be changed again by the account's owner the moment they notice. A second factor handed to someone else lets that someone pass every check the organisation has, for as long as it takes anyone to notice. The account's owner may be the last to know.

Three things are not verification, and the desk should be able to name them without hesitation. A voice the technician recognises is not verification; voices are recognised wrongly. A desk that relies on recognition has a rule that works only for the people it already knows. Urgency is not verification. A request that arrives with a nine o'clock client call attached is a request to verify with exactly the same care. A desk that verifies less when the pressure is higher has a rule that fails precisely when it matters. And knowledge of the account's details, the name, the e-mail address, the manager's name, the office location, is not verification either. That is because all of it is printed on the organisation's website or the user's own social profile. Verification is a route the desk controls. That could be a call back to a number already on file, or a manager contacted through a route the desk chose. It could be a face on a video call matched to a photo the organisation already holds, or the person at the desk in person. The password article has the list; use it.

The desk must also be able to name what it never does, whatever the caller says. It never reads a code to a caller, from any screen. It never approves a prompt on a user's behalf. It never turns the second factor off "just for today" to get someone working. If the organisation's rules allow that at all, it is a decision with a second person, a record and a time limit, not a Monday phone call. And the desk never completes a re-enrolment on the strength of a message from the user's own mailbox. That is because the mailbox is one of the things the second factor protects and may be in the wrong hands already. None of this needs to be said to the user in those words. It needs to be in the runbook. That way, the technician who is asked to do one of them can say "the procedure doesn't allow that, and here is what it does allow" and mean it.

Say the verification step as a courtesy, not a suspicion. "Before I can give you a new sign-in I need to confirm it's you by a route that doesn't go through your phone, because the phone is the thing that's missing. It takes about five minutes." Most users accept that at once, and the ones who push back are usually pushing back on the five minutes, not the principle. Give them the time estimate and keep it. Nobody has ever been talked into a verification they thought would take an hour.

Refused Codes and Lockouts

The code that is always refused, on a phone the user still has, is usually the clock. Authenticator codes are computed from the time. A phone whose clock has drifted by more than a minute or two produces codes the identity service has already discarded. The fix is to set the phone's clock to update automatically, which most phones do by default and some users have switched off for reasons of their own. Ask the first question in the table, "is the phone's clock set to automatic", and ask the user to compare the phone's time with the laptop's. A difference of a few minutes is the whole ticket. No re-enrolment is needed, and doing one anyway would fix nothing, because the new secret would compute codes from the same wrong clock.

The lockout after too many refused codes is the identity service protecting the account. The desk's job is to find out why the codes were refused before clearing anything. The cause might be a wrong clock, a half-moved app, or a user typing codes from the wrong account in an app that holds several. It might be someone other than the user trying codes against the account. The first three are tickets and the fourth is a security report. The account's sign-in history, which most identity services show, tells them apart by where the attempts came from. A lockout cleared without looking is a lockout that comes back. The lockout article in the password series has already said so at length.

The prompt the user did not ask for is the one every user should be told about in the setup guide, in one line: if your phone asks you to approve a sign-in you did not start, press deny and tell the desk. A denied prompt costs nothing. An approved one, pressed to make the phone stop buzzing, hands over the account. When it is reported, the desk treats it as a security ticket, resets the password, and passes it to whoever owns security, with the time and what the user saw. The shape of that handover is in Other Security Tickets the Desk Will See. The user who reported it is thanked, specifically, because reporting a prompt is the behaviour the organisation most wants and least often rewards.

What the Enrolment Runbook Must Contain

The runbook for a re-enrolment is short, agents-only, and followed in order every time, including the time the requester is the managing director and especially then. It verifies first and records the route. It revokes the old enrolment before issuing anything new, so the lost or traded-in phone becomes useless at that moment rather than later. It issues the new enrolment by a route that reaches the verified person and nobody else. It has the user complete it while the technician is on the call. It confirms with a real sign-in to something that needs the factor before the ticket is touched again. It ends with fresh backup codes kept by the user and a note that says what was done, by which route, and when, with no secret anywhere in it.

Two people are involved when the runbook cannot be completed by the book. That includes when the user cannot meet the verification standard, when the requester is senior enough that the technician feels pressure, or when anything about the request does not fit. The second person is the desk lead or whoever owns security, and the runbook names the role. A technician alone on a Monday morning with a locked-out executive on the phone should never be the only control. A runbook that says "stop here and get the second person" gives them the words to do it.

A Short War Story: One Voice at Pennywell Solicitors

Marcus, a partner at Pennywell Solicitors, left his phone on a train on a Sunday and rang the desk at eight on Monday with a court filing due at noon. Dev, covering for the only technician who knew the re-enrolment procedure, recognised Marcus's voice. He cleared the old enrolment, read him a temporary code from the screen, and had him working by half past eight. The note on the ticket said "verified by voice, sounded like him". It was him. Six weeks later the firm's annual security review read the note. Because the firm's own policy said a second factor was never issued on a voice, every sign-in on Marcus's account for the month had to be reviewed against his diary. That took the desk lead about twelve hours. The firm's insurer asked questions that took a partner most of a day to answer. The cost was a day of a partner's time and twelve hours of the desk lead's. It also included a technician who had done a kind thing and was made to feel he had done a dangerous one, which he had. The lesson the firm wrote into the runbook was that a verification route the desk controls takes five minutes. It also said that the runbook must be known by more than one person, and that "sounded like him" is a sentence a reviewer will read aloud.

The Re-Enrolment Runbook

The runbook below is the one to keep as an agents-only article. Fill the organisation's own identity service steps into the blanks and copy the verification routes from the password series' standard. The runbook is joke-free and followed in order; the stop lines are the point. Section A is the sort, B the verification, and C the containment that happens before anything new is issued. D is the enrolment itself, E the confirmation and the codes, and F the note. Write the date it was last run at the bottom and the ticket it was run on.

SECOND-FACTOR RE-ENROLMENT RUNBOOK — AGENTS ONLY
Ticket: ________   Requester: ______________   Technician: ______________   Started: ______

A. SORT (one minute)
   Does the requester still hold ANY working factor?  old phone on / hardware key / unused backup code
     [ ] YES — point them to the self-service route: ______________________  Stop here if it works.
     [ ] NO  — continue to B. Do not issue anything yet.
   Is the device lost or stolen?  yes / no   If yes: do C first, then the lost-device runbook, then B.

B. VERIFY (by the password series' standard; route must not depend on the missing factor)
   Route used (tick one):
     [ ] call back to the number already on file: ______________
     [ ] manager confirmed through a route the desk chose: ______________
     [ ] video call, face matched to the photo on file
     [ ] in person at the desk
   NOT verification: a recognised voice; urgency; account details; a message from the user's own mailbox.
   Verification not met, or anything does not fit: STOP. Hand to ______________ (second person, by role).

C. CONTAIN (before anything new is issued)
   [ ] remove the old enrolment from the account, so the old device's codes stop working
   [ ] sign the account out of all sessions the identity service can see
   [ ] reset the password if the device could have held it saved (lost or stolen: always)
   Time done: ______

D. ENROL (user on the call; technician watches it finish)
   [ ] issue the new enrolment by the verified route only: ______________________
   [ ] user installs or opens the authenticator on the new device and completes enrolment
   [ ] the one step that usually goes wrong here, and the fix: ______________________________
   Never read a code from any screen to the requester. Never approve a prompt on their behalf.

E. CONFIRM AND ISSUE CODES
   [ ] user signs in to something that requires the factor (VPN / mailbox): success at ______
   [ ] user generates fresh backup codes ON THEIR OWN SCREEN; told where to keep them: ______________
   [ ] old backup codes are now void; user told to discard any they find
   The desk never sees, stores, writes or reads out a backup code.

F. CLOSE
   Note on the ticket: what was done, verification route (B), containment time (C), confirmation time (E).
   Secrets in the note: NONE. Codes in the note: NONE.
   Lost or stolen device: link the lost-device ticket.   Category corrected at close: second factor.

Last run on ticket ______ by ______________ on ______________   Changes noted: ______________________

Farid ran Lena's ticket through the runbook at 08:15. The sort took a minute, because she had no old phone and no codes. The call back to her desk number took four minutes, including the time for her to walk to it. Containment, enrolment and confirmation took eleven. She was on her client call at nine with a new phone that worked, and a printed list of codes in her desk drawer. She also had a ticket note that a reviewer could read without flinching. The desk's "before you change your phone" article went out in the weekly notice the same afternoon. The Monday count fell from four to about one, which is the number the article at the end of this series would like to make zero.

Frequently Asked Questions