Password Resets and Account Status: The Hidden Time Sink

Look at a week of tickets on a typical IT support desk and one category shows up again and again without ever being interesting: "I can't log in." Half of those are a forgotten password. The other half is something about account status: locked out after too many attempts, disabled when it should not have been, or expired because a contract end date has passed. Each ticket is two minutes of work on its own. Together they are a creeping cost that rarely shows up on a dashboard.

TL;DR

• Password resets and account status questions together are often 20 to 40% of ticket volume on an IT support desk.
• Most of the reset work does not need a human: self-service password reset (SSPR) in Entra ID handles the bulk of it.
• Account status tickets often come from your own process, not the user: expired accounts, lockouts, and accounts disabled too early or too late.
• The real win is at the source: make status (active, locked, disabled, expired) a result of a rule or an attribute, not of manual work.
• Keep the genuine exceptions (suspicious account, forced reset after an incident) with a human.

Where the Volume Actually Comes From

A password reset looks like the simplest ticket there is. The real cost is not the reset itself but the context around it. The user calls or emails, the agent has to verify identity (you do not want someone resetting another person's password), perform the reset, hand over a temporary password through a safe channel, and sometimes explain how the user sets a new one afterwards. Count five to ten minutes each time, times dozens per week.

Account status tickets are quietly more expensive, because the user usually has no idea what is wrong. "I can't log in" can mean any of the following:

• The account is locked after too many failed attempts.
• The account is disabled, for example because someone flipped it during offboarding while the person is actually working one more day.
• The account expired because the accountExpires value or a contract end date passed.
• The user is stuck in an MFA loop and cannot get out.

Each of these costs diagnosis time before anything gets fixed. And the user is idle in the meantime.

Password Resets: Most of Them Do Not Belong on the Desk

The vast majority of reset requests are not incidents, they are routine. And routine belongs in self-service. Entra ID has a ready-made answer here: self-service password reset.

Turn SSPR On and Make It Mandatory

With SSPR a user resets their own password after verifying through a second factor. No ticket, no wait, no agent verifying identity. The practical steps:

1. Enable SSPR in Entra ID, first for a pilot group, then for everyone.
2. Require registration of the verification methods, so people do not discover at the moment they are locked out that they never set anything up.
3. Enable password writeback if you run hybrid, so a reset in Entra ID also flows down to on-prem Active Directory. Without writeback someone resets their cloud password but not the one they use to log in to their laptop, and then they call anyway.
4. Communicate once, clearly, where people do this themselves, and point to it from every relevant ticket.

This is not a ServiceChanger feature and it should not be. SSPR ships with Entra ID P1 and it is the first step that removes most of the reset volume. ServiceChanger does nothing with authentication, passwords, or MFA. That is deliberate: the identity provider should own that.

What You Do Keep on the Desk

Not every reset belongs in self-service. A forced reset after a security incident, an account you suspect has been taken over, or a user who lost their second factor and needs to re-register: those are the real exceptions. You want a human handling those, with the extra verification that comes with them. The point is not to automate everything, but to remove the routine so there is time left for the cases that deserve attention.

Account Status: The Problem Is Usually in Your Own Process

Password resets get solved with a tool Microsoft already ships. Account status tickets are harder, because they often come not from the user but from how your organization manages accounts. A few common patterns.

Expired Accounts Nobody Saw Coming

Contractors and temporary staff often get an end date. That is good practice. It goes wrong when that date is reached without anyone expecting it: the contractor keeps working, suddenly cannot log in, calls the desk, and the agent bumps the date forward a month. Often without checking whether that is even correct. So the account expires again next month, and every month it costs a ticket.

The fix is not to keep pushing the date out, but to tie the end date to the real contract duration and route any extension through an explicit approval. When an attribute like accountExpires or an end-date field is populated from a reliable source, expiry becomes a predictable outcome instead of a surprise.

Accounts Disabled Too Early or Too Late

In offboarding, timing is everything. Disable an account too early and someone sits on their last working day without access and calls the desk. Disable it too late and standing access stays open that should not exist anymore. Both are a problem, and both come from timing things by hand.

This is where an attribute-driven model does have something to offer. If leaver status follows from an attribute (last working day reached, employment ended), you can let access and group membership follow without anyone pressing the button at exactly the right moment. Note the boundary: actually disabling or deleting the account is a separate step. ServiceChanger handles group and role membership based on attributes out of the box; creating or disabling the account itself from an HR system is custom work through runbooks, not an out-of-the-box feature. Be honest about that internally, otherwise you are promising something the tool does not do.

Lockouts That Are Really Symptoms

A single lockout is normal: someone mistypes three times and the account locks. A user who is locked out every week is a signal. Usually there is an old stored password still trying to authenticate somewhere: a phone with an old mail profile, a service running with stale credentials, a mapped drive. A lockout ticket you only unlock without finding the source will just come back next week. This is not an automation question but a thing to watch: log repeated lockouts per account, because that list points you at the real cause.

A Practical Order

If you want to get a grip on this without standing up a big project, this is a workable order:

1. Measure first. Count for a month how many tickets are about password reset and account status. Without that number you do not know where the win is.
2. Turn SSPR on and require registration. This removes the largest, dullest chunk and is pure Entra ID.
3. Enable password writeback if you are hybrid, otherwise SSPR only solves half of it.
4. Make end dates reliable. Tie contractor account expiry to real contract data and an approval step, not to an agent who keeps pushing the date forward.
5. Let status follow from attributes where you can. Group membership and access that move with employment and role save a pile of separate status tickets. Turning the account itself on and off stays a deliberate choice.
6. Keep the real exceptions with a human. Suspicious accounts, forced resets after incidents, and lost second factors do not belong in self-service.

Closing

Password resets and account status are the kind of work that never makes the roadmap because each individual ticket is so small. That is exactly why they add up. The first step costs you nothing extra: turn SSPR on if it is not already, and count for a month how many of your tickets are about logging in. That number usually makes it clear in one go whether this is a footnote or one of your biggest quiet costs.