Why do OTP, SMS and push approvals still fail against phishing?

They can be intercepted, relayed or exhausted by attackers before the login completes. OTP and SMS depend on transferable codes, while push approvals can be worn down through repeated prompts. In both cases, the factor can be manipulated through the same human interaction channel the attacker is already targeting.

Why OTP, SMS and Push Approvals Still Fail Under Phishing Pressure

One-time passwords, SMS codes and push approvals all depend on a user reacting inside the attacker’s phishing flow. That means they can still be relayed, exhausted or tricked in real time, even when the attacker never learns the secret long-term. The weakness is not just code theft, it is that the authentication factor can be manipulated through the same human channel the attacker is already controlling.

Where These Factors Break Down in Practice

OTP and SMS are transferable by design. If a victim can read and enter the code, an adversary who is relaying the login can usually do the same before the session expires. Push approvals fail differently but on the same principle: they create a binary approval event that can be nudged through prompt fatigue, confusing context or repeated requests until the user accepts.

That is why these methods are weaker against adversary-in-the-middle phishing than many teams expect. The attacker does not need to defeat the factor cryptographically if they can drive the user to supply or approve it during the live session. For a practical contrast between phishing-resistant and transferable methods, see MFA Guide and the identity assurance guidance in NIST SP 800-63 Digital Identity Guidelines.

Push-based methods are especially vulnerable when the approval prompt does not carry enough transaction context for the user to judge whether the request is legitimate. When the user cannot distinguish a real prompt from an attacker-driven one, the control becomes a timing and attention game rather than a proof of intent.

What Makes Phishing-Resistant MFA Different

The practical boundary is whether the authentication method is bound to the origin and the session, or whether it can be replayed elsewhere. Phishing-resistant methods reduce relay value because the authenticator response is tied to the genuine site or device context rather than a code that can be handed over or an approval that can be socially engineered.

That is why sms otp and generic push approval should be treated as convenience controls, not as strong resistance to targeted phishing. In higher-risk environments, the decision is less about adding another factor and more about selecting a factor that cannot be cleanly transferred into the attacker’s login flow.

For teams comparing options, MFA Guide is useful because it contrasts OTP, SMS, push and phishing-resistant methods in operational terms, not just vendor labels.

Risk and Threat Considerations

These factors fail most often when the attacker can proxy the session, pressure the user in real time, or trigger approval fatigue. The risk is highest where the second factor is the last barrier protecting high-value accounts, privileged access or customer-facing systems.

Failure mechanism: The attacker relays an OTP or induces repeated push prompts until the user completes the live challenge, so the factor protects the wrong party in the wrong session.

Impact: A successful phish can lead to account takeover, token theft, privileged session establishment or follow-on fraud even though MFA was enabled.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Covers phishing-resistant authenticators and authenticator assurance levels for this MFA question
Recommendation — Prefer phishing-resistant authenticators and match assurance level to the account risk.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Applies to user authentication controls that OTP, SMS and push approvals are meant to satisfy
Recommendation — Require stronger authentication methods where account compromise would be material.
OWASP ASVS	V6 — Authentication	Addresses authentication strength and resistance to bypass in application sign-in flows
Recommendation — Use phishing-resistant authentication requirements for sensitive sign-in paths.
OWASP API Security Top 10	API2 — Broken Authentication	Authentication failures include weak or relayed second factors when APIs and sessions are abused
Recommendation — Treat transferable second factors as a broken-authentication risk in exposed login flows.
CIS Controls v8	CIS-6 — Access Control Management	Supports limiting account exposure by strengthening and managing authentication methods
Recommendation — Replace weak MFA methods on high-value accounts and revoke legacy access paths.

Practitioner Guidance

What to verify: Check whether your current MFA method is actually phishing-resistant or only second-factor resistant. If a user can move the factor from the real sign-in to an attacker-controlled prompt, it is not a reliable control against relay-style phishing.

Decision rule: If the account protects sensitive data, administrative functions or high-impact transactions, move away from transferable OTP and SMS as the primary safeguard and prefer methods that bind authentication to the authentic site or device.

What practitioners underestimate: Push fatigue is not just a user-experience problem. It is a control weakness when repeated prompts, weak context and poor alerting let an attacker convert human impatience into authentication success.

Practitioner takeaway: The real question is not whether MFA exists, but whether the specific factor can still be relayed or socially engineered inside a live phishing session.