Those controls break because they assume a human can reliably detect deception and protect a secret. AI makes phishing, relay attacks, and synthetic impersonation cheap enough that the attacker can capture or replay the factor at scale. In practice, the control no longer proves the user is present, only that a secret was exposed.
Why Passwords, OTPs, and Security Questions Stop Proving Presence
When fraud becomes automated, the problem is no longer just “can the user remember a secret?” It becomes “can an attacker obtain, relay, or synthesize the proof faster than the legitimate user can resist?” Passwords, OTPs, and security questions all rely on information that can be captured, guessed, replayed, or socially engineered, so they degrade from identity proof into reusable account-access material.
That failure is strongest when the factor is designed around knowledge or shared secret recovery. Knowledge factors can still reduce casual abuse, but they do not reliably distinguish the real user from a convincing impersonation flow, especially when the attacker can automate scale, timing, and message generation.
The practical implication is that these controls should be treated as legacy compatibility layers, not as strong fraud resistance. Phishing-resistant methods change the equation because they bind authentication to a stronger cryptographic and device-bound relationship instead of depending on secrecy alone. A MFA Guide is useful here because it separates weak second factors from phishing-resistant options and shows where attackers commonly bypass traditional MFA.
Why AI Fraud Makes Relay, Phishing, and Synthetic Impersonation More Effective
AI lowers the cost of crafting believable lures, adapting to victim responses, and iterating through attempts until one succeeds. That matters because the control failure is not just theft of a secret, but the attacker’s ability to turn a one-time human interaction into a scalable access path through relay attacks, consent tricks, voice cloning, or fabricated support scenarios.
Security questions are especially fragile because the answer is often discoverable, inferable, or harvested from public data and prior breaches. OTPs are better than static passwords, but they still depend on timely delivery and human handling of the challenge, which means adversary-in-the-middle setups, session hijacking, or SIM swap style compromise can still defeat the flow.
In other words, AI does not need to “break” cryptography to break the user journey. It only needs to make the social and operational path to the factor cheap enough that the defender loses the advantage of friction. For that reason, modern identity programs increasingly compare these methods against phishing-resistant authentication guidance such as NIST SP 800-63 Digital Identity Guidelines rather than relying on legacy knowledge factors alone.
What Should Replace Weak Factors in a Fraud-Heavy Environment?
The right response is to shift from secret-based proof to stronger, context-aware assurance. That usually means phishing-resistant authenticators, tighter session controls, step-up checks for high-risk actions, and fraud signals that examine device, behavior, and transaction context instead of assuming possession of a code proves legitimacy.
For most organizations, the key design question is not whether OTP exists, but whether the login and recovery flows can survive modern impersonation. If the answer is no, then password reset, help desk verification, account recovery, and MFA enrollment become the real attack surface, not just the primary sign-in page.
Identity teams should also think in terms of lifecycle, because a weak factor often persists through recovery, enrollment, and fallback processes long after the primary login has been hardened. A useful operational reference is the Identity Fraud Prevention Guide, which ties fraudulent access patterns to account takeover and the broader customer lifecycle, and the NHI Lifecycle Management Guide, which is valuable for understanding how lifecycle controls reduce stale, reusable access paths across identities and credentials.
Risk and Threat Considerations
Weak factors create a fraud-friendly control boundary because an attacker only needs to win one human interaction, one recovery flow, or one replay window to gain durable access. Once that happens, the fraud is no longer limited to login compromise, it can extend to account takeover, payment abuse, help desk impersonation, and downstream trust erosion.
Failure mechanism: AI improves pretext quality, speeds up phishing iteration, and helps attackers relay or replay captured secrets before the legitimate user or defender can react.
Impact: The organization ends up trusting a secret that was exposed, not a user who is demonstrably present, which increases takeover rate and weakens recovery controls across the account lifecycle.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63, OWASP ASVS 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 | Phishing-resistant assurance and authenticator strength directly address weak password and OTP proofing. |
| Recommendation — Prefer phishing-resistant authenticators and bind sign-in to stronger assurance levels. | ||
| OWASP ASVS | V6 — Authentication | The question concerns whether passwords and OTPs still establish reliable authentication under fraud. |
| Recommendation — Treat weak factors as insufficient and require stronger authentication assurance. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | AI-assisted fraud exposes weak, replayable authentication flows and fallback paths. |
| Recommendation — Replace replayable authentication flows with phishing-resistant, device-bound methods. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Authentication assurance for users is central when secrets no longer prove presence. |
| IA-5 — Authenticator Management | Passwords, OTP seeds, and recovery secrets are lifecycle-managed authenticators. | |
| Recommendation — Require stronger user authentication mechanisms for sensitive access. Rotate, protect, and retire authenticators that can be captured or replayed. | ||
| MITRE ATT&CK | T1566 — Phishing | AI fraud commonly exploits phishing to capture credentials and challenge responses. |
| T1110 — Brute Force | Automated fraud raises the scale of credential guessing and validation attempts. | |
| Recommendation — Detect and disrupt phishing campaigns that collect reusable login secrets. Throttle and detect repeated authentication attempts and credential stuffing. | ||
Practitioner Guidance
What to prioritise: Put the highest-risk accounts and recovery paths first, especially privileged users, support desks, payment flows, and any process where a stolen factor can trigger reset or re-enrollment. Those are the places where AI-assisted fraud converts fastest into real loss.
What to verify: Check whether the current factor can be phished, relayed, or socially engineered without a device-bound or cryptographic binding to the session. If it can, then it is an exposure-reduction control, not a strong proof of presence.
Practitioner takeaway: In an AI-fraud environment, the security test is no longer “did the user know the secret?”, but “can the authentication method survive a convincing, automated impersonation attempt without handing the attacker a reusable login path?”
Related resources from NHI Mgmt Group
- What breaks when support verification still depends on security questions?
- What breaks when security testing still depends on periodic scans in an AI-driven delivery pipeline?
- What breaks when security governance still depends on manual review queues for cloud AI services?
- What breaks when identity still depends on passwords and help-desk verification?