Shared OTPs can be intercepted, replayed, or socially engineered because the secret travels through a reachable channel rather than staying cryptographically bound to the intended device and site. Phishing-resistant methods reduce that interception window, which is why they are becoming the preferred control in regulated consumer banking.
Why shared OTPs are fundamentally easier to abuse
Shared OTPs weaken the trust boundary because the code is not bound to a single user action, device, or site in the way modern phishing-resistant methods are. Once a one-time code can be observed, relayed, or requested through a fake login flow, it becomes a reusable bearer secret for the attacker’s session rather than proof that the intended user approved the transaction.
That creates a different fraud profile from phishing-resistant authentication. A phished OTP is often good enough to complete a login even when the user is careful later, because the attacker only needs a short window to capture and use the code. By contrast, phishing-resistant methods are designed to make that relay step fail, so the attacker cannot so easily turn social engineering into account access.
Shared OTPs are also vulnerable to help-desk manipulation, SIM swap, inbox compromise, and real-time proxy phishing, which means the risk is not just “guessing” a code. The material issue is that the secret travels through a reachable channel and can be intercepted before it expires, especially when the surrounding recovery or fallback process is weak.
Why phishing-resistant authentication changes the fraud equation
Phishing-resistant authentication raises the cost of attack by binding the credential to the legitimate origin and, in many implementations, to the device that holds the private key. That means a copied code or a relayed login prompt is no longer enough, because the attacker does not get a transferable secret that can be replayed from elsewhere.
For fraud teams, the important distinction is not simply “stronger MFA,” but whether the method resists interception and replay under active phishing conditions. NIST SP 800-63 Digital Identity Guidelines treats phishing-resistant authenticators as a higher-assurance control because they reduce the attacker’s ability to reuse captured authentication material. That is why passkeys, security keys, and other origin-bound methods are preferred over shared OTPs when fraud pressure is high.
In practice, the fraud reduction comes from removing the attacker’s easiest path: real-time code theft. If the login ceremony itself makes relay or code replay impractical, then the attacker has to shift to harder problems such as device compromise, session theft, or account recovery abuse.
Where fraud still enters the picture
Phishing-resistant authentication does not eliminate fraud by itself, but it narrows the abuse paths. Attackers may still target enrollment, recovery, support workflows, or already-compromised sessions, which is why the surrounding identity lifecycle matters as much as the login factor itself. Passwordless and Passkeys Guide explains how secure recovery and rollout discipline affect whether the control holds up after deployment.
Shared OTPs, by contrast, are exposed to a much wider set of common fraud tactics because the attacker only needs the user to reveal or forward a short-lived secret. That is why OTP-based flows often fail under adversary-in-the-middle phishing, consent manipulation, and social engineering of support staff. MFA Guide shows how OTPs are bypassed in practice through relay, fatigue, and token theft patterns.
One useful way to frame the difference is that shared OTPs are a control against unauthorised access only when the delivery channel remains trustworthy, while phishing-resistant methods keep the authenticator itself outside that reachable channel. That makes the latter better aligned to fraud scenarios where an attacker is actively trying to impersonate the customer in real time.
Risk and Threat Considerations
Shared OTPs create a fraud exposure because they can be captured through phishing, forwarded by the victim, or intercepted in transit, and then used before expiry. The weakness is not the short lifespan of the code, but the fact that the code is still a transferable secret that can cross the trust boundary.
Failure mechanism: An attacker sets up a convincing login flow or support interaction, obtains the OTP, and immediately replays it to complete the session before the user or system can intervene.
Impact: The result is account takeover, fraudulent access, and a clean path into downstream actions such as payment redirection, profile changes, or abuse of recovery settings.
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, CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authenticators and authenticator assurance levels directly address this login fraud question. |
| Recommendation — Adopt phishing-resistant authenticators for high-risk sign-in flows and reduce reliance on replayable OTPs. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is about reducing account takeover risk from weak login methods and recovery paths. |
| Recommendation — Restrict high-risk authentication methods and remove unnecessary fallback access paths. | ||
| OWASP ASVS | V6 — Authentication | Authentication strength and phishing resistance are central to the control comparison in this question. |
| Recommendation — Verify that authentication flows resist replay, phishing, and session impersonation. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared OTPs versus phishing-resistant authentication is fundamentally an access-control design choice. |
| Recommendation — Define and enforce stronger access-control requirements for sensitive sign-in flows. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The question concerns how users are authenticated and how that affects fraud exposure. |
| Recommendation — Use stronger user authentication methods where replayable OTPs create unacceptable risk. | ||
Practitioner Guidance
What to prioritise: Treat phishing-resistant sign-in as the default for any customer or employee flow where account takeover converts directly into fraud loss, support burden, or downstream privilege abuse. If OTPs remain, confine them to lower-risk fallback paths and review whether they are being used because of genuine compatibility needs or simple legacy inertia.
What to verify: Check that recovery, help-desk reset, and step-up flows do not reintroduce the same weakness the primary factor was meant to remove. A deployment is not truly phishing-resistant if a call to support, SMS fallback, or weak recovery question can still hand the attacker a transferable login path.
Practitioner takeaway: The real control objective is not “one-time” authentication, it is preventing the secret from becoming a replayable fraud token in the attacker’s hands.
Related resources from NHI Mgmt Group
- Why do SMS-based authentication methods create more risk in environments exposed to phishing and SIM-swap fraud?
- Why do SMS OTPs create higher fraud and recovery risk than device-bound authentication?
- Why does shared-device retail authentication create higher fraud risk?
- Why do shared SaaS breaches create such high downstream phishing risk?