The Manual Reset, Done Safely, for the Rest

Tuesday, 15:40, at Bluewater Bank. A message arrives in the desk's live chat: "hi it's Dan from treasury, locked out again, can you reset me and just pop the new password in here, I'm in a meeting." Aisha knows Dan. She has reset Dan twice this year. The chat account says Dan, the tone is Dan, and the request would take her ninety seconds. She also knows that a chat window proves exactly one thing: someone is typing into Dan's chat. Treasury is the department whose accounts the bank's security owner lists first. She types: "I can do that now. I'll call you on your desk extension in one minute to confirm, then read you a temporary password." Dan replies "ok fine" with the mild irritation of a man in a meeting, and answers the phone on the second ring. Ninety seconds became four minutes. The four minutes are the subject of this article.

A manual reset is a password reset or account unlock carried out by a technician, in the directory. It is for a user who could not or did not do it themselves. Self-service, once enrolled, removes most resets from the desk. It never removes all of them. The ones that remain are, by definition, the ones self-service could not verify. That makes the manual route the place where a stranger will try next. The manual reset therefore has to be the strongest route into an account, not the weakest. It has to stay strong on the Monday when there are eleven of them. This article is part of our Password Reset Self-Service series. It is the procedure for the resets that stay.

It covers who still needs a manual reset once self-service is live, then the verification standard and the ladder of acceptable proofs. Next come the script step by step and how a temporary password is handed over safely. It explains why a request over chat or e-mail is never fulfilled over chat or e-mail, and what goes in the ticket and what never does. Then come the caller who wants to skip the steps and keeping the standard on a busy Monday. A short war story and the verification script to copy follow, in that order.

Who Still Needs a Manual Reset

Four groups of people will need a technician to reset them after self-service is live, and the plan should expect all four. The first is the people who have not enrolled yet, the stragglers. Their reset call is also the best moment to enrol them, as Enrolment Is the Whole Project argues at length. The second is the people who cannot enrol: no phone of any kind, a shared account, an exclusion the security owner wrote down. The third is the people whose second factor is gone: the new phone, the lost token, the number that changed. The fourth is the people for whom self-service failed. A code never arrived, a page would not load from the login screen, or a PIN was forgotten. Their ticket is a reset and also a bug report, and the bug report half is the one that fixes the system.

The third group is the one that makes the manual route important rather than residual. When the second factor is lost, the manual reset is the recovery route for the recovery route. It is the way back in for someone who has lost the thing self-service relies on. That is also exactly the story a stranger would tell: "I've got a new phone, the code's going to the old one." The manual route is therefore the one route to every account that cannot depend on the enrolled factor. And that is why its standard has to be set deliberately rather than left to whatever the technician usually does. Self-service lets the desk do fewer resets. It does not let the desk do them more casually. If anything the opposite.

The Standard Before the Script

The verification standard is the written list of proofs the desk accepts before it resets a password. It is the same list for every caller, every channel and every technician. And it must exist before the script does. Most desks have never written theirs down. The self-service project is the moment to do it. The trade-off table in Security Trade-offs: Convenience Against Identity has already forced the question of which proofs are real. The standard for the desk is the same table read from the other side. It includes the methods that self-service was allowed to use, plus the staffed methods only a human can do. It excludes everything a stranger could assemble from a name and ten minutes.

Write the standard as a ladder, because the caller will not always have the top rung. The technician needs to know which rung to go to next rather than improvising. The top rung is a call back to the phone number already held in the directory, desk extension or recorded mobile. That proves the caller holds a phone the organisation already associates with them. Below it, a one-time code to an enrolled factor, where the user has one and the problem is something other than the factor. Below that, a manager confirms the request in person or from their own verified phone. That moves the proof to someone whose identity the desk can check. At the bottom, the user in person at the desk or a staffed point, with a photo badge. Beside the ladder, in a box, are the proofs that are never accepted on their own. These are the voice, the start date, the employee number, the manager's name, the security question, and the channel the request arrived on.

Add a short list of accounts that only ever use rung four. Include anything that administers the directory or the reset system, anything that can move money, and anything the security owner names. Those holders get told in advance that a reset means a walk to the desk or a visit from a technician. In my experience they take it well once someone explains that the rule exists because their account is worth more to a stranger. Most people are flattered to be told they are a target. Briefly.

