Your mother's maiden name is not verification.

“What is your mother's maiden name?” “What are the last four digits of your Social Security number?” Those answers may help locate a record. They do not prove that the caller is the employee.

A correct answer can still come from an attacker

We should stop treating personal facts as secrets. A caller may know an employee's address, date of birth, manager, maiden name, or partial government identifier without being that employee. The information may have been reused, disclosed, purchased, or inferred.

NIST's current digital identity guidance says knowledge-based verification and knowledge-based authentication should not be used for identity verification. Its guidance is written for federal digital identity systems, but the helpdesk lesson is straightforward: information associated with a person is not proof that the person on the phone is the employee.

A correct answer also says nothing about the requested operation. It does not establish which support case is active, which account is being changed, what action was requested, or whether the operator is allowed to perform it.

How should a helpdesk verify a caller before a password reset?

Start with the employee's record in the organization's directory, then verify the caller with an approved, already-enrolled factor. Do not let the caller supply a new phone number or email address and treat a successful challenge to that destination as proof.

For an ordinary helpdesk call, use this verification checklist:

• select the employee from the organization's identity system;
• verify that employee through an appropriate organization-managed factor;
• keep the result short-lived and connected to the active request; and
• make the sensitive action available only after operator role and policy have also been checked.

This does not mean every support call needs government-ID proofing. Routine requests can use the enrolled factors the organization already manages. Higher-assurance recovery methods remain appropriate when policy requires something stronger.

What if the caller has lost their phone?

Another supported, enrolled method may still be available. If no approved method is usable, pause the standard reset and follow the organization's documented recovery or re-proofing process. An urgent ticket is not a reason to replace verification with an easier personal question.

Make verification part of the support action

This is one reason we built Fctr Portal: to keep the selected employee, caller verification, supported action, and outcome in one workflow. A familiar voice or a correct personal answer is not treated as authority.

We deliberately keep verification separate from authorization. Verifying the employee does not automatically approve a reset, unlock, factor change, or other administrative action. It establishes who is participating in this support interaction. The configured role and policy still determine what the operator may do.

Stop asking callers to prove what they know. Ask them to prove control of evidence the organization already trusts, then decide whether the requested action should be permitted.

For the next step, see our helpdesk account-unlock workflow: verification establishes the caller; role and policy determine whether the agent may restore access.

Sources

• NIST — SP 800-63A — Identity Verification
• NIST — Digital Identity Guidelines FAQ — Knowledge-Based Authentication