The Password Reset Itself, Done Properly Every Time

Wednesday, 14:05, at Acme. Leo has been on the desk for four months and is good at it. Sunita in procurement has forgotten her password. Leo has verified her by calling the extension on file. Now he does the part he has done a few hundred times. He sets the password to the temporary one he has been using all week. It is the name of the month with some punctuation on the end. He types it into the reply on the ticket so she has it in writing. "All sorted, your new password is below, let me know if there's anything else." Sunita signs in. The ticket closes. Nobody has done anything that felt wrong, and three things are now true that should not be. A working password is sitting in a ticket that every technician, and the contractor doing the system migration, can read. Sunita was not asked to change it, so she will not. And her phone, which has the old one, will lock her account at about half past four.

A reset done properly leaves the person with a password only they know and every device they own working. It leaves a ticket that proves the reset happened without containing anything a stranger could use. The reset is the part of the password ticket that looks like the whole job and is in fact the middle third of it, after the verification and before the follow-up. This article is part of our Password & Lockout Tickets series. It assumes the identity check in Verifying Identity Before You Reset Anything has already been passed. Nothing below happens before that.

It covers reset against unlock and the temporary password and the forced change. Next come handing it over through a safe channel and telling the person where else it will break. Then come the note on the ticket without the secret and the follow-up that confirms it worked. After that come the hand-off to self-service; shared, service and privileged accounts; and a short war story. Last comes the reset reply to copy.

Reset, Unlock, or Both

The first decision is whether the account needs a reset at all. A reset replaces the password with a new one. An unlock reopens an account that has been locked by too many wrong attempts and leaves the password as it was. A person who knows their password and is locked out needs an unlock. Giving them a reset instead makes their day worse. Now they have a temporary password to remember, a new one to choose, and a phone that still holds the old one. That leads to the recurring lockout described in The Lockout That Keeps Coming Back. A person who has forgotten the password needs a reset, and if the account is also locked, the unlock goes with it. Ask "do you know your password?" before anything else, and believe the answer.

The second decision is whether the password has merely expired. An expired password is one the person knows and the policy has retired. Most systems will let the person choose a new one at the sign-in prompt without the desk doing anything. Walking them through that prompt is better than a reset. That is because the new password is theirs from the first second and the desk never knew it. The reset is for the case where the person cannot get to a prompt or has nothing to type into it. On a good desk, a noticeable share of "reset" tickets end without a reset, which is not the desk being lazy. It is the desk declining to know a password it did not need to know.

The Temporary Password and the Forced Change

When a reset is needed, the desk sets a temporary password. This is a password that exists only to get the person to the screen where they choose their own. It has three properties. It is random: generated, not thought up, not the month and some punctuation, not the same one the technician used yesterday. It is unique to this reset: never reused for the next person, never a pattern the desk has settled into. A pattern that the desk knows is a pattern a leaver from the desk also knows. And the temporary password is marked must change at next sign-in, the directory setting that forces the person to replace it the moment they use it. That way, the temporary password is dead within a minute of being born.

The forced change is the step most often skipped and the one that matters most. Without it, the temporary password becomes the permanent one, because nothing told the person to change it and people do not change passwords for fun. A password two people know is not a password. It is a rumour, and it stays a rumour for as long as the account lives. With the forced change, the technician knew the password for the length of a phone call. Then nobody but the person knows it. That is the only state an account should be in. Set the forced change every time. If your directory cannot force a change, stay on the call until the person has made one, and say so in the ticket.

The temporary password should also be short enough to read aloud and long enough to be safe, because it will be spoken, not typed. A thirty-character string read over a bad line is a reset that takes four attempts and locks the account on the third. Most desks settle on a few random words or a short random string, read in groups, and the person types it once. It does not need to be strong enough to last a year. It needs to be strong enough to last the ninety seconds before it is replaced.

Handing It Over Through a Safe Channel

