SMS, push, and OTP methods can still be intercepted, relayed, or tricked through man-in-the-middle attacks because they do not bind authentication strongly enough to the legitimate user and device. They may improve coverage versus passwords alone, but they do not provide the same phishing resistance as WebAuthn or FIDO security keys. The practical risk is credential replay during an active phishing session.
Why SMS, push, and OTP still fail under phishing pressure
These methods reduce friction compared with passwords alone, but they still rely on a shared secret, a one-time code, or an approval event that can be captured and replayed during a live phishing session. That means the attacker does not need to defeat the service, only the user’s decision path. The result is weaker assurance than phishing-resistant authenticators that bind the login to the real origin and device.
In practice, the weakness is not that these factors are useless, but that they authenticate a transaction in a context the attacker can imitate.
How the attack works in practice
Phishing-resistant authentication fails when the factor can be relayed in real time. An attacker typically presents a convincing fake login page or proxy, captures the user’s code or push approval, then forwards it to the legitimate service before it expires. Because SMS, push, and many OTP flows do not cryptographically bind the authentication to the intended site, the service may see a valid factor and issue a session anyway.
- SMS codes can be intercepted through SIM swap, SS7 abuse, or user relay into a fake login flow.
- Push approvals can be socially engineered with prompt fatigue, urgency, or MFA bombing until the user accepts.
- OTP apps improve delivery security but still allow code replay in a live proxy attack.
- Session hijack often follows immediately after factor acceptance, before the user notices anything unusual.
This is why standards such as NIST SP 800-63 Digital Identity Guidelines treat phishing-resistant authenticators, especially WebAuthn and FIDO security keys, as a stronger class than out-of-band or one-time-code methods. The control gap is most visible in remote access, help desk reset flows, and high-value admin logins where an attacker can stay in the middle long enough to finish the exchange.
These controls tend to break down when the login path depends on user attention instead of cryptographic origin binding, because the attacker can simply mirror the conversation and reuse the factor fast enough.
Common variations and edge cases
Tighter authentication often increases user friction and rollout cost, so organisations must balance adoption speed against phishing resistance. That trade-off matters because some environments still need layered step-up methods for fallback, recovery, or device loss, but those paths should not silently become the primary control for privileged access.
There is no universal standard for every login journey yet, but the practical rule is clear: treat SMS and push as convenience or recovery controls, not as strong proof against phishing. OTP is better than passwords alone, yet it still leaves exposure whenever the factor can be relayed before it expires.
Edge cases also matter. Legacy VPNs, shared workstations, call-centre resets, and cross-device login flows often weaken otherwise good authentication designs. In those settings, the apparent strength of MFA can hide a real phishing path if the session token, recovery channel, or approval workflow is easier to abuse than the password itself.
Risk and Threat Considerations
The core risk is credential replay and session theft during an active phishing interaction. Attackers favour these methods because they are widely deployed, familiar to users, and often accepted by services as sufficient proof once the code or approval arrives.
Failure mechanism: A phishing proxy, SIM swap, push fatigue campaign, or similar relay attack captures the factor in real time and forwards it to the genuine service before expiry. If the authenticator is not origin-bound, the service cannot distinguish the attacker’s relay from the user’s legitimate login.
Impact: Account takeover can occur even when the user “completed MFA”, which means privileged mail, SaaS, help desk, and admin sessions may be established without a password crack or malware infection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL3 — Phishing-Resistant Authenticator Assurance Level | Directly addresses phishing-resistant authentication strength for this login problem. |
| AAL2 — Multi-Factor Authenticator Assurance Level | Covers common MFA methods that still leave relay and prompt-abuse exposure. | |
| Recommendation — Require phishing-resistant authenticators for high-value and privileged access paths. Use AAL2 only where relay risk is acceptable and step-up controls are in place. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Maps the question to authentication strength and access control design. |
| Recommendation — Harden authentication choices so access decisions cannot be satisfied by easily relayed factors. | ||
| CIS Controls v8 | 6 — Access Control Management | Supports controlling and limiting weaker authentication paths for sensitive accounts. |
| Recommendation — Restrict weaker MFA methods from privileged and high-impact access use cases. | ||
Practitioner Guidance
What to prioritise: Move high-risk and privileged workflows to phishing-resistant authenticators first, then retire SMS and OTP from any path that can reach production data, administrative consoles, or finance actions.
What to verify: Confirm that the factor is bound to the origin and device, not just to a one-time code or approval prompt. If a user can satisfy the flow from a fake site, the control is still relayable.
Decision rule: If the account can materially affect customers, revenue, or administration, treat SMS and generic push as insufficient on their own and require a stronger method for primary authentication or step-up.
Common mistake: Assuming “MFA enabled” means phishing resistance. It often only means the attacker must steal a live factor instead of guessing a password, which is a meaningful improvement but not the end state.
Practitioner takeaway: The real test is whether the factor survives an attacker standing between the user and the service; if it does not, the organisation has reduced password risk without eliminating phishing risk.
Related resources from NHI Mgmt Group
- Why do passwords and one-time codes still leave organisations exposed to identity fraud?
- Why do passwords and SMS one-time passcodes still leave financial accounts exposed to fraud?
- Why do SMS and push-based one-time passwords increase risk during phishing campaigns against identity providers?
- When does a phishing-resistant login method still leave organisations exposed?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
