The Desk's Own Security Habits: Being the Example People See

Tuesday, 11:20, at Bluewater Bank. The support desk sits in the open-plan area by the lifts, with two technicians behind a counter. Somebody once decided IT should be visible. Jess is halfway through a reset for a teller when a laptop arrives for collection. She walks the six metres to the cupboard with the administration console still open on her unlocked screen. A branch manager, waiting for the lift, watches her go. He says nothing. Three weeks later the same branch manager leaves his own screen unlocked for an hour with a customer file open. The desk raises it, gently. He says, with no malice at all, "IT does it."

He was right, and that is the problem. Nobody at Bluewater had read the acceptable-use policy in years. But everybody had watched the desk, because the desk was by the lifts and because it was IT. Whatever the desk did was, as far as two hundred people were concerned, what IT thought was fine. Jess's six metres had been a policy decision. She just had not been told she was making one.

The desk's security habits are the small, visible things technicians do all day. How they check who is asking. What they write in the ticket. Which account they are signed in as. Whether the screen is locked when they stand up. How they ask before they connect to somebody's machine. None of them is a project and all of them are watched. This article is part of our The Helpdesk's Role in Security Culture series. It is about the desk as the example everybody can see. That is the one part of security culture the desk controls completely.

It starts with why the desk is the example, the verification standard kept when it is awkward, and the note that never carries a secret. Then come admin accounts with one person and one purpose, the locked screen and the tidy desk, and remote sessions with consent. Next are what to do with the things users hand the desk, the day the desk itself is the target, and making the habits stick. A short war story and the desk security habits checklist to copy finish the article.

Why the Desk Is the Example

The desk is the most watched team in the building, and the one whose behaviour is read as a statement of what is allowed. A technician who props a door open is not a person propping a door; they are IT saying the door does not matter. A technician who reads a temporary password aloud across the floor has told every teller within earshot that passwords are said aloud. Nobody consciously decides to copy the desk. They simply assume that the people who wrote the rules know which ones are real.

This cuts both ways, which is the useful part. A desk that is seen to check identity on every reset, including for the managing director, teaches the organisation that nobody talks their way past the desk. That lesson reaches the person who would otherwise have tried. A desk that asks permission before every remote session teaches people what a legitimate session looks like. That is the only defence most of them have against an illegitimate one. The same visibility that makes the desk's shortcuts expensive makes its habits free training.

The habits in this article are therefore not about the desk's own risk, though that is real. They are about what the desk teaches by being watched. Every one of them is something a user can see or hear. The test for each is the same: if a requester watched you do this, what would they conclude was normal? A desk that asks that question of itself has most of security culture in hand. The rest is paperwork, and the paperwork is somebody else's.

The Verification Standard, Kept When It Is Awkward

The desk is the easiest door into an organisation, and the password reset is its handle. That is why the verification standard in Verifying Identity Before You Reset Anything exists. That article owns the standard; this one is about keeping it when it is awkward. The awkward cases are the ones people watch. The chief executive on the phone, audibly busy. The colleague from the next floor whose voice you have known for five years. The director's assistant asking for a reset for the director. Each of these is where a desk quietly stops checking, and each is exactly the case the standard was written for.

The sentence that makes it bearable is "I know it is you, and I am still going to check, because that is what we would do for anyone". Said warmly and every time, it stops being an insult within a week and becomes a thing people mention approvingly to each other. The chief executive, in my experience, is the easiest sell: nobody is more aware of being impersonated than the person whose name is on the fake e-mails. The hard sell is the colleague, and the way through is to check so routinely that checking stops being a comment on anyone.

What the floor sees is a desk that cannot be talked past, and that is worth more than the check itself. A person planning to try their luck with "I'm ringing on behalf of" has usually heard, from someone who was checked, that the desk checks. The verification standard protects the account on the day; the habit of being seen to apply it protects every account on every other day.

The Note That Never Carries a Secret

A ticket note never holds a password, a one-time code, a recovery answer, a card number, or any personal detail beyond what the ticket needs. The reasons are in What Not to Write in a Ticket. The habit that keeps the rule is writing what was done rather than what the secret was: "temporary password set, given by phone after verification, change forced at next sign-in". That line tells the next technician everything they need and tells a stranger reading the ticket in three years nothing useful. The reset itself, and how the temporary password travels to the user, is in The Reset Itself, Done Properly.

The internal note is not a safe place either, however tempting it looks. A note marked internal is hidden from the requester and visible to every agent, every future agent, every export and every audit, for as long as the ticket exists. If you run QuerySolv, both the public reply and the internal note sit in the ticket's event history permanently. That is exactly what you want for everything except a secret. A password written once in a note has been written forever. Treat "internal" as "not for the requester", never as "private".

The habit extends to what users send. A requester who e-mails "my password is Summer2 and it isn't working" has put the secret in the ticket for you. The desk's reply, in the same thread, says "please change that password now, since it has been sent by e-mail, and never send us one again; we never need it". Then the desk does what its tool and its policy allow to keep that line from living on. Some tools let a note be edited or redacted; many do not. Check yours. In either case the reply is the part that teaches.