The temporary password goes from the technician to the person by voice, on the verified call, or in person, and by no other route. Not in the reply on the ticket, which is readable by everyone who can read the ticket, now and in every export of it for the rest of time. Not by e-mail, which goes to a mailbox the person cannot open because that is why they rang. E-mail is in any case the channel most likely to be the one that was compromised. Not by chat, which keeps a history on every device the chat account is signed in to. Not by text message to a number the caller gave you, which is the caller choosing the channel. And not on a sticky note left on the desk, which I mention only because I have seen it, twice, on the same desk.

Reading it aloud works because it is instantaneous, leaves no copy, and happens on a channel the desk chose when it verified the person. Read it twice, in groups of three or four characters, say which letters are capitals, and have the person read it back. Then stay on the line while they sign in and change it. The in-person case is the same with a whisper instead of a phone. Or the technician can type the temporary password at the person's keyboard and turn away while they choose their own. Either way the temporary password exists for about a minute and is never written anywhere by anyone.

Remote workers and people at other sites get the same rule by a slightly longer route. There is the call back to the number on file or the one-time code to the registered device. Or, where the organisation has it, there is the self-service system's own channel. That channel hands the person a reset without the desk ever knowing a password at all. Where none of those reaches the person, the manager can be the channel, in person. In that case, the reset is done on a call to the manager's known number while the person sits beside them. What the desk never does is take the person's word for a channel. "Just e-mail it to my personal address" is not a channel. It is a request to put the password somewhere the desk cannot see.

Telling the Person Where Else It Will Break

The sentence that prevents tomorrow's ticket is the one about the phone. When the person changes their password, every device and saved session that held the old one keeps offering it. After a few offers the account locks. The desk knows this; the person does not, because nothing on the sign-in screen mentions their phone. So the reset includes a warning, spoken on the call and repeated in the reply on the ticket: "Your phone and anything else that has your work e-mail on it still has the old password. Update it now, before you put the phone down, or switch the phone off until you can, or it will lock you out this afternoon." The warning takes ten seconds. Its absence costs an unlock, a second ticket and the person's confidence in the first one.

List the places rather than hoping the person thinks of them. They include the phone's mail app, a tablet, a second computer at home or in another office, a browser or application that remembered the password, and a mapped drive or printer with a saved credential. The order to deal with them is the main computer first, so the new password is proven to work. Then comes the phone immediately, because it retries most often. Then come the rest as they are found. The six places and the fix for each are the subject of the lockout article in this series. The reset reply at the end of this one carries the list so the technician does not have to recite it from memory on the fortieth reset of a Monday.

Say it even when the person says they do not have work e-mail on their phone. People forget the tablet. People forget the laptop at home. The warning costs nothing when it is unnecessary and saves a ticket when it is not. The desk that includes it in every reset reply sees its recurring lockouts fall without doing anything else. This is the cheapest layer in the layered plan this series ends with and the one to do first.

The Note on the Ticket Without the Secret

The ticket records that the reset happened, how the person was verified, what was set, what the person was told, and when the desk will check back. It records none of the secrets involved. The temporary password is never on the ticket, in a note, in a reply, in a field, in an attachment or in the subject line. The one-time code is never on the ticket. The full phone number called is not needed, since the directory holds it. What the ticket says instead is a line like this: "Verified by call back to directory mobile. Reset to a random temporary password, must change at next sign-in set, account unlocked. Temporary password read aloud on the call, not recorded. Person signed in and changed it while on the call. Warned about phone, tablet and saved sessions. Follow-up tomorrow morning."

Keep the method and the private detail in an internal note, and keep the public reply to the outcome and the warning. If you run QuerySolv, the internal note is visible to the desk and never to the requester. In that setup, the public reply is what the person reads. So the split is already there to use. The note carries how the person was verified. The reply carries what they need to do next. Neither carries anything a stranger could use. In any tool, the same two layers exist in some form, and the rule is the same: the ticket proves the work without repeating the secret. The wider list of things that never belong in any ticket, from passwords to personal remarks about the requester, is in What Never to Write in a Ticket.

