How to Reduce Password Reset Tickets (Securely)

To reduce password reset tickets, attack the causes: give people self-service reset so they don't need the help desk, reduce the number of passwords with single sign-on, and stop forcing changes that cause forgetting — NIST's guidance says not to require periodic password changes and not to impose composition rules. For the resets that still reach a person, use a verified process — resets are a favourite route for social engineering — and rate-limit reset endpoints so they can't be abused.

Why password resets pile up

Password resets are among the most repetitive requests an IT desk handles: identical every time, often urgent (the person can't work), and mostly avoidable. The usual causes:

• Too many passwords. Every app with its own login is another password to forget.
• Forced expiry. Rules that make people change passwords every 60 or 90 days produce predictable variations and frequent lockouts after holidays.
• Complexity rules. "One uppercase, one symbol, one number" produces passwords people can't remember and write down.
• No self-service. If the only path is "ask IT", every forgotten password becomes a ticket.

Fix 1: self-service reset

The biggest single reduction. Let people reset their own password with verification they set up in advance — an authenticator app, a registered phone or a recovery email. Identity providers (Microsoft Entra's self-service password reset, Google Workspace's user recovery options, and others) support this; turn it on and require enrolment during onboarding. See the IT onboarding checklist.

For your own applications, a standard "Forgot password?" flow sends a single-use, time-limited link to the account's email. LetRelay uses Supabase Auth for this: a reset email with a link back to the app, where the person sets a new password. Two details matter:

• Don't reveal whether an account exists. "If an account exists for that email, we've sent a link" — the same response either way.
• Rate-limit the endpoint per IP address so it can't be used to flood someone's inbox or probe for accounts. LetRelay limits login, sign-up and reset attempts per IP, and deliberately not per email address — keying on email would let an attacker lock a victim out. Details in rate limiting without Redis.

Fix 2: fewer passwords

Single sign-on (SSO) means one strong credential, protected by multi-factor authentication, for most apps. Fewer passwords means fewer resets, and one place to disable access when someone leaves. When evaluating new tools, prefer ones that support your identity provider.

Fix 3: modern password rules

NIST's Digital Identity Guidelines (SP 800-63B) changed password advice substantially. The current version says:

• Passwords used as the only factor must be at least 15 characters; with multi-factor authentication, at least 8.
• Verifiers shall not require periodic password changes — but shall force a change when there's evidence of compromise.
• Verifiers shall not impose composition rules such as requiring mixtures of character types.
• New passwords must be checked against a blocklist of common, expected or compromised passwords.

Longer, memorable passphrases with no forced expiry and a breached-password check are both more secure and generate fewer resets. The UK's NCSC password guidance points the same way. If your policy still says "change every 90 days, one symbol required", updating it may be the cheapest ticket reduction available.

Fix 4: MFA that doesn't become the new reset

Multi-factor authentication is essential — CISA calls it one of the most effective ways to protect accounts — but lost phones generate "reset my MFA" requests. Reduce them:

• Let people register two methods (an authenticator app and a backup code or second device).
• Offer printable backup codes at enrolment.
• Treat MFA resets with at least the same verification as password resets; they're more sensitive, because an MFA reset plus a known password is full account takeover.

Fix 5: a secure process for resets that reach a person

Some resets will always need a human: a new phone and no backup method, a locked-out executive before a board meeting. This is exactly where social engineering happens — a caller claims to be someone important, in a hurry. A defined process protects the help desk:

1. Verify identity through a channel the caller didn't choose. Call back on the number in the HR record, get confirmation from their manager through a known channel, or check in person with ID.
2. Never reset based on urgency or seniority alone. "I'm the CFO and I'm about to present" is a script, not a verification.
3. Deliver the reset securely. A single-use link or a temporary password that must be changed at first sign-in — never the new password in a chat message that stays in history.
4. Log it on a request: who asked, how they were verified, who reset it. Make "password/MFA reset" its own category so volume and verification can be reviewed.
5. Notify the account holder through their known email: "Your password was reset by the IT desk." If they didn't ask, they'll say so.

LetRelay's admin tools follow this shape for workspace accounts: an admin can re-issue a one-time temporary password for a person, which must be changed at first sign-in, and the invite/reset email is sent to the account's address when email is configured.

Fix 6: answer the question before it's a ticket

Some "password" tickets are really questions: "Which password do I use for the VPN?", "Where do I change my password?". Write short knowledge-base articles for each and show them when someone starts typing a password request. See ticket deflection with a self-service knowledge base.

Common mistakes

• Security questions as recovery. Mother's maiden name and first pet are often discoverable online. Prefer an authenticator app or registered device.
• Resetting over chat and pasting the password back. It stays in message history indefinitely.
• Temporary passwords that never expire. A reset password should work once, briefly, and demand a change.
• Self-service without enrolment. Turning on self-service reset helps only if people registered their recovery methods; make enrolment part of day one.
• Blaming users. Frequent resets are a design signal — too many passwords, expiry rules, or no self-service — not a training problem.

Measuring progress

Track, monthly:

• Password and MFA reset requests as a category — the number should fall after each fix.
• Self-service resets completed from your identity provider's reports — the number should rise.
• Resets after holidays — a spike suggests expiry rules or lack of self-service enrolment.

The broader metrics set is in help desk metrics that matter.

FAQ

How can I reduce password reset requests?

Enable self-service password reset, adopt single sign-on so people have fewer passwords, stop forced periodic changes and composition rules as NIST recommends, and publish short help articles for common password questions.

Does NIST recommend changing passwords regularly?

No. NIST SP 800-63B says verifiers shall not require periodic password changes, but shall force a change when there's evidence of compromise.

How should the help desk verify identity before a password reset?

Through a channel the caller didn't choose — a callback to the number on record, confirmation from their manager via a known channel, or an in-person ID check — and log the verification on the request.

Should password reset be rate limited?

Yes, per IP address, with the same response whether or not the account exists, so the endpoint can't be used for inbox flooding or account discovery.

Sources

• NIST SP 800-63B — Authentication and lifecycle management
• NCSC — Password guidance
• CISA — Require multifactor authentication
• Microsoft Entra — How self-service password reset works
• Google Workspace — Let users reset their own passwords