I work at a state university where Microsoft SSPR is available, but the help desk still receives calls from users who need assistance resetting a password. Our current process uses a custom SSH-accessible application. The technician enters the account name, reviews identity information from a flat-file export of university systems, and asks the caller questions such as date of birth, address, and ZIP code. After verification, the application changes the password in Active Directory and displays a temporary password for the technician to provide.
The process works, but the developer who maintains it is leaving, and we would rather not take ownership of an undocumented custom application. We are researching alternatives before rebuilding it.
For organizations that still support assisted password resets, especially universities, what does your workflow look like? Do you use a commercial identity-verification product, an AD or Entra integration, a help desk platform, manager approval, an in-person process, or something custom? We are particularly interested in a solution that lets staff verify callers securely and perform the reset without exposing unnecessary personal information or creating an easy social-engineering path.
5 Answers
For students and other populations where managers cannot reliably recognize the person, a third-party identity-proofing workflow may be more practical. Some services send the user a one-time link and require a selfie plus an approved photo ID, then return only a pass/fail result to the help desk. It adds friction and is not perfect, but it avoids giving technicians broad access to identity documents and is stronger than asking easily discovered questions.
If you retain the custom approach, consider replacing the flat-file export with a small service backed by your ERP or directory and have the application validate claims without revealing records. Restrict who can initiate resets, require a reason and verification method, log every action, and alert on unusual activity. Also look at temporary access passes, phishing-resistant authentication, and eventually passwordless sign-in so password recovery becomes less central to the support process.
Several organizations handle exceptions by using an already registered factor. Options include sending an approval push to a device the user still controls, calling back a verified number, sending recovery information to a registered alternate address, or having a manager validate the request through an established channel. A push alone should not automatically be enough to reset every other factor, since it only proves control of that device.
Do not use date of birth, address, ZIP code, or similar knowledge-based questions as the main proof of identity. That information is commonly exposed through public records, data breaches, and university directories. If you keep an internal tool, have the technician enter what the caller claims and return only a pass/fail result instead of displaying the user's personal information. Keep the verification and reset audit trail in a system the help desk cannot edit.
The safest approach is usually to separate ordinary password assistance from account recovery. If the user still has a working authenticator or registered device, have the help desk guide them through SSPR rather than resetting the password themselves. If they lost the device, are a first-time user, or cannot complete SSPR, treat that as a higher-assurance recovery process with stricter requirements, such as an in-person visit, manager verification, a callback to a number already on record, or a documented identity-check service.
That also makes the support boundary clearer: help desk can coach someone through self-service, but they do not bypass it simply because the user would prefer a manual reset.
For a lost phone or compromised account, we require supervisor involvement or an in-person check rather than trusting a new number supplied during the call.