Verifying Identity Before You Reset Anything

Thursday, 11:50, at Redbrook Engineering. A chat message lands on the desk from an account called Mark Ellis, who is in sales. He is at a client's site and cannot get into his e-mail to send a quote. The client is apparently standing next to him waiting for it. "Can you reset my password? I can't use my phone for the code, it's in the car and I'm in a secure area. Just send it here, it's me." Aisha has been on the desk for eleven months and has reset perhaps two thousand passwords. She knows Mark; he came by the desk last month about a docking station. The chat account is his. The story is plausible, the tone is right, and the request will take her forty seconds. She has her hand on the mouse. Something she was told in her first week is tugging at her sleeve. It is this: the chat account being Mark's is not the same thing as Mark being on the other end of it.

Verifying identity is the step where the desk makes sure that the person asking for a reset is the person who owns the account. The desk uses something a stranger could not easily produce, before any credential changes hands. Verification is the one part of the password ticket where speed is not the goal. It is also the one part where a desk's natural helpfulness works against it. This article is part of our Password & Lockout Tickets series. It is written entirely from the defender's side. It says what to check, what never to accept, and what to do when you cannot be sure. It does not say anything that would help someone on the other side of the door.

It covers why the help desk is the easiest door and what a good check looks like. Next come the methods that count, what never counts as proof, and levels by account. Then it covers the urgent caller who cannot be verified, writing it down without writing the secret, and making the standard stick. It finishes with a short war story and the verification standard to copy.

The Help Desk Is the Easiest Door

Someone who wants into an organisation's systems does not need to break anything if a person will open the door for them. The help desk is staffed by people whose whole job is opening doors. That is not a criticism of the desk. It is a description of what the desk is for. And it is exactly why the reset request is the handle on the easiest door in the building. A reset gives the holder a working credential for an account that already has the access the real owner has. And the credential is handed over by a person who is measured on how quickly and kindly they hand things over. Every other door in the building has a lock. This one has someone who wants to be useful.

The request does not have to be clever to work. It has to be ordinary. Consider a stranger who sounds like a stressed colleague and knows the name of the person they are claiming to be. They ask for the thing the desk does fifty times a day. They are asking the desk to do its job. And a desk without a standard will do it. The defence is not suspicion of every caller, which exhausts the desk and insults the real users. It is a short, fixed check that the real user passes in under a minute and a stranger cannot pass at all. The check is applied every time, to everyone, including people the technician knows by sight. Especially those.

The standard protects the technician as much as the organisation. A technician who resets an account for a stranger after following the standard has done their job. The standard is what failed. A technician who resets an account for a stranger because the caller was convincing is the person the review will name. Aisha's hesitation is the standard working. The rest of this article is about making sure she does not need to feel it. That is because the sheet beside her will say what to do.

What a Good Check Looks Like

A good verification check has four properties. And a check that lacks any of them will either be skipped on busy days or passed by the wrong people. It is quick for the real user: under a minute, with nothing to remember and nothing to look up. It is hard for a stranger. It relies on something the real person has or can reach, not on something the real person knows. Most of what a person knows about themselves can be found out. It uses a channel the desk chose, not one the caller supplied. The desk calls a number already on file, or sends a code to a device already registered. It does not call back on the number the caller gave or reply to the message the request came from. And it leaves a record. The ticket says which check was used and when, without saying anything that would let the check be repeated by someone reading it.

The principle under all four is that the desk verifies through something already on file, never through something the caller offers in the moment. A phone number the caller reads out is not on file. A manager's name the caller mentions is not confirmation from the manager. An e-mail from the person's own address proves that someone has access to that mailbox. On the day the request is about a compromised account, that is exactly what you are trying to find out. The desk's records, the directory, the HR system, the registered device, are the ground the check stands on. If the ground is poor because the directory has no phone numbers in it, then fixing the directory is the first project. In that case, the standard says what to do until the directory is fixed.

The Methods That Count

