The Layered Plan That Makes Password Tickets Rare

Friday, 15:30, at Wrenfield College. Marcus runs a desk of three for a further-education college with about six hundred staff. Its term-time rhythm makes September feel like a siege. He has the census from the first article in this series on the desk in front of him. 230 of 610 tickets last month had a credential as the cause. He also has an e-mail from the finance director. She has heard that there is a product that lets people reset their own passwords. She would like a quote by Monday, because "that will sort it". Marcus is not against the product. He is looking at the census, where the largest line is not "forgotten" but "locked, device still held the old password". The second largest is "expired on schedule". He is trying to work out how to tell the finance director that the thing she wants to buy fixes the third line.

A layered plan is a set of separate changes, each removing one slice of the password tickets. They are ordered by cost and applied one at a time with a month between them. That way, you can see what each one did and stop when the problem is small enough. It is the opposite of the single purchase. And it is the only approach I have seen that works, because the password ticket is not one problem. It is six, wearing the same subject line. This article is part of our Password & Lockout Tickets series. It is the one that turns the census into a plan.

It covers why one fix never does it. Then come the six layers in order of cost: the changed-password reminder, the onboarding briefing, the expiry policy, lockout tuning, single sign-on and self-service reset. Next come the order and why it matters, a worked example of what each layer removed at Wrenfield, and how to read the drop. A short war story and the layer plan to copy follow, in that order.

Why One Fix Never Does It

The census sorts password tickets by cause, and the causes point at different fixes, which is the whole reason for sorting them. A lockout caused by a phone holding the old password is fixed by telling people about the phone at the moment they change the password. An expired password is fixed by changing how often passwords expire, if the organisation's rules allow it, and by nothing else. A second system with its own password is fixed by making it use the directory's password instead. A forgotten password is fixed by letting the person reset it themselves. A new starter who never got a password is fixed by the onboarding process. No single purchase touches more than two of those, and the one everybody wants to buy, self-service reset, touches one.

The layers also differ in cost by a factor of hundreds. The reminder is a template and an afternoon. The self-service project is months, a budget, and an enrolment campaign that decides whether the months were wasted. A plan may start with the expensive layer because it is the visible one. In that case, it spends the budget before the cheap layers have shown what is left to fix. And it often finds, nine months later, that the lockouts it was meant to remove were never the kind it removes. Start with the layer that costs a day. Count for a month. Then the next. The expensive layer will still be there when you reach it, and the census will tell you whether you need to.

Layer One: The Changed-Password Reminder

The first layer is a message that reaches every person at the moment they change their password. That includes changes at the expiry prompt, by their own choice, or through a desk reset. The message tells them that their phone, tablet, second computer and saved sessions still hold the old one. These will lock the account unless updated now. The reminder targets the largest line on most censuses, the lockout caused by a stale device. It costs almost nothing: a short knowledge base article and a line in the reset reply. Wherever the organisation has a way to send a message when a password changes, it includes that message too. Some directories and identity systems can send one automatically. Many cannot. In that case, the desk sends it by hand after each reset and once, to everyone, the week before each expiry wave.

The content is the list of six places from The Lockout That Keeps Coming Back, in plain words, with "do this before you put the phone down" at the top. Keep the article where everyone can read it without signing in, since the person reading it may be locked out. If you run QuerySolv, a knowledge base article visible to everyone rather than to agents only is the right home. The reset reply links that article. The reminder does not stop people changing passwords. It stops the phone from locking them out afterwards, which on the Wrenfield census was a third of the whole problem. The reminder was in place by the following Tuesday.

Layer Two: The Onboarding Briefing

The second layer is five minutes in every new starter's first day. The briefing says which passwords they have, which devices will hold them, what will happen when the password expires, and how to change it. It says how to reach the desk if locked out. Where self-service reset exists, it says how to enrol before they need it. It targets the new-starter line on the census. It also targets a slice of the forgotten and locked lines that show up in the first month of employment. It costs a page in the knowledge base and the five minutes, repeated. The briefing belongs on The Day-One Checklist in the onboarding series, which owns the rest of the first day. This article only says that the password briefing is on it and what it contains.