The Script, Step by Step

The script is nine steps, in order. The order is doing work. The two most common mistakes are resetting before verifying and handing over before the directory has been told to force a change. First, find the account by the name the caller gives, in the directory. Read back the department and manager from the directory to the caller, not the other way round. The caller confirming facts you read to them tells you nothing. This step is for finding the account, not proving the caller. Second, confirm what they want. Is it a reset because the password is forgotten, or an unlock because it is known and the account is locked? These are different changes with different causes. Third, ask the unlock question before anything else: "is there a phone, tablet or second machine still signed in with the old password?" An unlock without that question is an unlock that will be repeated at eleven.

Fourth, choose the rung. Say what you are doing in one sentence: "I'm going to call you back on your desk extension to confirm it's you, then reset it." Do it, even to the colleague whose voice you have known for years. Fifth, on the verified call, make the change: a new random temporary password. Switch on the directory's option to force a change at next login, and unlock the account if it was locked. Sixth, read the temporary password aloud, twice, slowly, in groups, with the letters spelled where they could be confused. Never type it into any written channel. Seventh, stay on the call while the user signs in and chooses their own password. That way, the temporary one has lived for about ninety seconds and the call ends with a working login rather than a hope.

Eighth, if the user is not enrolled in self-service, enrol them now, while they are signed in and on the phone. That turns this reset into the last one they will need from you. Ninth, write the note in the ticket. Record who asked, by which channel, which rung was used and to which number. Record that the reset or unlock was done and when, that the user confirmed login, and whether they were enrolled. Those are nine steps, about four minutes when nothing goes wrong. The whole thing is in the template at the end as a card to keep by the phone. A reset done in ninety seconds has skipped at least three of them. And the three skipped are always the call back, the forced change and the note.

The Temporary Password, Handed Over Safely

A temporary password is the one the technician sets so that the user can log in once and choose their own. It is handled safely by four rules. It is random and used once, never a pattern the whole desk uses. A pattern the desk uses is a password every leaver knows and every stranger who has heard one reset can guess. The temporary password is set with the directory's force-change-at-next-login option. That way, even if it is overheard it is dead the moment the user signs in, and dead within the hour if they do not. It is spoken, on a verified call, never written into chat, e-mail, a text or the ticket. And it is spoken to the person who was verified, not to the colleague who "is sitting right here and can take it down".

The user may be unable to take a call because they are in a no-phone area or the only phone is the one they have lost. In that case, the temporary password is delivered by a route that is itself verified. It is read to the user in person, or given to their manager in person for the manager to hand over. The force-change option makes the exposure short. What is never acceptable is the route of least effort, which is to type it back into whatever window the request came from. That window is the subject of the next section. The rule has its own section because it is the one most often broken by good technicians who were trying to be quick.

Set the password rules expectation while the user is choosing their own, in one sentence. "It needs at least this many characters and can't be one you've used before, so a short phrase works well." Half the follow-up calls from a manual reset are a user whose new password was rejected and who could not read the rejection message. One sentence prevents most of them. The other half are the stale phone, which you asked about in step three. If you did not, you will be unlocking the account again shortly, and the user will be entitled to the sigh.

Never Over Chat or E-mail Without Verification

A request that arrives by chat, e-mail, text or social message is a ticket like any other. And the channel it arrived on is never, by itself, proof of who sent it. A mailbox can be read by anyone who has its password, which is, after all, the thing that is being asked for. A chat account is signed in on a laptop that may be unattended, a phone that may have been taken, or a browser a colleague borrowed. The message that says "it's Dan, can you reset me and send it here" might be Dan. The desk cannot know. And the one thing it must not do is answer the question of whether it is Dan by sending Dan's new password to whoever asked. The channel is where the request came in. Verification happens on a channel the desk chooses.

The right response is the one Aisha gave. And it takes ten seconds to type: acknowledge, say you will call the number in the directory in a minute, and do it. If the number in the directory is the phone the user has lost, go down the ladder to the manager or in person. Do not go sideways to "well, which number should I call?" A number the caller supplies is a number the caller controls. The reset is then done on the verified call, and the temporary password is spoken. And the chat or e-mail thread gets one line: "done, and confirmed by phone." If you run QuerySolv, the chat, the e-mail and the web form all land as ordinary tickets in the same queue. So the record of the request and the technician's verification note live in one place regardless of which window the user typed into. The note itself is an internal note the requester never sees. Whatever the tool, the principle is that the channel chooses nothing about how the reset is verified.

