They prove knowledge of a secret, not presence on a specific registered device. Passwords can be phished, leaked, or stuffed, and OTPs can be relayed in real time. If the attacker can log in from another machine, the account can still be used for harmful actions unless a stronger, device-bound control is required at the action layer.
Why passwords and OTPs fail against account takeover fraud
Passwords and OTPs answer a narrow question: can the user prove knowledge of a secret right now? They do not reliably answer the fraud question, which is whether the person at the keyboard is the rightful account holder using the expected device, session, and transaction context. That gap is why account takeover can still succeed after a login challenge is passed.
The practical failure mode is familiar. Attackers steal passwords through phishing, reuse, malware, or stuffing, then use OTP relays, adversary-in-the-middle kits, or social engineering to satisfy the second factor in real time. Once the session is established, the attacker can often act like a normal user unless the application adds stronger checks at login, recovery, and especially at high-risk actions.
Passwords and OTPs also operate too early in the flow. They can block casual unauthorised access, but they do not by themselves bind the session to a trusted device or validate whether an action is unusual, high value, or inconsistent with the user’s normal pattern. That is why fraud teams care about more than authentication: they need device signals, step-up controls, and action-layer approval for risky changes.
What account takeover looks like after login succeeds
Account takeover fraud usually turns authentication into a doorway rather than a finish line. If the attacker can log in from a different machine, browser, or network, they may still reset recovery options, add a new payee, change contact details, withdraw funds, or exfiltrate data without ever needing to defeat the original password again.
That is why current guidance in customer identity and fraud prevention increasingly treats customer identity controls as a layered problem: login assurance, recovery assurance, bot resistance, and transaction risk. A credential can tell you who knows a secret; it cannot alone tell you whether the account is under takeover pressure or whether the action is safe.
OTPs are especially weak when they are reused as a universal proof of legitimacy. They are often enough to satisfy legacy flows, but they are not strong evidence of possession when the code can be forwarded, intercepted, or entered by a victim into a live phishing proxy. For that reason, many fraud controls now favor phishing-resistant methods and device-bound claims over code-only confirmation.
Why stronger controls need to move from login to action
The control objective changes once the attacker has a valid session. At that point, the decision is no longer “should this identity be allowed to authenticate?” but “should this specific device, session, and request be allowed to perform this action?” That is why device binding, session risk scoring, and transaction-specific step-up controls matter more than another generic prompt for a one-time code.
In practice, MFA guidance should be read with this distinction in mind, because the same factor that is useful against password replay can still be bypassed by relay, fatigue, or token theft. The stronger pattern is to combine phishing-resistant authentication with device recognition and action-layer verification for account recovery, payout changes, and other irreversible events.
Fraud prevention also benefits from behavioural and device intelligence rather than relying on secrets alone. A familiar password from an unfamiliar environment is not the same as a trusted return visit, and a valid OTP on a risky device should not automatically clear a high-impact transaction. That is the operational reason many teams pair authentication controls with identity fraud prevention signals and bot detection.
Risk and Threat Considerations
Password and OTP failure is not just a usability issue, it creates direct exposure to fraud, account abuse, and downstream customer harm. Once an attacker can reuse a stolen secret or relay an OTP, the remaining risk shifts to session hijacking, recovery abuse, and fraudulent action execution.
Failure mechanism: The attacker satisfies authentication with a stolen password, a relayed OTP, or a compromised session, then uses the authenticated state to change recovery data or perform value-moving actions from a separate device.
Impact: Account takeover can lead to payment diversion, data theft, social engineering of contacts, reputation damage, and expensive recovery work even when the original login factors were “successful.”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Passwords and OTPs are authentication controls for user sign-in. |
| IA-5 — Authenticator Management | The question centers on why secrets and OTPs are insufficient as authenticators. | |
| IA-9 — Service Identification and Authentication | Device-bound and session-bound trust depends on authenticating non-human endpoints and services. | |
| Recommendation — Strengthen sign-in assurance and require stronger authentication for sensitive accounts. Manage authenticator lifecycle, rotation, and protection to reduce compromise and relay risk. Bind authentication to trusted systems and limit reusable credentials across devices. | ||
| OWASP ASVS | V6 — Authentication | ASVS Authentication directly addresses password and OTP weaknesses in sign-in flows. |
| V8 — Authorization | The key failure is that authenticated users may still be allowed to perform harmful actions. | |
| V7 — Session Management | Takeover often succeeds through a valid session rather than a fresh login. | |
| Recommendation — Use stronger authentication requirements for high-risk accounts and flows. Enforce action-level authorization for risky changes, not just at login. Harden sessions so stolen or relayed credentials cannot be reused indefinitely. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account takeover fraud is fundamentally an abuse of account lifecycle and access paths. |
| Recommendation — Review and restrict account access paths that enable takeover and recovery abuse. | ||
Practitioner Guidance
What to prioritise: Treat password plus OTP as a minimum access check, not a fraud control. The first design question should be whether the account can still execute sensitive actions from an untrusted device after login.
What to verify: Confirm that recovery flows, email change, payout change, device enrollment, and session re-authentication all have stronger controls than ordinary sign-in. Those paths are where takeover usually becomes monetisable.
Decision rule: If the attacker can authenticate from a new device and still complete high-risk actions, add device binding or step-up at the action layer before trying to harden the login page further.
Common mistake: Teams often measure success by login failure rates alone. For fraud prevention, the more useful metric is how often suspicious sessions are stopped before recovery changes or irreversible account actions occur.
Practitioner takeaway: The right control target is not “did the user prove a secret,” it is “can this specific session safely perform this specific action.”
Related resources from NHI Mgmt Group
- Why do password-only policies fail to stop account takeover and fraud in citizen services?
- Why do identity checks fail to stop referral and account cycling fraud?
- What breaks when organisations rely on passwords and basic MFA to stop account takeover in identity verification flows?
- Why do single fraud signals fail to catch account takeover in ecommerce?