Four methods satisfy the four properties on most desks. A desk needs at least two of them available so that there is a route for the person whose phone is in the car. The first is the call back. The technician ends the conversation and calls the person on the number held in the directory or the HR record. That is a desk extension or a recorded mobile. The technician does the reset on that call. The second is the one-time code. The directory or the identity system sends a code to the person's registered device or authenticator app. And the person reads it back to the technician. The third is confirmation from the manager. The desk reaches the manager on the manager's own known number or by a message to the manager's own account. The manager confirms that the person is who they say and has asked for a reset. The fourth is in person. The person is at the desk, or at a staffed reception point, with their photo badge. Someone looking at both the badge and the directory record checks one against the other.

Note what is common to all four: none of them asks the caller a question whose answer the caller could have looked up. The call back works because the stranger does not hold the phone. The code works because the stranger does not hold the device. The manager works because the manager is a second identity the desk already trusts, reached on a channel the desk already has. In person works because a face and a badge and a directory photo are hard to arrange at short notice. A desk that has all four available can verify almost anyone in a minute. A desk that has only one will meet the day when that one is unavailable. That is the day the standard is tested.

What Never Counts as Proof

There is a short list of things that feel like proof and are not. Each is either written down somewhere a stranger could read or easily guessed from somewhere they could. The employee number: it is on the badge, in the e-mail signature, on the payslip and in the HR system. And it was never meant to be a secret. The date of birth: known to friends, family, social media and every form the person has ever filled in. The name of the person's manager: on the organisation chart, the website and the out-of-office reply. Then there are the start date, the department, the job title, the office location, and the extension number. All of these are facts about the organisation, not about the person, and an organisation does not keep its facts in a vault.

Then the subtler ones. The voice: "I recognised him" is the sentence in more incident reports than any other. Recognising a voice on a bad line from someone you met once at the docking-station ticket is not recognition. The source address: a request from the person's own mailbox or chat account proves that whoever sent it can use that account. When the account has been compromised, that is the attacker, writing from the most convincing address they have. Internal jargon: knowing the name of the finance system or the nickname of the office printer shows familiarity. Familiarity is available to anyone who has read a few of the organisation's e-mails. And urgency, seniority, charm, irritation and the client standing next to them: none of these is a fact about identity. A standard that bends for any of them is a standard that a stranger needs only to perform.

The security questions that some systems still offer, "mother's maiden name", "first school", belong on this list too. The reason is the same as for the date of birth: the answers are facts about the person's life. A person's life is not private in the way a credential is. Where an organisation's own systems still rely on such questions, that is a conversation for the security function, laid out in Security Trade-offs in the self-service series. In that situation, the desk's standard does not accept them on their own in the meantime. A fact a stranger can look up is not a key. It is a label.

Levels by Account

Not every account needs the same check. A standard that treats a warehouse scanner login and the payroll administrator's account identically will be too heavy for one and too light for the other. Most desks need three levels. The ordinary account, which is almost everyone, gets one method from the table, usually the call back or the code, and the reset proceeds. The sensitive account gets two methods, one of which is the manager or in person. Sensitive means finance, payroll, HR, anyone who can approve payments or change bank details, shared mailboxes with an audience, and the executives. The damage from a wrong reset is larger, and a minute more is cheap. The privileged account means administrators, service accounts and anything that can change other accounts. It is not reset by the desk on request at all. It goes to whoever owns that account, with a change record, and the desk's role is to route it.

Write the level next to the account, or next to the role, so the technician does not have to decide under pressure. The directory can carry a note, or the knowledge base can hold the list of roles and their level. And the standard at the end of this article has a line for it. The question "which level is this?" should be answered by a lookup, not by a judgement. A judgement is what the urgent caller is counting on. The unlock, where the password is not changed, can sit one level lighter than the reset for the same account on many desks. That is because nothing new is handed over. But it still needs identity. Unlocking an account for a stranger who already has the password is handing over the door without the key. And some strangers have the key.

The Urgent Caller Who Cannot Be Verified

The hardest moment in the standard is the caller who is, in all likelihood, genuine and in real difficulty. Yet the desk cannot verify them by any method available right now. The phone is in the car, the manager is on leave, the site is two hours away, and the client is waiting. The answer is that the reset does not happen until a method is available. The technician says so kindly, says what will work, and stays on the problem. "I can't reset it from here without a check I'm able to do, and I'm not able to skip that for anyone. The fastest route is the code to your phone when you can get to it, which takes a minute; or I can reach your manager on her desk number and do it on her say-so; or reception at the Hadley site can check your badge and ring me. Which of those is quickest for you?"

