The Monday Morning Test: Proving MFA Recovery Before It Is Needed

Multi-factor authentication is now a baseline control for UK SMEs, and for good reason. It raises the cost of account takeover, frustrates credential-stuffing and gives identity providers a chance to spot anomalous sign-ins. Yet a control that cannot be recovered is only half a control. The business discovers the other half on a Monday morning, when the finance director cannot approve payments, the service desk cannot verify a caller, and nobody can find the person who holds the recovery key.

The uncomfortable truth is that many organisations have tested whether MFA blocks an attacker. Far fewer have tested whether the business can regain access safely when a legitimate user is locked out. Those are different exercises with different failure modes. One tests the front door; the other tests whether the keys are where the business thinks they are.

Recovery is a control in its own right

MFA shifts risk rather than removing it. It creates dependencies on devices, enrolment processes, identity providers, service desks and the people who administer them. In a lean UK SME, those dependencies often run through one or two individuals. That is efficient until it is not.

The National Cyber Security Centre has long warned that recovery processes can become the weakest link in an otherwise sound identity programme. An attacker who cannot phish a code may instead ring the helpdesk, claim to be a locked-out director and exploit a hurried verification process. The control that restores access can therefore become the control that grants it to the wrong person.

The objective is not to make recovery frictionless. It is to make it predictable, evidenced and no weaker than the front-door control it supports.

Four scenarios worth rehearsing

A useful tabletop exercise does not need expensive tooling. It needs a facilitator, a realistic scenario and a willingness to find gaps. Four failure modes cover most of the ground for a typical SME:

1. Lost phone. A senior user loses a device on Friday evening and needs access before a Monday payment run. Who verifies identity, how, and what is the temporary replacement factor?
2. Starter without a device. A new joiner arrives before their phone or security key is available. What is the approved path, and does it create a temporary bypass that nobody removes?
3. The only administrator leaves. The person who knows the break-glass process, recovery codes and tenant settings hands in their notice. What is transferred, when, and how is it proven?
4. A helpdesk call that does not add up. A caller claims to be the chief executive, pressures the service desk and provides partial information. Does the verification script hold under pressure?

Each scenario should be run against the current process, not an imagined future one. The point is to expose the difference between what the policy says and what the team would actually do.

Set the rules before anyone picks up the phone

A tabletop exercise works best when it is time-boxed and safe. No real credentials should be changed during the session. The facilitator should state the scenario, assign roles and ask the team to narrate each step: who they would contact, what evidence they would request, where they would record the decision and how they would restore normal service.

Useful measures include time to restore access, number of people involved, quality of identity verification, completeness of the audit trail and whether the user's original MFA enrolment is re-established afterwards. A process that restores access in ten minutes by disabling MFA for an hour has not passed the test. It has simply moved the risk.

Break-glass accounts need governance, not secrecy

Break-glass accounts are a sensible contingency for identity-provider lockout. They are also a common source of quiet risk. A shared break-glass account with a password in a spreadsheet is not a control; it is a back door with a rota.

A defensible approach uses a small number of dedicated accounts, strong phishing-resistant authentication such as hardware security keys, secure storage with restricted access, alerting on every use and a documented owner. The credentials should be tested on a scheduled basis, not left until an incident. The test should confirm that the account still works, that the alert reaches the right people and that the person who used it can explain why.

Crucially, break-glass use should be exceptional and reviewed. If it becomes the normal route for Monday lockouts, the organisation has a process problem, not an MFA problem.

Recovery codes and helpdesk verification

Recovery codes are easily created and easily mislaid. The exercise should establish where they are stored, who can retrieve them, whether they are single-use, when they were last regenerated and how retrieval is logged. A code stored in the same mailbox as the account it protects is not a recovery plan.

Helpdesk verification deserves equal scrutiny. A workable script asks for information that an attacker is unlikely to know, uses a callback to a known number rather than one supplied by the caller, and escalates unusual requests to a second person. Manager confirmation has a place, but it should not be the only check. The aim is to make social engineering slower and more visible, not to make legitimate recovery impossible.

Joiner-leaver handoffs are where recovery quietly breaks

Recovery plans often fail at the edges of employment. New starters need a verified enrolment path before their first working day, not an ad hoc bypass because the device has not arrived. Leavers need their MFA methods, sessions, recovery codes and admin roles revoked as part of the same checklist that disables their account.

Where an administrator leaves, the handover should include the location of break-glass credentials, the identity-provider configuration, outstanding recovery requests and any supplier-held admin rights. A departure checklist that covers email and payroll but not identity recovery is incomplete.

A ninety-minute agenda that produces evidence

A practical session can follow a simple sequence. Spend ten minutes agreeing scope and roles. Spend fifteen minutes walking through each of the four scenarios. Spend twenty minutes testing the evidence trail: what would be logged, where and for how long. Spend fifteen minutes reviewing break-glass and recovery-code access. Spend twenty minutes assigning actions with owners and dates. Reserve ten minutes to agree how the exercise will be repeated.

The output should be a short record: scenarios tested, people involved, gaps found, decisions taken and actions assigned. That record is more useful to a board than a dashboard showing MFA coverage alone, because it demonstrates that the control has been tested under realistic pressure.

What good looks like

A mature recovery process is not secretive or heroic. It is documented, delegated and tested. More than one person can initiate it. Identity verification is proportionate and recorded. Break-glass use is rare, alerted and reviewed. Joiners are enrolled before day one and leavers are removed completely. The organisation knows how long recovery takes and accepts that time as a business risk.

For ResultIT, the measure is straightforward: can the business regain access safely, with evidence, without weakening the controls that keep attackers out? If the answer is uncertain, the next Monday morning is not the time to find out.