The briefing's hidden benefit is the list of systems. A new starter is handed accounts on the directory, the finance system, the HR portal and whatever else the role needs. The person doing the briefing walks through each one, which means the desk has to know what they are. The first time the briefing is written, the desk discovers two systems it did not know had their own passwords. Both go on the list that layer five will need.

Layer Three: The Expiry Policy, Where the Rules Allow

The third layer is the conversation with whoever owns security about how often passwords expire. It targets the expired line and the wave of lockouts that follows each expiry. The desk does not own the policy and should not pretend to. What the organisation's rules permit depends on its regulator, its auditors, its insurers and the guidance its security function follows. That guidance differs between sectors and changes over time, so this article does not say what the right expiry period is. What it says is that the desk is the only part of the organisation that knows what the current period costs. The conversation goes differently when the cost arrives as a number.

Bring three things to the meeting. Bring the count of expired tickets per month from the census, the count of lockouts that followed each expiry wave, and the dates of the waves. The security owner can then see that a wave lands on the same week every cycle and plan around it even if the period does not change. Then ask the question as a question. "Within the rules we have to follow, is there room to lengthen the cycle, to stagger the waves, or to move to changing passwords when there is a reason to?" Sometimes the answer is yes and the expired line falls by half. Sometimes the answer is that the insurer requires the current period. In that case, the desk has learned something true and can stop arguing with the calendar. Either answer is better than the one the desk had before, which was a grievance.

Where the policy cannot change, two smaller moves still help. Staggering the waves, by spreading the next forced change across several weeks rather than one, turns a Monday siege into a steady trickle the roster can absorb. And an advance notice goes to the people whose passwords expire next week, with the reminder from layer one attached. That means more of them change at the prompt with the phone already in hand. The number of expired tickets stays the same. The number of lockouts behind them does not.

Layer Four: Lockout Tuning and the Stale-Credential Hunt

The fourth layer is a second conversation with the security owner, this time about the lockout policy. It is the conversation to handle with the most care, because the lockout is a defence. The desk is asking about it from the side that finds it inconvenient. The lockout policy sets how many wrong attempts lock the account, over how long, and for how long. All three are the security owner's decision. The desk's contribution is evidence from the diagnostic sheets. How many lockouts in the month were traced to a device? How many were traced to a person mistyping, and how many to a source nobody could explain? The unexplained count should be none and must be reported if it is not. A policy that locks an account on a single retry from a phone generates tickets without adding protection against anything. A policy loose enough to let a guessing program through is worse than any number of tickets. Where the line sits between them is not the desk's call. The desk brings the counts and goes back to the queue.

The half of this layer the desk does own is the hunt. A recurring lockout may have been traced to a scheduled task, a kiosk, a shared device or a service signed in as a person. Every such cause can be removed for good by giving that thing an account of its own. And the lockout diagnostic sheet from the lockout article is where those are recorded. Go through a month of sheets and list every device or task that was signing in as a person. Raise a ticket to move each one to a dedicated account. That list is short, it is finite, and once it is done the lockouts it caused never return. Phones will keep being phones. Forklifts need not.

Layer Five: Single Sign-On Where It Exists

The fifth layer is single sign-on. In plain words, a system accepts the directory's password instead of keeping its own, so that a person has one credential instead of several. Single sign-on targets the second-system line on the census. It is cheap for systems that already know how to talk to the directory and were simply never connected. It is a project for systems that do not, which is why it comes fifth: the desk cannot do it alone. The order in which systems are connected should follow the census, largest line first. At Wrenfield the largest second-system line was the timetabling application, and the second was the library system. Nobody had connected either because nobody had counted the tickets they caused.

