Should organisations keep SMS or email codes as a backup factor?

When should SMS or email codes be used as a backup factor?

SMS and email codes can serve as a fallback only when the organisation accepts that the channel is weaker than a phishing-resistant factor and that the backup is bounded by clear recovery rules. The main decision is not whether the code works, but whether the fallback reduces outage risk without creating a standing path to account compromise.

Why backup codes are different from a preferred MFA factor

Backup codes are usually justified by recovery needs, not by strength. A primary factor should resist phishing, interception, and easy replay; an SMS or email code often depends on controls outside the authentication system itself, including telecom security, mailbox security, device security, and user behaviour. For that reason, many organisations treat these channels as transitional controls rather than as the design target for everyday sign-in.

The practical distinction is between a factor that supports continuity during exceptional recovery and a factor that is expected to protect high-value access all the time. If the same channel is used for routine access, it becomes part of the normal attack surface and inherits weak-link dependencies that are hard to see in a login policy alone.

What makes SMS and email backups fragile in practice

SMS codes can be exposed through SIM swap, number port-out abuse, message forwarding, malware on the endpoint, or carrier-side weaknesses. Email codes can be defeated if the mailbox is already compromised, if message forwarding rules are abused, or if the account recovery chain is weaker than the protected application. In both cases, the backup factor often protects only as well as the weakest adjacent account, device, or help desk process.

That fragility matters most when the backup path can reset access to a production account, an administrator account, or a financial workflow. In those cases, the fallback is not just a convenience feature, it is an access path with material security impact.

How to decide whether the backup is acceptable

Use SMS or email only when there is a documented reason the organisation needs a lower-assurance recovery option and there is no better alternative that users can actually operate. A limited backup can be acceptable for low-risk accounts, for short migration windows, or for constrained recovery flows, but it should be hard to escalate into a permanent sign-in method.

Where stronger options exist, current guidance favours phishing-resistant methods such as security keys or passkeys for primary authentication, with recovery designed separately from daily access. NIST SP 800-63 Digital Identity Guidelines are useful here because they distinguish authenticator strength and emphasise phishing resistance in higher-assurance designs.

Risk and Threat Considerations

SMS and email backups create a recovery channel that attackers often target because it can bypass a stronger primary factor if the organisation treats the fallback as equivalent. The risk is highest where the same channel also supports password resets, session recovery, or privileged account recovery.

Failure mechanism: An attacker compromises the phone number, mailbox, endpoint, or recovery workflow, then uses the backup code path to obtain or reset access without defeating the primary factor.

Impact: Account takeover becomes easier, especially for privileged or high-value accounts, and defenders may misread the presence of MFA as meaningful assurance when the effective control is much weaker.

Practitioner Guidance

What to prioritise: Keep the backup path narrow. If SMS or email must exist, limit it to recovery, add short lifetimes, and prevent it from becoming the default login method.

What to verify: Confirm that the backup cannot independently unlock privileged access, cannot be reused indefinitely, and cannot be issued through a weak support process. Also verify that mailbox or phone compromise does not automatically become account compromise.

Decision rule: If the account can materially affect production systems, customer data, or financial action, prefer a phishing-resistant primary factor and treat SMS or email as an exception path only. If the organisation cannot enforce that boundary, the backup is too risky to keep.

Practitioner takeaway: The safest backup factor is the one that helps with recovery without silently becoming a second normal login path; once it can do both, it stops behaving like a backup.

Related resources from NHI Mgmt Group

• What happens when organisations keep SMS as a fallback authentication factor?
• How should organisations strengthen account security when moving beyond SMS or app codes for multi-factor authentication?
• What breaks when organisations rely on SMS or email MFA for sensitive access?
• How can organisations keep email detection resilient as threats change?