I work at a state university where Microsoft SSPR and other self-service options are available, but the help desk still receives calls from users who need assistance resetting a password. Our current process uses a custom SSH-accessed application. Staff enter the account name, review information pulled into a flat file from university systems, and ask the caller questions such as date of birth, address, and ZIP code. After verification, the application resets the password in Active Directory and displays a temporary password for the help desk to provide.
The process works, but the developer who maintains it is leaving, and we would rather not inherit an undocumented custom application. I'm interested in how other universities and organizations handle assisted password resets, especially for first-time users or people who have lost or changed their MFA device.
Do you use a commercial identity-verification product, an Active Directory or Entra integration, a help desk platform, or an internally developed tool? I'm particularly interested in workflows that verify callers securely, avoid exposing unnecessary personal information to help desk staff, and provide strong auditing for every reset.
5 Answers
Many organizations eliminate phone-based resets entirely. Users are directed to SSPR, and the help desk walks them through it without performing the reset. If that fails, the user must come in person or complete a video or identity-document verification process. It is less convenient, but it establishes a clear boundary and removes a high-risk social-engineering path.
The long-term answer is reducing password dependency. Strong passwordless authentication, hardware security keys, and well-designed recovery procedures make these calls much less common. For students and other large populations where managers cannot personally identify everyone, an in-person ID check or a reputable identity-proofing service is generally more defensible than asking personal-history questions over the phone.
If remote recovery is unavoidable, use layered verification and never give a new password to an untrusted number supplied during the call. Some organizations contact the registered number, obtain manager approval, or send the temporary credential to a supervisor who verifies the person and hands it over. Others require the user to connect from a managed, already-authenticated device so the help desk can assist them without revealing the password verbally. Every assisted reset should record the verifier, method used, approving person, target account, and time in an audit log that help desk staff cannot edit.
DOB, address, ZIP code, employee numbers, and similar knowledge-based questions are no longer reliable identity verification. Most of that information is available in public records, data breaches, or the university directory. If you keep an internal tool, have the help desk enter the answers supplied by the caller and return only a pass/fail result instead of displaying the person's records. That reduces unnecessary PII exposure and makes it harder for staff to browse other people's information. Ideally, the application should query the source systems directly rather than depend on a stale flat-file export.
That kind of application is often just a small query against the ERP anyway, so the university's ERP developers or analysts may be able to maintain a limited verification service without preserving the whole legacy program.
The safest approach is to separate ordinary password resets from account recovery. If the user still has a working authentication factor, have the help desk guide them through SSPR rather than resetting the password for them. If they have lost their phone, are a first-time user, or cannot complete SSPR, treat that as a higher-assurance recovery process with different rules. Options include a callback to a previously registered number, approval from a manager, an in-person ID check, or a document-and-selfie verification service for users nobody on staff personally knows. Temporary Access Passes can also help with enrolling a replacement factor, but they should only be issued after the identity check is complete.
A manual Duo or authenticator push can confirm that someone controls an existing device, but it should not be the only check when the other factor is being replaced. Otherwise the process has effectively become single-factor authentication.
This works best when the policy is applied consistently. Help users through the self-service flow once or twice, but avoid making a phone call an easier alternative to enrollment and MFA maintenance.