The desk's part is the list and the case. The list is every system with its own password, started by the census and completed by the onboarding briefing. Beside each system is the count of tickets it caused last month. The case is that list handed to whoever owns integration, with the suggestion that the top one goes first. The desk will also want to say, honestly, that single sign-on makes the one remaining password more valuable. That is a point in favour of the verification standard in this series and of the second factor the security owner probably already wants. Fewer passwords is a security improvement and a ticket improvement at the same time, which is rare, and worth saying in the meeting.

Layer Six: Self-Service Reset

The sixth layer is self-service reset. A person who has forgotten their password proves who they are to the directory or the identity system by a registered device or a second factor. They then set a new password without the desk. Self-service reset targets the forgotten line, the largest one on desks where the earlier layers are in place. It is a feature of the directory or an identity system, never of a help desk tool. It is also a project rather than a purchase: requirements, a choice of approach, a pilot, a rollout. It also includes an enrolment campaign that is the whole project in disguise. A self-service system nobody has enrolled in is a reset ticket with extra steps. All of that is the subject of the self-service reset series, and this article does not repeat it.

Self-service comes last not because it matters least but because it is the one layer whose result depends on the others. Put it in before the reminder and the forgotten line falls while the lockout line, which it does not touch, stays where it was. The sponsor who paid for it then asks why password tickets are still a quarter of the queue. Put it in after the cheap layers and it lands on a census where forgotten passwords are now the largest line. By then, the desk's role in enrolment is already written into the reset reply and the onboarding briefing. The drop self-service produces is then visible and its own. The expensive layer deserves a clean month to show what it did.

The Order, and the Worked Example at Wrenfield

The order is by cost and by independence: cheapest first, and each layer before the one whose result it would otherwise hide. The table below is Marcus's plan at Wrenfield, with the fictional desk's own numbers in ranges. They are given so the shape is clear and not as anything to expect on your desk. The census month had 230 password tickets of 610. Each layer was given a month on its own before the next, which is slow. It is the only way the "removed" column can be believed. The monthly count that measures the drop is the subject of Measuring the Password Problem Month by Month. The plan only needs the count to exist.

Read the "removed" column against the "of about" figure in each row rather than against the total. Each layer removes from its own line and leaves the others alone. Adding the ranges up gives somewhere between 120 and 175 fewer password tickets a month at the end of the plan. That is against the 230 Marcus started with, leaving a residual of perhaps 55 to 110. The residual is mostly mistyping, people who cannot enrol, and the genuinely forgotten. The residual is the point at which the plan stops; the measuring article says how to recognise it. Marcus's plan took most of an academic year, and the finance director got her quote for the self-service product in the spring. By then, the desk could say exactly which fifty tickets a month it would remove and why the other hundred and eighty had already gone.

Reading the Drop Honestly

A month between layers is the minimum. On a desk with a seasonal rhythm it is not enough on its own. The password count falls in August at every college on earth whether or not anyone did anything. Compare each month with the same month in the previous year where the record exists. Where it does not, compare with the average of the surrounding months. Treat a drop that coincides with a holiday as unproven until the next busy month confirms it. The way to tell a trend from a season is the subject of Trends and Seasonality. The plan borrows it rather than restating it. A layer that "worked" in August and vanished in September did not work. The students left.

Watch the lines, not the total. Suppose the reminder removes forty lockouts. A new finance system with its own password adds thirty-five tickets of a kind that did not exist before. The total can then stay flat, and a desk reading only the total will conclude that the reminder did nothing. The census by cause, repeated monthly, is what shows that one line fell and another was born. And the new line goes straight onto the single sign-on list. The layered plan is never quite finished, because the organisation keeps buying systems. It is finished enough when each new line is noticed the month it appears and has an owner by the month after.

A Short War Story: The Expensive Layer First at Marchbank Solicitors

