A collector calls the IT support number from a new phone. The old phone is broken, the employee cannot approve the multifactor authentication prompt, and the next shift starts in twenty minutes. The caller knows the supervisor’s name, employee ID, and last four digits of the mobile number on file.
The request sounds reasonable. That is why the reset process needs more than a helpful technician and a few facts that may be easy to obtain.
Resetting MFA can place a new authenticator under someone else’s control. NIST treats adding an authenticator as a binding event and calls for the subscriber to be notified through a mechanism independent of that transaction.[1] A small collection agency should decide in advance who can authorize that event, how the employee’s identity will be checked, and what happens to the old factor and existing sessions.
This drill uses a fictional employee and a test account. Do not use a consumer record, real debtor information, a live collector account, or an actual authentication secret. The goal is to test the decision path without weakening production access.
Write the reset rule before the phone rings
Start with the systems a collector needs for a normal shift: email, the collection platform, document storage, remote access, calling tools, and any payment or customer portal. Record who administers each system and whether MFA is controlled in one identity platform or separately inside each application.
Then write a one-page reset rule. It should answer five questions:
- Who may request a reset?
- Which pre-established channel will the agency use to verify the employee?
- Who may approve a reset for an ordinary user and for an administrator?
- Which old factors, sessions, recovery methods, or temporary credentials must be removed?
- Which records and notifications must be retained?
Do not make possession of a name, birth date, employee ID, supervisor name, or account balance the only proof. The drill should use information or a channel established before the reset request. That might mean an in-person check by an authorized manager, a callback to a number already held in an approved personnel record, a previously issued recovery method, or another method selected by the agency’s security owner.
Keep the verifier out of the requester’s path. If the caller supplies a new number, email address, video link, or manager’s contact information during the call, do not use that same information to approve the reset. Open the trusted record through the agency’s normal system instead.
NIST recommends maintaining more than one means of authentication to reduce the need for account recovery.[1] The agency can review which platforms support a second approved authenticator or securely stored recovery method. Do not improvise a backup by sharing an administrator’s factor or storing a recovery code in an ordinary ticket.
Run the drill with a realistic request
Give the support person a fictional ticket: “Jordan Lee dropped a phone this morning and cannot receive MFA prompts. Jordan is working remotely and needs access before a 9:30 shift.”
The caller provides correct background details and becomes impatient when the technician pauses. The supervisor appears to send a quick message saying, “Please fix this now.” The exercise facilitator should not make the caller theatrical. A routine request under time pressure is enough.
Watch what the support person does next. A sound path should include these actions:
- open a ticket and record the affected account and system;
- use the approved verification method rather than details supplied during the call;
- obtain the required approval, with a separate review for a privileged account;
- remove or suspend the old factor before or as the replacement is bound;
- inspect and revoke sessions when the platform and circumstances call for it;
- notify the employee through a contact path already on record;
- record who requested, verified, approved, and completed the change.
NIST says providers should keep records of authenticators bound to an account and the time of significant authenticator events.[1]
It also says account recovery should trigger a notification to help the subscriber detect fraudulent recovery.[1]
NIST calls for a compromised authenticator to be suspended, invalidated, or destroyed promptly after the compromise is detected.[1]
Even when a business application does not provide every control, the agency can document the gap and decide whether an identity provider, compensating approval, or vendor change is needed.
Add one fork to the scenario. The approved manager cannot confirm the request, but the caller offers to answer security questions and send a photo of an ID. The technician should not invent a new recovery method during the call. The safe outcome may be a delay, a handoff to the security owner, or an in-person check under the written procedure.
That delay should be an expected operating condition. Managers need to know that a missed shift target does not authorize support staff to bypass the identity check. The exercise should identify who handles staffing while access is withheld and who can accept the remaining risk if an emergency process exists.
Check what the platform records
After the tabletop discussion, use a test account to inspect the actual controls. Do not assume the application behaves the way its settings page suggests.
Confirm whether the administrator can see every registered factor, the date it was added, recent sign-ins, recovery contacts, and active sessions. Test whether adding or replacing a factor sends an alert to a pre-existing address. Check whether the alert identifies the account, time, and action clearly enough for the employee to report an unexpected change.
Review the administrator log too. The FTC’s Safeguards Rule guidance tells covered financial institutions to implement MFA for access to customer information, periodically review access controls, and maintain logs of authorized-user activity to detect unauthorized access.[2]
The FTC lists collection agencies among its examples of financial institutions, but coverage and specific obligations depend on the business’s activities and regulator.[2]
The agency’s legal or compliance adviser should determine what applies; this exercise is operational guidance, not a compliance opinion.
The test record should show more than “MFA reset complete.” Capture the requester, verifier, approver, administrator, old-factor action, new-factor time, session action, notification result, and any exception. Avoid putting authentication secrets, recovery codes, ID images, or consumer data in the ticket.
Strengthen the path for higher-risk accounts
Start with accounts that can reset other users, change email routing, export records, alter payment settings, or administer the collection platform. These accounts deserve a stricter reset path and a second approver.
MFA methods do not all resist the same attacks. CISA notes that some forms remain vulnerable to phishing, push bombing, SS7 exploitation, or SIM-swap attacks, and recommends phishing-resistant MFA as the stronger target.[3]
CISA specifically urges system administrators and other high-value targets to implement phishing-resistant MFA or plan a migration to it.[3]
Ask each major provider whether it supports FIDO/WebAuthn for administrators and other higher-risk users. A migration plan can begin with the people who can change everyone else’s access.
Stronger MFA does not excuse a weak reset process. If support can remove the strong factor after a convincing phone call, the recovery path becomes the easier route into the account. Test both sides: how the user signs in on a normal day and how the agency proves identity when that method is unavailable.
Finish the drill with two assigned fixes. One may be adding a second approver for administrator resets. Another may be enabling independent alerts or documenting how to revoke old sessions. Give each fix an owner and due date, then rerun the scenario with a different support person.
For practical guidance on cyber risk and safer technology use, subscribe to Cyber & AI Insights.
If your collection agency wants an independent review of its account-recovery and administrator-access workflow, schedule a conversation with Your Data Guardian.