The reason to be strict about this is that a ticket is a document with a long life and a wide audience. It is read by every technician, exported for migrations, shared with contractors, searched by auditors, and kept for years after everyone who wrote it has left. A password written in a ticket is published to every one of those readers. The forced change is the only thing that stops the publication mattering. A desk that both writes the password in the ticket and skips the forced change has published a working credential. I have seen that combination more often than any other mistake in this series.

The Follow-Up That Confirms It Worked

The reset is confirmed when the person has signed in with the new password they chose, on the main computer, and the account has not locked again. The best confirmation is to stay on the call for the sign-in and the change, which takes a minute and turns "it should work now" into "it works". When the call cannot last that long, the ticket is not closed on the reset. Instead, it is resolved with a reply that asks the person to say if anything is still wrong. In that case, a follow-up is set for the next morning. That is when a missed phone will have locked the account. A ticket closed at the moment of the reset is the desk declaring success before the evidence is in.

The reply to the person is the public half of the reset. It confirms the reset was done after verification, repeats the device warning in writing, says what to do if the account locks again, and invites a reply. If you run QuerySolv, a reply from the person to that message reopens the resolved ticket. So "still locked out" comes back onto the same ticket with its history rather than starting a fresh one with none. Most tools do something similar, and where yours does not, the follow-up the next morning is how the desk finds out. The thinking behind resolving with an invitation rather than closing in silence is in Avoiding the Silent Close. This thinking applies to the reset exactly as it applies to everything else.

The follow-up also catches the second system. A person whose directory password was reset and who then rings back because "the finance system still won't take it" has not had a failed reset. They have a second credential on a second clock, and the follow-up is where that is discovered and routed. Note it on the ticket and on the list of systems with their own password, which the census in the first article of this series starts. The reset worked. The organisation has more passwords than the person knew.

The Hand-Off to Self-Service

The reset call is the best moment the desk will ever have to enrol the person in self-service reset, where the organisation has it. That is because the person is signed in, on the phone with a technician, and freshly reminded of what forgetting a password costs. Self-service reset is a feature of the directory or the identity system, not of any help desk tool. The project of putting it in place, with the enrolment campaign that decides whether it is used, belongs to the self-service series and is not repeated here. The desk's part is one sentence at the end of the call: "While you're signed in, can I get you set up so you can reset this yourself next time? It takes a minute and you won't need to wait for us."

Most people say yes. The ones who say no are usually in a hurry. The reply on the ticket carries the link to the enrolment article in the knowledge base so they can do it later. Either way, record it: enrolled on the call, already enrolled, declined, or cannot because the person has no registered device. The last of those is a line for the enrolment project rather than for the desk. It is a useful one, since the people who cannot enrol are the people whose resets will remain manual for good.

Shared, Service and Privileged Accounts

Not every reset request is for a person's own account, and the three other kinds each need a different answer. A shared account, such as a mailbox used by a team or a login on a kiosk, has several people who know the password. Resetting it on one person's request locks out the rest. The reset needs the account's named owner to agree. Every user must be told the same day through a safe channel each. The ticket needs a note of who was told. A service account, one that a scheduled task, a backup job or an application signs in with, breaks whatever it runs the moment the password changes. Its reset is a change, planned with whoever owns the thing it runs, and never done on a call because somebody has been locked out. A privileged account, one that can change other accounts, is reset by whoever owns it under whatever the organisation's rules are for such accounts, with a record. The desk's role is to route the request and refuse to do it on the spot, however senior the voice asking.

The common thread is that the person asking is not the only person affected, so the person asking cannot be the only person consulted. Which of these changes needs a review before it is made belongs to the change management series in this library. The reset article's contribution is simpler. If more than one person or one process depends on the password, it is not a reset ticket. It is a change with a reset inside it, and it is done on the change's timetable, not the caller's.

