The MFA reset is the front door

Organisations spend years rolling out multi-factor authentication, and rightly — it removes most of the value from a stolen password. Then they leave a single, legitimate, supported route to switching it off: ring the help desk and say you have a new phone.

That route is not a flaw to be closed. Devices genuinely get lost, people genuinely start new jobs, and a desk that cannot re-enrol a token is a desk that cannot function. The task is to make the route narrow enough that only the genuine version fits through it.

Why this specific request

An attacker choosing where to spend their effort is looking for the action that yields the most access for the least technical work. MFA re-enrolment wins on both counts:

• It requires no vulnerability, no malware and no infrastructure — just a phone call.
• It defeats the control that most other defences assume is working.
• It is a routine request, so the engineer handling it is not primed for an attack.
• It has a built-in cover story that cannot be disproved: the device is gone, so of course the caller cannot use it.

That last point deserves attention. Most verification schemes quietly assume the caller can still be reached on a channel you trust. The MFA reset is defined by the caller claiming they cannot. The request is an argument for lowering the bar, delivered by the person who benefits from it being lowered.

The playbook

1. Treat it as its own class of request

Do not file MFA re-enrolment under password resets. It is a different risk with a different threshold, and lumping them together means the more dangerous one inherits the weaker rule. Certra treats it separately for exactly this reason — see MFA reset security.

2. Verify on a channel the caller did not choose

The caller says the phone is gone. Fine — that removes one factor, not all of them. Use the remaining registered channels: a call-back to a desk phone, a message to the email address on the record, a passphrase agreed in advance, or confirmation from the person's line manager where that manager is a named approver on the account.

The principle is simple: the channel must be one you already held, not one the caller supplies during the call. A caller offering a new number to receive the code is describing the attack.

3. Require a second person for privileged accounts

For domain admins, finance approvers, senior executives and anyone with access to the money, one engineer's judgement on a phone call is not an adequate control — not because the engineer is unreliable, but because they are alone, under time pressure, and being actively persuaded. A named approver at the client turns a judgement call into a decision with two people in it.

4. Invert the seniority reflex

The instinct when a senior person calls is to reduce friction. Attackers know this precisely as well as you do, which is why they impersonate executives rather than warehouse staff. Seniority should raise the threshold, and the policy should say so in writing, so that an engineer holding the line is following a rule rather than making an awkward personal choice.

5. Add a delay you can defend

A short mandatory wait on privileged re-enrolments — even fifteen minutes, with a notification to the account owner and the client's security contact — costs a genuine user very little and destroys the economics of the attack. Social engineering depends on completing the whole sequence inside one call, before anyone compares notes.

6. Write down what happened

Which factors were tested, which matched, who approved, what time. If the reset is later questioned, this is the only thing standing between you and a reconstruction from memory. It should be captured automatically and be impossible to edit afterwards.

The failure mode worth naming

Every one of the steps above is easy to write and easy to skip, and they get skipped in the same circumstances: end of the day, a queue building, a caller who is annoyed and senior. Rules that depend on an engineer's resolve at their most tired moment are not controls, they are hopes.

Which is the argument for putting the threshold in the system rather than the handbook. If re-enrolment on a privileged account cannot proceed without an approver's sign-off, then no amount of pressure on the phone changes the outcome — and the engineer gets to say "the system won't let me", which is a far easier sentence to deliver than "I don't believe you".