Password and MFA resets are the front door attackers use when they cannot phish a phishing-resistant credential, so the reset tool decides how strong your authentication really is. Self service password reset (SSPR) and help desk verification tools let users recover access without an agent, and give agents a controlled, logged way to verify a caller before any reset. Bought badly, they replace a weak help desk script with a weak web page: security questions, SMS codes to numbers an attacker has moved, and temporary passwords sent to whoever asked. This vendor-neutral buyer's guide covers reset and recovery flows, step-up to verified identity for high-risk recoveries, and agent tooling. Identity proofing products themselves, used at onboarding and as one step in recovery, are covered in the Workforce and Help Desk Identity Verification Buyer's Guide. It is for IAM leads, service desk owners and security architects.
Key takeaways
- Recovery is a separate trust decision. NIST SP 800-63B-4 treats account recovery as its own process with defined methods: saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing. A tool should map to those, not invent its own.
- Knowledge questions are out. NIST SP 800-63A-4 does not permit knowledge-based verification, and SP 800-63B-4 does not allow prompting users for knowledge-based authentication when setting passwords. Do not buy a tool whose main fallback is security questions.
- Stronger accounts need stronger recovery. For AAL2 accounts NIST requires two recovery codes by different methods, a code plus an existing bound authenticator, or repeated identity proofing; for IAL3 accounts recovering to AAL3, a biometric comparison against the sample from the original in-person proofing.
- Every recovery must notify. SP 800-63B-4 requires a notification to the subscriber after every account recovery, to all stored addresses except postal ones. Buy a tool that does this by default.
- Finish with a phishing-resistant credential. The safest recovery ends with the user enrolling a passkey or security key in the same session, not with a temporary password.
Define requirements
- Threat model: CISA's Scattered Spider advisory AA23-320A describes actors persuading help desk staff to reset passwords and MFA, registering their own MFA, using SIM swaps and abusing trust in contracted IT help desks. Your requirements should assume a convincing caller with the victim's personal details. See the Vishing and Help Desk Social Engineering Awareness Guide.
- Recovery paths to cover: forgotten password with an authenticator still held (which NIST treats as binding a new authenticator, not recovery), lost or replaced phone, lost security key, locked account, new device enrolment, and change of MFA method or phone number.
- User classes: standard staff, privileged administrators, executives, contractors and third-party users, service desk staff themselves, and frontline staff without corporate phones or email.
- Assurance levels: record the authentication assurance level (AAL) each class needs and whether accounts were identity proofed at hire, because NIST recovery options depend on both.
- Directory and IdP estate: cloud identity provider, on-premises directory with password writeback, ITSM, HR system, MDM and the authenticators in use.
- Constraints: users without smartphones, shared devices, accessibility needs, languages, and data protection limits on biometrics and document images.
Capability areas
| Capability | What good looks like | Weak version to avoid |
|---|---|---|
| Self-service recovery flows | Recovery methods matching NIST classes; recovery with an existing phishing-resistant authenticator where held; risk-based step-up | Security questions; email link alone for privileged users |
| Recovery codes | Saved codes with at least 64 bits of randomness, stored hashed, single use and replaced after use; issued codes with short validity (NIST: 10 minutes for text or voice, 24 hours for email) | Long-lived codes; codes sent to an address added in the same session |
| Phone-based codes with risk checks | SIM change, device swap and number porting checked before sending; never the only factor for privileged accounts | SMS code as sole proof for any account. See the SIM Swap Fraud Guide |
| Recovery contacts and manager attestation | Named trusted contacts managed by the user, annual review reminder, approval through an authenticated channel | Approval by email reply; contacts the caller can name on the call |
| Verified identity step-up | Repeated identity proofing (document, liveness, match to hire record) for lost-everything cases and privileged users | Agent compares a photo by eye on a video call. See the Deepfake-Resistant Identity Verification Guide |
| Help desk verification console | Agent starts a verification from the ticket; push or passkey challenge to a registered device; result written to the ticket; agent cannot reset until it passes | Agent asks questions from the HR record; free-text "verified" checkbox |
| Post-recovery enrolment | Direct handoff to passkey or security key enrolment; short-lived, single-use bootstrap credential where needed | Temporary password read out over the phone |
| Notification and audit | Notification to all stored addresses after every recovery; full log of methods, results, agent and IdP actions to the SIEM | Notification only to the new address; logs kept only in the tool |
Evaluation criteria
| Criterion | What to test | Evidence to request | Suggested weight |
|---|---|---|---|
| Alignment with NIST recovery rules | Configure recovery for an AAL2 class and a privileged class; check code entropy, validity and notification | Mapping of features to SP 800-63B-4 section 4.2; configuration demonstration | 20% |
| Social engineering resistance | Caller with full personal data tries to get a reset; agent override attempts | Red team results in pilot; override controls and alerts | 20% |
| Phishing-resistant outcome | Recovery ends in passkey or security key enrolment without a temporary password | Live end-to-end demonstration in your IdP | 15% |
| Identity proofing step-up | Document and liveness check matched to the hire record; injection and deepfake handling | ISO/IEC 30107-3 presentation attack test report; integration with your proofing provider | 15% |
| Integration | IdP, on-premises directory writeback, ITSM, HR and MDM; session revocation after reset | Integration list for your estate; demonstration | 10% |
| Usability and reach | Users without smartphones, frontline and contractor users; completion rate and time | Pilot completion and abandonment rates; accessibility statement | 10% |
| Audit and detection | Events in the SIEM with ticket, method, result and agent | Sample event schema; retention options | 5% |
| Product security | Admin roles, API keys, the tool's own privileged access to reset all users | Security attestation; admin role model; how the tool's service account is protected | 5% |
The tool's service account can reset every password in the directory, which makes it one of your most privileged non-human identities. Scope it, vault its credentials and alert on its use outside the tool. See the Account Recovery and Help Desk Security Guide for the process design around the product.
Questions to ask vendors
- Map each recovery method you offer to the SP 800-63B-4 classes: saved codes, issued codes, recovery contacts and repeated identity proofing. Which of your methods fall outside them?
- Can security questions be disabled entirely, including as a hidden fallback?
- How do you enforce two independent recovery methods for AAL2 accounts, and what do you require for privileged users?
- Before sending an SMS or voice code, do you check for SIM change, device swap or number porting? What happens when a check fails?
- Can a help desk agent reset a password or MFA without a successful verification? If an override exists, who approves it and how is it alerted?
- After recovery, can the user go straight to passkey or security key enrolment, and can you block issuing a temporary password?
- Which notifications are sent after recovery, to which addresses, and can a user report "this was not me" from them?
- How is the service account or API credential that performs resets protected, and can its permissions be limited by user class?
- How do contractors and staff of an outsourced service desk use the product, and do they get the same controls and logs?
Red flags
- Security questions or employee ID plus date of birth offered as a verification method.
- SMS code accepted as the only factor for privileged account recovery.
- Temporary passwords read out or emailed as the standard end of a reset.
- Agents can mark a caller verified with a checkbox, or override without logging.
- No notification after recovery, or notification only to the newly added contact.
- Recovery addresses can be added and used in the same session without confirmation.
- The reset service account holds directory-wide rights with no scoping or monitoring.
Proof of concept
- Inventory every reset path today: phone, chat, email, walk-up, self-service, outsourced desk and administrator consoles.
- Configure two classes in the tool: standard users at AAL2 and privileged users, with stronger recovery and a second approver for the latter.
- Run end-to-end journeys for the common cases: forgotten password, lost phone, lost security key and new device, and time each one.
- Test the users you usually forget: frontline staff without corporate phones, contractors not in HR, and users with accessibility needs.
- Run social engineering tests with consent: a caller with the target's personal data, a request to skip verification, a SIM swap simulation before an SMS code, and a deepfake attempt at the proofing step.
- Confirm every recovery sends notifications, revokes existing sessions and ends in phishing-resistant enrolment.
- Check that a reset without a matching successful verification raises a SIEM alert.
- Define the outage fallback: a manual process with two people, manager attestation and a time-limited account, never a silent bypass.
Metrics for the pilot and beyond: share of resets with a successful verification (target 100% for privileged users), share of recoveries completed by self-service, agent overrides per month, recovery completion time, and recoveries reported as "not me" from notifications. Policy wording to go with the tool is in the Help Desk Identity Verification Policy Template, and the response plan in the Help Desk Social Engineering Incident Playbook.
How NHI Mgmt Group can help
We provide independent identity security advisory, including recovery design, help desk verification and product evaluation. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Account Recovery and Help Desk Security Guide · Workforce and Help Desk Identity Verification Buyer's Guide · Passkey account recovery · Help Desk Identity Verification Policy Template · Scattered Spider Threat Actor Profile