Admin Accounts: One Person, One Purpose

Every technician has two accounts. The everyday one is for e-mail, the ticketing tool and the web. The administrative one is used only for the task that needs it, then signed out of. The everyday account reads mail, which means it opens attachments, which means it is the account most likely to be tricked. The admin account never reads mail, never browses, and never stays signed in on a screen somebody might walk past. On a desk of two this feels like ceremony. It is the single habit most likely to limit a bad afternoon to one account instead of all of them.

The shared administrative password is the habit's opposite, and almost every small desk has one. It is the account "everyone" uses for the thing that only takes one login. Its password was set by a technician who has since left. Nobody has changed it because changing it means telling everyone. Shared admin credentials mean nobody can say who did what. That is the same argument the desk uses when refusing a shared account to a user, and the floor notices the difference. Where a shared account genuinely cannot be avoided, it has an owner, a register of who knows the password, and a change on the day anyone on that register leaves.

The leaver is where admin discipline is tested, because the desk's own leavers have the most access of anyone. The disable-first routine in The Offboarding Checklist: Disable First, Delete Later applies to the technician who leaves exactly as it applies to the sales manager. Add the shared passwords they knew and the unattended-access entries in their name. The principle underneath all of it is that an account has the access its work needs and no more. That is argued in Least Privilege Under Pressure. The desk is not exempt from it because it wrote the rule.

The Locked Screen and the Tidy Desk

Lock the screen when you stand up, every time, for any distance, including the six metres to the laptop cupboard. It is one keypress and it is the habit the whole floor can see. A desk that locks every time teaches the floor that locking is normal; a desk that does it mostly teaches the floor that it is optional. Set the automatic lock short as a backstop and treat the backstop as failure: if the screen locked itself, you forgot.

The tidy desk is the same habit in paper. The printed list of new-starter accounts with temporary passwords. The whiteboard with the guest wireless password that was changed twice but the whiteboard once. The delivery note with a serial number and a user's name. The sticky note. Everything on the desk's surface is readable by everyone who approaches the counter, and the counter is approached all day. The rule is that nothing on the surface would matter if a stranger photographed it. The way to get there is to clear it at lunch and at the end of the day until nothing accumulates.

Sound carries further than paper. The temporary password read aloud across the floor. The verification question answered at a volume the queue can hear. The phone call on speaker while a visitor waits for a meeting. The habit is to lower your voice for anything you would not write on the whiteboard. Hand the user the temporary password in a way that only they receive. The desk by the lifts has the hardest version of this problem, and I have some sympathy. Somebody put the one team that handles everyone's passwords in the one place everyone walks past.

Remote Sessions With Consent, Every Time

The desk asks before it connects to anybody's machine and says what it is about to do. It keeps the session visible and tells the user they can end it at any moment. The routine, including the words to use, is in Consent, Every Time. The note that records the session is in Logging and Session Records. This article adds only the reason the habit matters beyond the session. The user who has been asked permission fifty times knows what a legitimate support session looks like. They will recognise the one that does not ask.

The exception is the moment the habit is tested. The user is on the phone, in a hurry, says "just connect, I don't mind", and the technician is tempted to skip the words. Say them anyway, in ten seconds: "I'm going to connect now, you'll see a prompt, and you can close it whenever you like". The user who said they did not mind has just been shown the standard. The next time somebody connects without asking they will know something is wrong. Consent that is skipped when the user is relaxed is consent the user will not expect from anyone.

Unattended access to servers and to workstations out of hours is a separate arrangement with its own register and approvals. The desk keeps it as a written exception rather than a convenience. The policy lives in The Unattended Access Policy. The habit, for the technician, is that an unattended session is logged the same way as an attended one. That way the question "who was on that machine at nine on Sunday night?" has an answer that is not a shrug.

What Users Hand the Desk

Users hand the desk things all day, and each one is a small test of discipline. The USB stick found in the car park is not plugged into a desk machine to "see what is on it". It goes in the drawer with a tag and the security contact is told, as Other Security Tickets the Desk Will See describes. The laptop handed over for repair has the user's photographs and their bank's website in the history. There is a document called "redundancies" on the desktop. The technician looks at none of them, because the ticket is about a fan. If the user asks whether you saw anything, the honest answer is that you did not look, and that answer is the habit.

The mailbox is the hardest version. A manager asks the desk to "just check" a leaver's mailbox for a customer's message, or their own mailbox for something they cannot find. The desk reads what the ticket needs and nothing else, in a way that leaves a record of what was opened. Where a request would mean reading somebody else's mail in bulk, it goes to the person who can approve that. That is not the desk. The arrangements for a leaver's mail and files are in The Leaver's Data and Mailbox. Technicians can see almost anything, which is why the habit of not looking is the one people most want to be sure of.

When the Desk Itself Is the Target

The desk receives its own share of convincing requests. The habit that handles them is the same verification standard applied to everyone who asks the desk for anything, not only to users asking for resets. The call from "the vendor" who needs the administrator password reset to finish a support case. The "new starter" who needs access this morning and whose record has not arrived from HR yet. The e-mail from a director asking for a reset to be done for a named person who is "in a meeting and cannot ring". Each of these may be entirely genuine, and each is exactly what an attempt to use the desk as a door would look like.