Expect the request to be impatient and the impatience to be genuine. Dan is in a meeting. The housing officer is in a tenant's kitchen. The store manager has a queue at the till. None of that changes the rung. The technician's job is to be quick inside the standard rather than quick instead of it. Call back within the minute you promised, have the directory window open before you dial, and keep the whole call to four minutes. A standard that is slow gets bypassed by sympathetic technicians. A standard that is fast and firm gets followed. And the users learn it in a fortnight and stop asking for the password in the chat window. Dan stopped after the second time, which for Dan is quick.

What Goes in the Ticket, and What Never Does

The ticket note for a manual reset answers four questions a stranger reviewing the account in a year would ask. Who asked and how? How did the desk know it was them? What was changed and when? What happened next? In practice that is six short lines, and they are in the template. The reason for the note is not bureaucracy. It is that the directory's own log will say an administrator changed the password at 15:44. And the ticket is the only place that says why, for whom, and on what proof. When the monthly review compares the directory log with the tickets, it first finds a reset with no ticket or a ticket with no rung recorded. That usually comes from a technician who was being kind in a hurry. The note is what distinguishes kindness from a hole.

Three things never go in the ticket. The temporary password, in any form, including "set to the usual". The user's new password, which the technician should never know, since they chose it on their own screen. The third is any reproduction of a security question's answer or a personal detail used to find the account. The ticket is read by more people over more years than the person writing it imagines. The full list of what a ticket should never hold is in What Not to Write in a Ticket. For resets, the short version is that a ticket records how identity was proved. It never records anything that would help someone fake it next time.

The Caller Who Wants to Skip It

Someone will ask the technician to skip the verification. The request will be reasonable-sounding, because the people who make it are nearly always genuine and in a hurry. The director's assistant who "always does this for him". The colleague at the next desk who vouches for the caller on the other line. The senior manager who says "you know who I am" and does, in fact, sound exactly like himself. The technician's own instinct, which says that a call back to a director's extension is faintly insulting. None of these is a rung. The response is one sentence, said warmly and without apology. "I do this for everyone, including the chief executive; I'll call your extension in one minute and we'll be done in four."

Where the caller has the authority to change the rule, and some do, the answer is still not to skip it today. It is to do today's reset to the standard and route the question of the standard to the security owner, in writing. That is the move described in Saying No Upward: Managers, Directors and the Exception. The standard is the security owner's rule, not the technician's. And a technician who bends it for a director has made a decision about the director's account that neither of them had the right to make. In practice, nobody with authority ever changes the rule once they understand that the rule is protecting their own mailbox. They just want the four minutes to be four.

The Standard on a Busy Monday

The standard is tested by volume, not by cleverness, and the Monday after a holiday is the test. Eleven callers are holding, three chats are open, and every one of them is a reset. It is exactly the morning on which a technician will decide that the call back can be skipped for the ones they recognise. It is exactly the morning a stranger would choose. The defence is organisational, not moral. Put resets on one technician for the morning, on a rota. That way, the others can work the queue and the reset technician can work the ladder without feeling the queue behind them. Queue the callers honestly, with a time: "I'll call you back on your extension by ten past; please stay near the phone." And have the directory window, the script card and the ticket template open before the first call, so that four minutes is four minutes.

Count what the morning cost afterwards, because the count is the case for finishing the enrolment campaign. If eleven manual resets on a Monday are eleven unenrolled people, that is eleven enrolments the technician should have done on the calls. In that case, it also means eleven names for the manager nudge. If those resets are eleven lost phones after a company handset refresh, that is a conversation with whoever runs the handsets about telling the desk next time. If those resets are eleven self-service failures, something is broken and it is the most important ticket of the day. The manual reset count after self-service is never just a workload. It is a reading of what the project has not yet reached, and Measuring the Drop and Keeping It Down is about taking that reading every month.