Two things follow from the way that sentence is built. The first is that the real user almost always accepts it. The sentence offers three routes and a timescale and treats them as a person with a problem rather than a suspect. The second is about a caller who, offered three routes, rejects all three and returns to pressure. They raise their voice, invoke a director, or explain at length why the standard does not apply to them. That caller has told the technician something. In that case, the technician should not reset the account and should write the conversation on the ticket. That is not an accusation; genuine people under stress push too. It is simply that the standard's answer is the same either way. And the record of a failed verification is a security data point that whoever owns security will want, as Other Security Tickets the Desk Will See describes.

Seniority is the special case of urgency, and the standard's answer does not change. A director who cannot be verified is not verified. And the technician does not need to decide whether to make an exception, because the exception is not theirs to make. Saying no to someone above you really means sending the decision to its owner while offering what you can do. That is the subject of Saying No Upward. Here it is enough that the standard names the person who may grant an exception. The desk technician is never that person. A standard with a quiet exception for senior people is a standard that tells a stranger whom to impersonate.

Writing It Down Without Writing the Secret

The ticket records that verification happened, which method was used, and who confirmed. It records nothing that would let the verification be repeated by someone reading it. "Verified by call back to the directory mobile at 11:58" is a record. The mobile number itself is not needed on the ticket, since it is in the directory. "Code sent to registered authenticator, read back correctly" is a record; the code is not. "Confirmed by manager Dana on her desk extension" is a record. The temporary password that follows the verification is never on the ticket, for reasons the reset article in this series spells out. And the broader list of things that should never be written in any ticket is in What Never to Write in a Ticket.

Keep the verification record where the requester cannot see it. The requester does not need to know which number the desk holds for them or which method was chosen. If the requester is not who they said, telling them which check they failed is a lesson you do not want to give. If you run QuerySolv, the internal note on the ticket is the place. The desk sees it; the requester never does. The note never carries the code or the password. In any tool, the same split applies: a private note for the method and a public reply for the outcome. The public reply says only that the reset was done after verification.

Record the failures as carefully as the successes. A ticket that says "requester could not be verified; offered call back, manager and in person; requester declined all three and ended the chat at 12:04" is the most useful ticket on the desk that week. It is the only trace of an attempt that may be repeated, against a different technician, tomorrow. Flag it to whoever owns security the same day. Nobody will thank the desk for the ones it stops, which is the nature of the job, and the ticket is how the desk thanks itself.

Making the Standard Stick

A standard that lives in a policy document is a standard that is read once, by its author. The one that works is a single page beside the phone. It is in the knowledge base where technicians can find it in three seconds. It is also in the first week's training for every new technician. The sentence for the unverifiable caller is rehearsed aloud until it stops feeling rude. The standard is owned by the security function if the organisation has one and by the desk lead if it does not. It is reviewed when the methods change: when the directory gains phone numbers, when the authenticator rolls out, when a site loses its staffed reception. The version date goes on the page. The old versions go in the bin.

Then check that it is being used, because every standard decays under load and this one decays on Monday mornings. Once a month, read a sample of reset tickets, twenty or so, and look for the verification line. A ticket without one was either a reset done without a check or a check done without a record. Both are corrected with a conversation, not a reprimand. Count the failed verifications and read each one. Count the exceptions, who granted them and why, because an exception that recurs is a gap in the methods, not a gap in the people. The desk-side script that walks a technician through the reset call step by step, including the verification rungs, is in The Manual Reset, Done Safely. This standard is the policy that script applies. The script is what the technician holds. The standard is what the technician is held to.

A Short War Story: The New Finance Manager at Greyfield Timber

