Do not drop verification to keep people logging in. Offer a stronger alternative such as an authenticator app, security key or passkey, keep a staffed recovery path, and avoid quietly falling back to a weaker method. The best fix is to reduce dependence on SMS before an outage forces the question.
What goes wrong in an outage
If login codes travel by SMS and your messaging vendor stops delivering, users cannot sign in or reset passwords. Pressure builds. The easy fixes are the risky ones: turning off the second step, extending code lifetimes, or letting support reset accounts on a weak identity check. Attackers know outages are good moments for social engineering.
Why SMS is a fragile choice anyway
NIST's digital identity guidance, SP 800-63B, treats use of the telephone network (SMS and voice) for out-of-band authentication as a restricted authenticator. Accepting it means assessing and accepting the risk, and verifiers must make sure alternative authenticator types are offered. Related posts cover the details: is SMS two factor allowed under NIST 800-63B and why SMS codes are a weak second factor. Delivery also depends on carriers and a vendor, which adds outages you cannot fix yourself.
Fallback options compared
| Option | Safe in an outage? | Notes |
|---|---|---|
| Authenticator app codes | Yes | Works offline on the phone, no vendor needed at login time |
| Passkey or security key | Yes | Strongest, and independent of message delivery |
| Email code | No, for authentication | The cited NIST text says email must not be used for out-of-band authentication |
| Backup recovery codes | Yes | Must be issued in advance and stored safely |
| Disable the second step | No | Opens every account to password attacks |
| Support resets on a short call | Risky | Needs a documented identity check |
A plan to write down now
- Enrol users in a second method before they need it. Prompt them after login, and when they add SMS.
- Issue backup recovery codes and tell users where to keep them. See MFA recovery codes and fallback without weakening MFA.
- Turn off SMS fallback once an authenticator is added, so attackers cannot downgrade. See turn off SMS fallback after adding an authenticator.
- Monitor delivery rates per country and carrier. A dip is an early warning.
- Decide failover rules. If you use a second SMS vendor, test it, and accept that the same carrier issues may still apply.
- Rate limit sends and watch for pumping abuse. See what is SMS pumping.
- Document the support recovery path, with identity checks and a second approver for high risk accounts.
- Tell users plainly what is happening and what they can do, without asking for codes or passwords in reply.
What not to queue
Do not store pending login codes to send later. A code delivered an hour late is expired or, worse, still valid for too long. Let users request a new one. Keep code lifetimes short. See how long should a verification code be valid.
Where Safeguard fits
Safeguard's asset discovery helps you see which messaging vendors your product depends on, and compliance evidence automation helps document your continuity plans. A free scan covers dependencies.
Quick check
Can I temporarily turn off the second step during an outage?
It is a risky shortcut. Prefer offering authenticator, passkey or recovery code options, and keep a staffed, verified recovery path.
Should I extend the code lifetime so late messages still work?
No. Let users request a fresh code instead. Longer lifetimes widen the window for guessing and interception.
Sources
Last reviewed: 19 October 2026.