Marchbank Solicitors is a law firm with a hundred and forty staff and a two-person desk. Its IT manager, Daniel, was given a budget for a self-service reset product after a partner was locked out before a court hearing. He spent the budget first and counted the tickets afterwards. Nine months later enrolment was below half, because nobody had been asked to enrol at the moment they rang the desk. Password tickets were down by about a sixth. When Daniel finally ran a census, it showed why. Most of the firm's lockouts came from phones after the quarterly expiry wave and from a document system with its own password. The self-service product had never heard of that system. He then did the cheap layers in a single month. He put the reminder in every reset reply and sent an advance notice the week before each expiry wave. He requested that the integration contractor connect the document system to the directory. The password tickets roughly halved. The cost was a year's subscription to the product spent while the afternoon's work waited. It also cost around two hundred hours of desk time on tickets that the afternoon's work would have removed. The expensive layer is the one everybody wants to buy. The cheap layers are the ones that work on Monday.

The Layer Plan

The plan below is the one Marcus wrote on the Monday after the finance director's e-mail. It fits on one page because the thinking is in the census, not the plan. Section one carries the starting census so the plan can be measured against it. Section two lists the six layers in order of cost, each with the census line it targets, its owner, and its start month. It also gives the line's count before and after, filled in as the months pass. Section three is the stopping rule, so that the plan ends when the problem is small and understood rather than when the budget runs out. Section four is the list of new lines, for the systems the organisation buys while the plan is running. Date it, and bring it to every monthly review until section three is true.

THE LAYER PLAN — PASSWORD AND LOCKOUT TICKETS, ONE PAGE
Desk: ______________________   Plan owner: ______________   Started: ____________

1. THE STARTING CENSUS  (from the census sheet; never changed)
   Month: ________   Password tickets: ______ of ______ all tickets
   By cause: expired ____  forgotten ____  locked, device ____  locked, mistyped ____
             changed and broken ____  second system ____  new starter ____  not recorded ____

2. THE LAYERS, CHEAPEST FIRST  (one at a time; a full month between each)
   Layer                               Targets line        Owner          Start    Before   After
   1. Changed-password reminder        locked, device      desk           ______   ____     ____
      KB article written [ ]  in reset reply [ ]  sent before each expiry wave [ ]
   2. Onboarding briefing              new starter         desk + HR      ______   ____     ____
      page written [ ]  on the day-one checklist [ ]  systems list started [ ]
   3. Expiry policy and staggered waves expired, and lockouts behind each wave
                                                           security owner ______   ____     ____
      counts and wave dates presented [ ]  decision recorded: ______________________
   4. Lockout tuning and the hunt      recurring, non-phone security owner ______   ____     ____
      diagnostic sheets reviewed [ ]  devices signing in as people moved to own accounts: ____ of ____
   5. Single sign-on, largest system first  second system  integration    ______   ____     ____
      systems with own password, by ticket count:  1. __________  2. __________  3. __________
   6. Self-service reset               forgotten           directory owner ______  ____     ____
      enrolment target: ____ of ____   reached on: ______   desk enrols on every reset call [ ]

3. THE STOPPING RULE
   The plan is done when password tickets are below ______ of ______ for three months
   including one busy month, every remaining cause is understood, and no line is growing.
   Residual expected: mistyping, people who cannot enrol, the genuinely forgotten.

4. NEW LINES  (systems bought while the plan ran; each gets an owner within a month)
   System: ______________   First seen: ______   Tickets last month: ____   Owner: __________
   System: ______________   First seen: ______   Tickets last month: ____   Owner: __________

Marcus replied to the finance director on the Monday with the census attached. His reply included a sentence saying he would like the quote too, in the spring. That would be after the desk had removed the hundred and eighty tickets a month that the product would not touch. The fifty it would touch would then be visible when she paid for them. She asked why not now. He showed her the lockout line, and the phone in her own hand, which had asked her to sign in twice that morning. The reminder went out on Tuesday.

Frequently Asked Questions