If your login asks for a password and then a six-digit code by SMS, you are safer than with a password alone.
That deserves saying first, because the rest of this article is about limits, and the right conclusion is not "turn off MFA until you have something perfect".
It is "know what SMS protects against, what it does not, and plan the next step".
What SMS codes do well
- They need no app installation, so adoption is nearly universal.
- They stop the most common attack: a reused or guessed password used by someone with no access to the victim's phone number.
- They are easy to explain to non-technical staff.
For a first deployment of MFA across a large and varied workforce, that matters.
Watch out
A six-digit code can be typed into a fake page. Moving from SMS to an authenticator app helps; moving to a passkey ends that attack.
Where SMS falls short
The channel is not controlled by you. A code sent as a text message passes through telecom networks and the SMS gateway you use. The user's account security depends on the mobile carrier as much as on your own systems.
SIM swap. An attacker persuades a carrier, or a carrier's agent, to move the victim's number to a SIM the attacker holds. Every text, including login codes, now goes to the attacker. The attack is targeted, but it is well documented and has been used against finance and executive accounts.
Interception. Weaknesses in telecom signalling, malware that reads messages on a phone, and message forwarding features can all expose a code in transit or on arrival.
Phishing. This is the most common practical failure. A convincing fake sign-in page asks for the password and then the code, and relays both to the real site immediately. The code is valid for a few minutes, which is plenty. Any code the user can read and type can be phished, whether it arrived by SMS or from an authenticator app; SMS just adds more ways to lose it.
Social engineering of the user. People are trained to read codes out to "support" callers. A code looks harmless to them.
NIST SP 800-63B treats out-of-band authentication delivered over the public switched telephone network, which includes SMS, as a restricted authenticator.
In plain terms: it is still permitted, but the guidance asks organisations to understand the risk, offer alternatives, and not rely on it as the only option.
If you work under a sectoral regulator, check your regulator's cyber-security guidance and speak to compliance counsel about what it expects for your use case.
Reliability problems that are not about attackers
Operational issues drive more help-desk tickets than attacks do.
- Delivery delays and failures. Messages to Indian mobile numbers pass through registered sender and template rules, and delivery can be slow or inconsistent at peak times or across carriers. A code that arrives after it has expired is a failed login.
- Roaming and low signal. Travelling staff, basement offices and remote sites often cannot receive texts.
- Shared and role devices. In many workplaces, a handset is shared among a shift team, or a number belongs to a supervisor, a relative or a previous employee. A code sent to the wrong person is both an access failure and a privacy problem.
- Number changes. People change numbers without telling HR, and the old number may be recycled.
- Cost. Per-message charges add up across a large workforce with frequent logins.
The factor ladder
A way to think about this is a ladder, from weakest to strongest against phishing:
| Factor | Phishable in real time? | Notes |
|---|---|---|
| Password only | Yes | Baseline |
| SMS code | Yes, plus SIM swap and interception | Wide reach, weak assurance |
| Authenticator-app code (TOTP, RFC 6238) | Yes, by relay | No telecom dependency, works offline |
| Passkey or security key (WebAuthn) | No, bound to the real domain | Strongest common option |
The step from SMS to an authenticator app removes the telecom channel from the picture and costs nothing per login. The step from an authenticator app to a passkey removes the phishing relay.
More detail on each is in Choosing MFA factors and Passkeys explained.
A balanced migration plan
You do not need to abolish SMS on day one.
- Keep SMS available as a fallback, not a default, once better methods are offered.
- Make an authenticator app the standard second factor for everyone with a smartphone. Show people how to scan the QR code during enrolment and to keep a recovery method.
- Offer passkeys to people on supported devices, starting with administrators and finance or HR roles.
- Provide a non-phone route for people who cannot hold a smartphone at work: a hardware security key is one option.
- Restrict SMS for sensitive actions. For high-risk steps such as changing payout details or admin settings, require a stronger factor through step-up authentication.
- Protect the recovery path. If the fallback for a lost authenticator is "send an SMS", the SMS is still your effective security level.
- Monitor. Watch for phone number changes shortly before a password reset, and for many failed codes in a short time.
Practical hardening if you must keep SMS for now
- Keep codes short-lived, single-use, and tied to the specific login attempt.
- Rate-limit code requests per account and per number, so the channel cannot be used for spamming or enumeration.
- Do not reveal in the error message whether a number is registered.
- Notify the user by email when their phone number is changed, and require a verification step on the new number.
- Record each delivery and verification outcome in your audit log, so a pattern of failures is visible.
Where AuthMantra stands
AuthMantra supports authenticator-app codes (TOTP) and passkeys, and also SMS codes. The integration with an SMS provider is still planned, so we would not suggest planning a production rollout that depends on SMS delivery from us today.
For most workforces we would suggest the authenticator app and passkeys as the main route.
What to do this week
- Count how many of your users rely on SMS as their only second factor.
- Ask the help desk which login problems they hear about most, and see how many involve codes not arriving.
- Pick one group, such as IT administrators, and move them to an authenticator app or security key.
- Review your recovery process for a lost phone, and remove any path that is weaker than your normal login.
- Check the glossary entry for MFA and share it with the team who handle support calls.