Every MFA rollout generates exceptions. Someone loses their phone. A legacy application cannot support MFA. A senior executive insists they need to be excluded. A contractor needs temporary access. How you handle these exceptions determines whether your MFA deployment is genuinely secure or full of exploitable gaps.
This lesson covers the two most critical operational challenges of MFA: managing exceptions without undermining security, and handling recovery codes so they do not become a backdoor into your organisation.
Why Exceptions Are Dangerous
An MFA exception is any account that is exempt from your MFA requirement. Every exception is a potential entry point for an attacker. Attackers actively look for accounts without MFA — they are the path of least resistance.
The problem is not that exceptions exist. In any real-world deployment, there will be legitimate situations where MFA cannot be applied immediately. The problem is when exceptions are granted informally, are not tracked, have no expiry date, and are never reviewed.
Diagram
MFA Exception Risk Model
Funnel diagram — Top: Total accounts in organisation. Middle: Accounts with MFA enforced (protected). Bottom: Accounts with MFA exceptions (exposed). Arrow showing that attackers concentrate effort on the exception accounts. Sidebar showing the risk factors: no expiry, no review, no compensating controls.
Building a Formal Exception Process
Every MFA exception should be treated as a risk acceptance decision — not an IT convenience. A proper exception process includes:
- Written request — the person requesting the exception must explain why MFA cannot be applied to this account or system
- Risk assessment — document what data or systems the account can access and what the impact would be if it were compromised
- Named approver — a senior business owner (not just IT) must formally approve the exception and accept the residual risk
- Compensating controls — if MFA cannot be applied, what additional safeguards will be put in place? Examples include IP restriction, enhanced monitoring, shorter session timeouts, or stronger password requirements
- Expiry date — every exception must have a defined review date (maximum 90 days). At review, the exception must be re-justified or removed
- Register — all exceptions must be recorded in a central register that is reviewed regularly
This may feel bureaucratic for a small organisation. It does not need to be complex — even a simple spreadsheet tracking the account, reason, approver, compensating controls, and review date is sufficient. What matters is that every exception is visible, justified, and time-limited.
Common Exception Scenarios and How to Handle Them
- “I lost my phone.” This is not an exception — it is a recovery scenario. The user should use a pre-registered backup method (backup codes, secondary phone, hardware key). If none exist, follow your MFA reset process with proper identity verification before re-enrolling.
- “This application doesn’t support MFA.” Investigate whether the application supports modern authentication protocols. If it genuinely cannot support MFA, apply compensating controls (IP restriction, dedicated service account with limited permissions, enhanced logging) and set a timeline to replace or upgrade the application.
- “The CEO doesn’t want to use MFA.” This is a risk acceptance decision, not a technical exception. The CEO’s account is one of the most targeted in any organisation. Document the risk clearly — including the potential for business email compromise and invoice fraud — and require formal sign-off. In most cases, a conversation about the actual risk changes the decision.
- “We need a shared account for the front desk.” Shared accounts and MFA are fundamentally incompatible because MFA is tied to an individual. Options include converting to individual accounts, using a shared mailbox that does not require direct login, or applying compensating controls with documented risk acceptance.
Recovery Codes: The Hidden Backdoor
Recovery codes (also called backup codes) are one-time-use codes generated when a user first enrols in MFA. They allow login if the primary MFA device is unavailable — a lost phone, a dead battery, a new device. Every major platform offers them.
The problem is that recovery codes are essentially static passwords. If an attacker obtains a user’s recovery codes, they can bypass MFA completely. This makes how you store and manage recovery codes a critical security decision.
Diagram
Recovery Code Lifecycle: Generation to Expiry
Flow diagram — MFA enrolment → Recovery codes generated → Secure storage (encrypted password manager or physical safe) → Code used in emergency → Code invalidated after use → New codes generated if needed. Red warning path showing: codes stored insecurely → attacker finds codes → MFA bypassed.
Best Practices for Recovery Codes
- Store recovery codes in an encrypted password manager — not in a text file, not in email drafts, not on a sticky note, and not in a shared document. If your organisation uses a password manager, recovery codes should be stored there.
- For administrator accounts, store backup codes in a physical safe — printed on paper and sealed in an envelope, stored alongside your break-glass account credentials. Physical security prevents remote compromise.
- Limit the number of recovery codes generated — most platforms generate 8–10 codes by default. Each code is a potential bypass. Generate only what is needed and regenerate (invalidating old codes) periodically.
- Track recovery code usage — if a recovery code is used, investigate why. Was the user’s phone lost? Did they get a new device? Or has someone else obtained their codes?
- Regenerate codes after any use — once a recovery code has been used, assume the remaining codes may also be compromised. Regenerate a fresh set and securely destroy the old ones.
- Never share recovery codes over email or chat — if a user requests their recovery codes, they should access them directly through their account settings or retrieve them from secure storage. Recovery codes sent over email can be intercepted.
The MFA Reset Process
When a user genuinely cannot access their MFA device or recovery codes, you need a process to reset their MFA enrolment. This is one of the most exploited processes in social engineering attacks — an attacker calls the helpdesk, claims to be a user who lost their phone, and persuades the helpdesk to reset MFA, giving the attacker full access.
Your MFA reset process must include identity verification:
- Verify the user’s identity through an out-of-band channel (e.g., video call, in-person verification, callback to a known phone number)
- Never reset MFA based solely on an email or chat request
- Require manager approval for MFA resets
- Log all MFA resets and review them regularly for patterns
Diagram
Secure MFA Reset Process Flow
Decision flow — User requests MFA reset → Identity verification (video call, in-person, or callback to known number) → Manager approval → MFA reset performed → New MFA method enrolled immediately → Incident logged and reviewed. Red path showing: reset without verification → social engineering attack succeeds.
Why This Matters
The 2023 MGM Resorts and Caesars Entertainment breaches both began with social engineering attacks against IT helpdesks to reset MFA. The attacker group Scattered Spider specialised in calling helpdesks, impersonating employees, and convincing support staff to reset MFA — giving the attackers direct access to corporate environments. The combined cost of these two breaches exceeded $200 million.
Your MFA deployment is only as strong as its weakest exception and its reset process. A rigorous approach to both turns MFA from a checkbox exercise into genuine protection.
What to Do Now
- Create a simple MFA exception register (spreadsheet is fine) documenting all current exceptions with reason, approver, compensating controls, and review date
- Review any existing MFA exceptions — remove those that are no longer justified
- Establish a written MFA reset process that requires identity verification through an out-of-band channel
- Ensure all users have generated and securely stored recovery codes
- Brief your helpdesk or IT support on the MFA reset process and the social engineering risks it faces
- For admin accounts, store recovery codes in a physical safe alongside break-glass credentials
Evidence to Collect
- Your MFA exception register with current entries, approvers, and review dates
- A documented MFA reset process including identity verification requirements
- Evidence that recovery codes for admin accounts are stored securely (e.g., confirmation of safe storage)
- Helpdesk training materials or briefing notes on social engineering risks during MFA resets
- Logs of any MFA resets performed, with the verification method used
Common Mistakes
- Granting MFA exceptions informally with no record. Untracked exceptions accumulate over time and create invisible security gaps. Every exception must be documented, time-limited, and reviewed.
- Allowing MFA resets based on email or chat requests alone. This is the exact attack vector used in major breaches. Always verify identity through a separate channel before resetting MFA.
- Storing recovery codes in email, shared drives, or plain text files. Recovery codes are equivalent to a password that bypasses MFA. Treat them with the same — or greater — security as passwords themselves.
- Letting exceptions become permanent. An exception approved six months ago for a “temporary” situation often persists indefinitely because no one reviews it. Mandatory expiry dates with re-approval requirements prevent exception drift.
- Not briefing the helpdesk on social engineering. Your helpdesk is a direct target for attackers seeking MFA resets. They need specific training on verifying identity and recognising social engineering tactics.
Knowledge Check
Question 1 of 3
What should every MFA exception include?
- A verbal agreement from the IT team
- A written request, risk assessment, named approver, compensating controls, and an expiry date
- An email from the affected user confirming they understand the risk
- Approval from the software vendor
Reveal Answer
B. A proper MFA exception requires a written request, documented risk assessment, approval from a named senior business owner, compensating controls, and a mandatory expiry/review date. This ensures exceptions are visible, justified, and time-limited.
Question 2 of 3
Why are MFA recovery codes considered a security risk?
- They expire too quickly to be useful
- They are essentially static passwords that bypass MFA — if stolen, an attacker gains full access
- They only work on the original device
- They are automatically shared with all administrators
Reveal Answer
B. Recovery codes are one-time-use codes that allow login without the MFA device. If an attacker obtains them — from a text file, email draft, or insecure storage — they can bypass MFA entirely, which is why secure storage is critical.
Question 3 of 3
What attack method was used in the 2023 MGM Resorts and Caesars Entertainment breaches?
- Brute-force password attacks against admin accounts
- Zero-day exploits against the company’s firewall
- Social engineering against the IT helpdesk to reset MFA
- Physical break-in to steal hardware security keys
Reveal Answer
C. The Scattered Spider group called IT helpdesks, impersonated employees, and convinced support staff to reset MFA — giving the attackers direct access. This demonstrates why MFA reset processes must include robust identity verification through out-of-band channels.
Summary Notes — Handling MFA Exceptions and Recovery Codes
Key Takeaways
- Every MFA exception is a potential entry point — treat each one as a formal risk acceptance with documentation, approval, compensating controls, and expiry.
- Recovery codes are static passwords that bypass MFA. Store them in encrypted password managers or physical safes — never in email, chat, or plain text files.
- The MFA reset process is a primary social engineering target. Always verify identity through an out-of-band channel before resetting.
- Helpdesk staff need specific training on social engineering tactics used to manipulate MFA resets.
- Exceptions without expiry dates become permanent security gaps.
Action Items
- Create and maintain an MFA exception register with review dates.
- Document and communicate a secure MFA reset process.
- Ensure all recovery codes are stored securely; admin codes in a physical safe.
- Train helpdesk staff on social engineering risks during MFA resets.
- Review all existing exceptions and remove any that are no longer justified.
Compliance Relevance
ISO 27001 Annex A.5.1 (Information Security Policies) requires documented exception processes for security controls. Cyber Essentials expects MFA without undocumented exceptions. NIST CSF PR.AC-7 requires authentication controls with documented alternatives where primary controls cannot be applied. An MFA exception register with named approvers and review dates directly satisfies these audit requirements.