A Short War Story: The Reply at Larkspur Dental

Larkspur Dental was a group of four practices with one technician, Owen. A dentist called Hana rang between patients to say she had forgotten her password. Owen had verified her and was in a hurry himself. He reset it and typed the temporary password into the ticket reply so she could read it from the screen when she had a moment. He did not set the forced change because she was busy and would "sort it later". She used the temporary password for the next five months. During those months the practice's ticket history was exported, with every reply in it, and shared with an outside contractor migrating the booking system. The contractor's laptop was later stolen from a car. The practice had to treat Hana's account, which held patient correspondence, as compromised. The reset that followed took five minutes. The remaining work included the mailbox review, the forwarding-rule audit and the check of what had been accessed. It also included the notification to the practice's regulator about a possible exposure of patient data. Together, that work took about forty hours and a fortnight of the owner's attention. A password written in a ticket is a password published to everyone who will ever read that ticket. A ticket has more readers than anyone expects.

The Reset Reply

The template below is in two parts, and the two parts go in two different places. Part one is the internal note, written for the desk, carrying the verification method, what was set and what the person was told, and never the secret. Part two is the public reply to the person, carrying the confirmation, the device warning, the self-service hand-off and the invitation to reply. It has blanks for the names and times and no blank for the password, because the password is never in it. Write part one as the reset is done, send part two on the same call, and set the follow-up before closing the ticket window.

THE RESET REPLY — INTERNAL NOTE AND PUBLIC REPLY
Ticket: ________   Account: ______________________   Technician: ______________

PART 1 — INTERNAL NOTE  (desk only; never visible to the requester)
   Request: [ ] forgotten  [ ] expired, could not change at prompt  [ ] locked, password known -> unlock only
   Verified by: [ ] call back to directory number  [ ] code to registered device
                [ ] manager ______________ on own number  [ ] in person, badge checked
   Action: [ ] random temporary password set  [ ] must change at next sign-in set  [ ] account unlocked
   Temporary password handed over by: [ ] voice on verified call  [ ] in person   -- not recorded anywhere
   Person changed the password while on the call: [ ] yes  [ ] no -> follow-up set for ______
   Warned about: [ ] phone  [ ] tablet  [ ] second computer  [ ] saved sessions  [ ] drive or printer
   Self-service: [ ] enrolled on the call  [ ] already enrolled  [ ] declined  [ ] cannot: no registered device
   Other systems with their own password mentioned: ______________________

PART 2 — PUBLIC REPLY TO THE REQUESTER
   Hello ______________,

   Your password has been reset after we confirmed it was you by ______________.
   You have signed in and chosen your own new password, and the temporary one no longer works.

   One thing to do straight away: anything else that has your work e-mail or sign-in saved
   still has the OLD password and will lock your account if it keeps trying. Please update
   the new password on:
     - your phone's mail app
     - any tablet with work e-mail on it
     - any other computer you use, at home or in another office
     - any app or website you stay signed in to for work
     - any drive letter or printer that asked you for a password
   If you cannot do these now, switch the device off until you can.

   If the account locks again, reply to this message and we will find the device that is
   still trying; you will not need to go through the reset again.

   To reset your own password next time without waiting for us: ______________________

   Regards,
   ______________, IT Service Desk

   Follow-up set for: ______   Close only after: sign-in confirmed and no lockout by ______

Leo's reset for Sunita, redone the proper way the following week after the desk lead had read the ticket, took three minutes instead of one. The extra two were the random password read aloud, the forced change, the wait while she chose her own, and the sentence about the phone. She updated the phone while he was still on the line. Her account did not lock at half past four. The ticket said what had been done and contained nothing anyone could use. The contractor doing the migration read it, as contractors do, and learned nothing from it except that Acme's desk knew what it was doing.

Frequently Asked Questions