At Greyfield Timber, a sawmill and merchant with a two-person desk, a caller rang on a Friday afternoon claiming to be Ruth. Ruth was the finance manager who had started a fortnight earlier. The caller said her phone was in a locker on the mill floor. She said she needed her password reset to approve a supplier payment before the bank's cut-off. The caller had Ruth's employee number, her start date and the name of her manager. All three were in the welcome announcement that had gone to the whole company. And the technician, Ben, who had never spoken to Ruth, accepted them as proof and did the reset on the call. Within the hour a forwarding rule had been set on the mailbox. Within that hour, a supplier had received a polite request from Ruth's address to update the bank details on file. The supplier's own accounts clerk queried the request by phone, which is the only reason it stopped there. The firm's security contractor spent three days on the mailbox, the forwarding rules across every account and the audit of what had been read. The desk and the finance team lost around sixty hours between them. The supplier payment was late anyway. Everything the caller knew had been published by Greyfield itself, to everyone, a fortnight before. Nothing they knew was proof, and nothing Ben had been given told him the difference.

The Verification Standard

The standard below is the one Greyfield wrote the following week, and it is a page, not a policy. Section one is the rule in two lines. Section two is the methods, in order of preference, with a box to mark which are available on this desk today. Section three is what never counts, kept short so it is remembered. Section four is the three levels, with the roles that belong to each filled in for your organisation. Section five is the unverifiable caller, with the sentence to say and the person who may grant an exception named. That way, the technician never has to decide. Section six is the record. Date it, put it beside the phone, and read a sample of tickets against it every month.

IDENTITY VERIFICATION STANDARD — ONE PAGE, BESIDE THE PHONE
Desk: ______________________   Owner: ______________   Version date: ____________

1. THE RULE
   No reset, unlock or credential change without verification by a listed method.
   Verify through something already on file. Never through something the caller supplies now.

2. METHODS THAT COUNT  (available on this desk today: tick)
   [ ] A. Call back to the number held in the directory or HR record; reset on that call
   [ ] B. One-time code to the registered device or authenticator, read back to the desk
   [ ] C. Manager confirms, reached by the desk on the manager's own known number or account
   [ ] D. In person at the desk or staffed reception; photo badge checked against the record
   If the directory holds no number for the person: methods B, C or D only.

3. NEVER COUNTS, ALONE OR TOGETHER
   Employee number, date of birth, start date, manager's name, department, job title,
   extension, home address, security-question answers, a recognised voice,
   a request from the person's own mailbox or chat account, internal jargon,
   urgency, seniority, or a number the caller gives you to call back on.

4. LEVELS  (fill in the roles for this organisation)
   Ordinary account ...... one method from A to D         Roles: everyone not listed below
   Sensitive account ..... two methods, one of them C or D  Roles: ____________________________
   Privileged account .... not reset by the desk; routed to ______________ with a change record
   Unlock without reset .. same level as reset for sensitive and privileged; one method otherwise

5. THE CALLER WHO CANNOT BE VERIFIED
   Say: "I can't do this without a check I'm able to do, and I can't skip it for anyone.
         The routes that will work are ______, ______ or ______. Which is quickest for you?"
   Do not reset. Offer the routes. Stay on the problem.
   Exceptions may be granted only by: ______________ (role), recorded in the ticket in their words.
   A caller who declines every route and returns to pressure: record it, do not reset,
   flag to ______________ (security owner) the same day.

6. THE RECORD  (internal note, never visible to the requester)
   Method used: ____   Confirmed by / to: ______________   Time: ______
   Never on the ticket: the code, the temporary password, the full number called.
   Failed verification: what was offered, what was declined, when the contact ended.

MONTHLY CHECK: read ____ reset tickets; count those without a verification line: ____
               failed verifications this month: ____   exceptions granted: ____ by ______

Aisha, in the end, typed back to Mark's chat account: "Happy to sort this. I'll ring you on the mobile we've got for you in a minute, or if you're in the secure area with no signal, I can get Dana to confirm on her extension and do it then. Which is better?" The reply came thirty seconds later: "Dana's fine, I'm at my desk actually, the client went for coffee." Dana confirmed on her extension that Mark was sitting across from her. The reset took forty seconds, as it always would have. The check had taken two minutes. And it had been worth every one of them, including the ones where it turned out to be Mark.

Frequently Asked Questions