Because both can be intercepted, reused, or coerced. A password plus OTP model improves security, but it still leaves a reusable secret in play and depends on channels that attackers routinely target through phishing, SIM swapping, replay, or MFA fatigue tactics.
Why Passwords and OTPs Still Leave a Phishing Surface
Passwords and OTPs are stronger together than either factor alone, but they still depend on secrets the user must present or approve. That means the defence can fail at the point of entry, during enrollment, or at the moment the attacker relays or reuses the authentication flow. The residual risk is not theoretical, it is built into the mechanism.
A password can be phished, replayed, guessed, reused, or stolen from a synced browser, and an OTP can be captured in real time through adversary-in-the-middle phishing, SMS interception, or push-based social engineering. Where the second factor is delivered over a vulnerable channel, the attacker does not need to break encryption, only to position themselves between the user and the service.
That is why phishing-resistant methods, especially passkeys and security keys, are different in kind rather than just degree. NHIMG’s MFA Guide and the Passwordless and Passkeys Guide both show why password-plus-OTP remains exploitable even when it improves baseline protection.
Where OTP Risk Becomes a Real-World Failure Mode
The weak point is often not the login page itself but the surrounding identity flow. Help desk resets, account recovery, legacy fallback methods, and device enrollment paths can all become alternate ways to satisfy the second factor or to reset the first. If those paths are easier to social-engineer than the primary login, the MFA programme inherits their weakness.
OTP methods also vary materially in how they fail. SMS OTP is exposed to SIM swap and number-port fraud. Authenticator app OTP is better, but still relayable through live phishing kits. Push approvals can be abused through fatigue or prompt bombing. Even when the secret expires quickly, it can still be harvested and used within its valid window.
The practical lesson is that MFA strength is bounded by the least resistant factor and by the weakest recovery path. NHIMG’s Workforce Identity Security Guide and IAM and Identity Provider Buyer's Guide both frame MFA as part of a wider identity system, not a standalone control.
Why “MFA Enabled” Is Not the Same as “Phishing Resistant”
Many programmes treat any second factor as if it meaningfully neutralises credential theft. In practice, password plus OTP often reduces the blast radius but does not remove account takeover risk, because the attacker can still steal both factors in sequence or in one live phishing session. That is especially true where users must type codes manually or approve a prompt without cryptographic binding to the origin.
Programmes also overestimate the value of a second factor when attackers already hold session material or valid credentials. A stolen session token, compromised recovery channel, or legacy account can bypass the normal challenge flow entirely. NHIMG’s CitrixBleed exploitation 2023 and Microsoft Midnight Blizzard breach illustrate how attackers move around MFA instead of fighting it head-on.
The right conclusion is not to abandon MFA, but to distinguish factors that merely add a hurdle from factors that are phishing-resistant by design. NIST SP 800-63 Digital Identity Guidelines gives the clearest external baseline for that distinction, especially around authenticator assurance and phishing-resistant authentication. NIST SP 800-63 Digital Identity Guidelines remains the most useful reference for that control choice.
Risk and Threat Considerations
Password and OTP combinations create a residual attack surface because they still rely on reusable or relayable secrets. Attackers target the password, then target the channel or human decision point that delivers the OTP, which makes phishing, SIM swapping, OTP replay, and MFA fatigue effective against otherwise mature programmes.
Failure mechanism: The attacker captures the first factor, intercepts or coerces the second, or steals a session token after authentication, then reuses that access before detection or revocation occurs.
Impact: Account takeover, privilege abuse, lateral movement, and downstream data exposure can follow even though MFA was technically enabled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines phishing-resistant authenticators and assurance levels for MFA choices. |
| Recommendation — Prefer phishing-resistant authenticators for sensitive access and recovery flows. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Covers authenticating workforce users in MFA programmes. |
| IA-5 — Authenticator Management | Applies to lifecycle and protection of passwords, OTP secrets and tokens. | |
| Recommendation — Enforce strong user authentication with resistant factors for privileged access. Manage authenticator issuance, storage, rotation and revocation tightly. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Password and OTP exposure through phishing or interception is a secret-leakage problem. |
| NHI-07 — Long-Lived Secrets | Passwords are durable secrets that remain exploitable when stolen or reused. | |
| NHI-04 — Insecure Authentication | OTP and password flows remain vulnerable when they can be replayed or relayed. | |
| Recommendation — Reduce leakage by removing reusable secrets from authentication paths. Shorten secret lifetime and replace reusable secrets where possible. Adopt authentication methods that resist relay, replay and phishing. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Token reuse, replay and weak factor handling are classic authentication failures. |
| API8 — Security Misconfiguration | Fallback and reset path weaknesses often reflect misconfiguration in access controls. | |
| Recommendation — Harden authentication flows against replay, interception and token theft. Disable weak fallback factors and legacy auth paths. | ||
Practitioner Guidance
What to prioritise: Treat password plus OTP as an intermediate control, not the end state. Prioritise phishing-resistant authentication for any user population that can reach sensitive systems, administrative functions, or high-value transactions.
What to verify: Check whether recovery, reset, and enrolment paths are stronger than or weaker than the primary sign-in flow. If help desk or SIM-based recovery can be socially engineered, the programme still has a bypass path.
Practitioner takeaway: An MFA programme is only as strong as its weakest factor and its weakest fallback, so the real question is not whether MFA exists, but whether an attacker can still obtain a usable login path without possessing the legitimate device or cryptographic key.
Related resources from NHI Mgmt Group
- Why do passwords and conventional MFA still create phishing risk?
- Why do passwords and OTPs still create risk in regulated environments?
- Why do passwords and OTPs create persistent risk in enterprise identity programmes?
- Why do passwords and phishable MFA factors still create unacceptable risk for enterprise access?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org