The most common IT ticket is also the least necessary
Somebody forgets a password over the weekend, or mistypes it enough times on Monday to lock the account. Now they cannot work. So they call the help desk — or wait until it opens — describe the problem, wait for the queue, and eventually get a temporary password read out to them.
Multiply that across an organisation and it stops being a nuisance and becomes a standing cost. Every one of those tickets consumes two people’s time, the one locked out and the one unlocking them, and produces nothing.
And the handling time is the smaller half. The real cost is the shape of the delay: the person locked out at 6pm, or on a Saturday, or the morning of a deadline, who simply cannot work until somebody else is free. A ticket that takes three minutes to close can cost hours before it is even opened.
A locked-out employee isn’t a ticket in a queue. They’re a person who can’t work until someone else is free to help them.
None of it needs a human in the loop. The person who forgot the password is standing there holding the phone that could prove who they are. The only reason it becomes a call is that nothing lets them prove it themselves.
Three numbers, from systems you already have
How many resets and unlocks did the help desk handle last quarter, and what share of all tickets were they? In most organisations this is the largest single category, and quantifying it is what turns we should look at self-service into a funded decision.
How much of that volume landed outside working hours? Filter by when the ticket was raised against when it was resolved. That gap is productivity cost, and it never appears in a first-response-time report because it isn’t help-desk time — it’s somebody else’s.
How much of it is the same few people? Group resets by user. A small number usually account for a large share, often the ones whose password expires on a cycle they never see coming — a tail that is almost entirely preventable.
Build the case from your own numbers. There is a well-worn industry figure for what a single reset costs, and we deliberately don’t quote it: the versions in circulation almost never say whose environment they were measured in. Yours is straightforward — the volume above, what one interaction actually costs your service desk, and the time somebody couldn’t work while they waited.
Reset the password. Unlock the account. Keep the help desk out of the authentication path.
The person who needs the reset does it themselves, and proves who they are with the second factor they already have enrolled — a push approval, a code from the app, TOTP or SMS.
That is not a weaker check than a phone call. It is a considerably stronger one: a help-desk agent is verifying a voice against details a caller happens to know, under time pressure, while somebody insists they are locked out of something urgent.
- Unlock is its own action Most of the time the password is fine and the account is simply locked. Unlocking without forcing a new password is what people actually need most often, so it doesn't drag a password change along with it.
- It covers the hours nobody is staffing Nights, weekends and holidays are where the value concentrates — because that is precisely when the call cannot be made and the person waits until morning.
The lockouts that never happen
Closing a ticket faster is a smaller win than the ticket not existing.
Expiry reminders warn people a configurable number of days ahead, and then daily as the date approaches. The password gets changed calmly, at a desk, by somebody who had notice — instead of expiring quietly over a weekend and turning into a Monday-morning lockout for the whole team at once.
That single control removes a meaningful share of the category at source, and it is the part most self-service projects skip because it isn’t self-service.
Adoption is decided before anybody needs it
A portal nobody enrolled in produces the old call volume plus a written-off project. That is the usual way this fails, and it fails at enrolment rather than at the reset.
So enrolment isn’t a separate campaign. People register their phone in the same portal, as part of the MFA rollout — which means they are already enrolled on the day they get locked out, rather than being asked to set something up at the exact moment they are frustrated and in a hurry. The product page covers how that rollout is run.
Self-service without handing over the directory
Here is the objection a security team raises first, and it is the right one: a tool that can reset anybody’s password is now one of the most valuable things in the environment.
No Domain Administrator account is required. The service account behind Mirket’s self-service runs on delegated, OU-scoped Active Directory permissions — the specific rights needed to reset a password, unlock an account and read the relevant attributes, inside the organisational units you choose.
That means the blast radius of the self-service platform is the set of operations it performs, rather than the directory. The exact permission list, and the dsacls commands that grant them, are on Secure Self-Service — worth handing to whoever will ask.
Wherever your directory is
Self-service runs on your own servers or as a service, with the same capability either way. Deployment sets out which modules are offered in which shape, and why.
What changes with Mirket
| Before | With Mirket |
|---|---|
| A reset is a call, a queue and a temporary password | The user does it, verified by a second factor |
| A lockout at night waits until morning | Self-service covers the hours the help desk doesn’t |
| Unlocking drags a password change along with it | Unlock is its own action |
| Every expiry is a potential lockout | A reminder heads it off days ahead |
| Identity is verified by a voice on the phone | It is verified by the enrolled second factor |
| Resets are the largest ticket category | The category is removed rather than staffed |
| The reset tool needs broad directory rights | It runs on OU-scoped delegated permissions |
Frequently asked questions
What is self-service password reset?
Letting a user reset their own password, or unlock their own account, after proving who they are with a second factor — instead of calling a help desk and being read a temporary password over the phone.
Is unlocking an account the same as resetting a password?
No, and conflating them is a common mistake. Most of the time the password is perfectly fine and the account is simply locked after too many attempts. Unlocking without forcing a new password is what people need most often, so it is its own action.
How does the user prove who they are?
With the second factor they already have enrolled — a push approval, a code from the app, TOTP or SMS. That is a stronger check than a help-desk call, where the agent is verifying a voice against whatever details the caller happens to know.
Does this need Domain Admin rights?
No. The service account behind it runs on delegated, OU-scoped Active Directory permissions — the specific rights needed for reset and unlock, and nothing else. A tool that can reset passwords should be able to do that and nothing more; the exact permission list is on Secure Self-Service.
What stops somebody social-engineering their way to a reset?
The check is a second factor rather than a conversation. There is nobody to persuade, no details to recite and no agent under time pressure deciding whether a caller sounds legitimate. Secure Self-Service covers that side in full.
Does it work outside working hours?
That is where most of the value is. A lockout at seven in the evening, on a Saturday, or the morning of a deadline is the one that costs real time — and it is exactly when a call cannot be made.
Can lockouts be prevented rather than handled?
Yes, and it is the cheapest win available here. Expiry reminders warn people a configurable number of days ahead and then daily, so a password gets changed calmly at a desk rather than becoming a Monday-morning lockout.
What if a user loses their phone entirely?
Then the recovery path is the thing being designed, and it is a configuration decision rather than a fixed flow — a time-limited enrolment link by email, personal security questions, an administrator-issued link, or a combination. Secure Self-Service sets out the building blocks and the trade-off between them.
Self-service was tried here before and nobody used it. What is different?
Adoption is the whole game, and it is won before anybody needs a reset. People enrol their phone in the same portal as part of the MFA rollout, so they are already registered on the day it matters — rather than being asked to enrol at the exact moment they are locked out and frustrated.
Does this work on-premise?
Yes, on your own servers or as a service. Both deployments offer the same self-service capability — Deployment sets out which modules run where.
How do I build the business case?
From your own ticketing system rather than from a published industry figure. The volume, what one service-desk interaction genuinely costs you, and the time somebody could not work while they waited. Those three, multiplied out, tend to surprise the people who sign off the budget.
Related
Solutions — Passwordless Authentication · MFA Fatigue Attacks · MSSP & Multi-Tenant · Adaptive Authentication
Product — Secure Self-Service