A Short War Story: The Payroll Mailbox at Pennywell Council

At Pennywell Council, an e-mail arrived at the desk from the payroll officer's own address at 16:50 on a Friday. It said she was locked out of the finance system and working late on the month-end run. It asked whether the new password could be e-mailed back as her desk phone was "playing up". The technician, Ewan, recognised the address and knew the month-end run was real. He reset the finance account and e-mailed the temporary password to the address the request had come from. That seemed to him the natural place to send it. The payroll officer's mailbox had been compromised two days earlier through a convincing message about a shared document. The person reading it was not the payroll officer. By Monday morning a supplier's bank details had been changed and a payment run approved. The bank's own checks caught the payment, which was the only piece of luck in the story. The council spent two days reconstructing what had been read and changed and made the report its regulator required. It rewrote its reset standard so that no request arriving by e-mail or chat was ever fulfilled by e-mail or chat. A call back to the directory number was the first rung for everyone. Ewan had verified nothing except that the request came from the mailbox, and the mailbox was the thing that had been stolen. The channel a request arrives on proves who holds the channel, and nothing else.

The Verification Script

The script below is a card to keep beside the phone and a note to paste into the ticket, in that order. The card is the nine steps with the ladder on it. That way, a technician on their eleventh reset of the morning does not have to remember which rung comes next. The note is the six lines the ticket needs, with the three things that must never appear in it listed at the bottom. That way, nobody has to be told twice. Fill in the account exclusions and the directory-number source once, in ink; the rest is filled in on each call.

MANUAL RESET — VERIFICATION SCRIPT (KEEP BY THE PHONE)
Desk: ______________________   Standard owner: ____________   Accounts that are rung 4 only: ______________________

THE LADDER (go down only when the rung above is not available)
   1. Call back to the number held in the directory (extension or recorded mobile)
   2. One-time code to the user's enrolled factor, read back to you
   3. Manager confirms in person or from the manager's own directory number
   4. User in person at the desk or staffed point, photo badge checked
   Never alone: voice, start date, employee number, manager's name, security question,
                the fact that the request came from the user's own e-mail or chat

THE NINE STEPS
   [ ] 1. Find the account in the directory. Read department and manager TO the caller.
   [ ] 2. Confirm: reset (password forgotten) or unlock (password known, account locked)?
   [ ] 3. Ask: "Is a phone, tablet or second machine still signed in with the old password?"
   [ ] 4. Say which rung you are using, then do it. Rung used: ____   Number called: ______________
   [ ] 5. On the verified call: new random temporary password, force change at next login, unlock if locked.
   [ ] 6. Read the temporary password aloud, twice, in groups. Never type it anywhere.
   [ ] 7. Stay on the call until the user has signed in and chosen their own password.
   [ ] 8. Not enrolled in self-service? Enrol them now, while signed in.   Enrolled: [ ] yes  [ ] already  [ ] cannot
   [ ] 9. Write the ticket note below. Close with "confirmed by phone" on the original channel.

IF ASKED TO SKIP A STEP
   "I do this for everyone, including the chief executive. I'll call your extension in one minute
    and we'll be done in four."   Then route any request to change the standard to: ____________

TICKET NOTE (internal, paste and fill)
   Request received by: phone / e-mail / chat / form / in person   at: ____:____
   Account: ______________   Change: reset / unlock   Stale device asked about: yes / no   Found: ______________
   Verified by rung ____ : ______________________ (number called or person who confirmed)
   Changed at: ____:____   Force change at next login: yes   User confirmed login: yes / no
   Enrolled in self-service on this call: yes / already / cannot (reason: ______________)
   Self-service failed first? yes / no   If yes, what happened: ______________________

NEVER IN THE TICKET: the temporary password, the user's new password, any answer or personal
detail that was used to find the account.

Aisha's call with Dan took four minutes and ended with Dan enrolled, which he had been meaning to do since the spring. The ticket note said rung one, the extension, 15:44, confirmed login, enrolled. The following Monday, Dan's password expired over the weekend and he reset it himself from the login screen at 08:20. Aisha knew only because the self-service log said so and because Dan did not phone. The manual reset is the part of the project that never finishes. And the measure of doing it well is that, one call at a time, it makes itself rarer.

Frequently Asked Questions