The response is the standard, politely and without apology. Confirm through a contact the desk already holds, not through the one offered in the request. Refuse what cannot be confirmed. Record what was asked and by whom. Tell the security contact about any request that failed verification. An attempt on the desk is a signal in its own right and goes on the sheet from Spotting Incidents Early From the Queue. The desk does not try to work out who was behind an odd request. It notes the facts and moves on, which is both safer and quicker.

Making the Habits Stick

Put the checklist on the wall, where the desk and the floor can both read it. A visible standard is itself a habit the floor copies. The checklist at the end of this article is one page and it is written as what the desk does, not what it must not do. New technicians walk through it in their first week with somebody who has kept it for a year. This is part of the standards that The New Technician's First Thirty Days sets out. They watch it done before they are asked to do it.

The desk checks itself, monthly, as a desk and never as a tally of individuals. Ten minutes at the end of a month: has every reset this month got a verification line in its note? Any secrets found in notes? Any shared password past its change date? Any session without a record? The answers go in a note for the desk lead and into the working agreement with the security function. That agreement is described in the next article in this series. It is where the security function's occasional look at the desk's habits is agreed. The point of the self-check is to find the habit that has slipped before somebody else does.

When a habit slips, fix the habit and not the person. The technician who sees a colleague's unlocked screen locks it, says nothing in front of users, and mentions it later in private. The desk lead who finds a password in a note deals with the note. Then they ask what made the line feel necessary, because the usual answer is a gap in the tool or the process. Nobody's name goes on a wall for forgetting to lock a screen. The desk that runs its own habits without blame has just taught the floor the previous article in this series by example. That is the only way the floor was ever going to learn it.

A Short War Story: The Sticky Note at Bellweather Logistics

The warehouse desk at Bellweather Logistics had a shared terminal for printing labels. Under its keyboard, for about two years, there was a sticky note with the administrator password for the label server written on it in a confident hand. It had been written by Dean, a technician who had wanted the night shift to be able to restart the service without ringing him. Dean had left the company eight months before anybody thought about the note again. The person who thought about it was the auditor, on the first morning of the annual audit. He lifted the keyboard to plug in a laptop and read the note aloud. He found that the rest of the control environment was no longer the most interesting item on his list. The cost was every administrative password in the company changed over one weekend, about twenty hours of two technicians' time. There was a finding that followed the desk into every management meeting for a year. And the uncomfortable fact that Dean's access had been disabled on his last day and his password had not. The lesson Bellweather wrote into its checklist was that the desk's habits were the organisation's security policy, whatever the policy document said. The document had never been under the keyboard.

The Desk Security Habits Checklist

The checklist below is the one Bellweather put on the wall the following month. It is written as what the desk does. The first section is every ticket; the second is every day. The third is the monthly self-check, and the last is what happens when a habit slips. Rewrite it for your desk, keep it to one page, and put it where the floor can read it too. The floor reading it is half the point.

THE DESK SECURITY HABITS CHECKLIST — ON THE WALL, ONE PAGE
Desk: ______________________   Checklist owner: ______________________   Last reviewed: ____________

ON EVERY TICKET
  [ ] Identity checked before any reset, unlock or access change, whoever is asking
  [ ] The note says what was done and how the secret was handed over; never the secret itself
  [ ] A secret sent to us by a user: reply "change it now, and never send us one again"
  [ ] Remote session: asked first, said what we will do, user told they can end it; session noted
  [ ] Looked only at what the ticket needed on any device or mailbox we were given
  [ ] Any request that failed verification: refused politely, recorded, security contact told

EVERY DAY
  [ ] Screen locked every time we stand, for any distance
  [ ] Admin account used only for the admin task, signed out after; never for e-mail or the web
  [ ] Counter and desk surface clear of anything a stranger could photograph
  [ ] Low voice for anything we would not write on the whiteboard
  [ ] Found devices in the drawer with a tag; nothing plugged in "to see"

MONTHLY SELF-CHECK (ten minutes, the desk as a whole, no names)
  [ ] Every reset this month has a verification line in its note
  [ ] No secret found in any note or reply; any found is handled and the cause asked about
  [ ] Shared passwords: owner named, register current, changed since the last leaver
  [ ] Every remote session this month has a record
  [ ] Unattended access register matches who still works here
  [ ] One line to the desk lead and to the security contact: what slipped, what was fixed

WHEN A HABIT SLIPS
  Lock the screen; say nothing in front of users; mention it later, in private.
  Fix the note, then ask what made the line feel necessary.
  Change the password, then fix the register that let it go stale.
  No names on the wall. The desk runs its own habits without blame.

WHO WE TELL WHEN SOMEONE TRIES THE DESK AS A DOOR
  Security contact: ______________________   Reach them by: ______________

Jess locks her screen now, for the six metres, and the branch manager has noticed. The branch manager notices everything the desk does. That is the whole lever. The desk cannot make two hundred people read a policy. It can be seen, every day, doing the eight things the policy was trying to say.

Frequently Asked Questions