Reusable secrets and relayable factors break because they can be captured, replayed or coerced in real time. AI-generated phishing makes the user the attack surface, so a control that depends on human judgment at login can no longer provide dependable assurance for sensitive access.
Why passwords and OTPs stop being dependable under AI phishing pressure
Passwords and OTPs assume the attacker has to steal a static secret or convince a user to reveal a one-time code after the fact. ai phishing changes that assumption by making lures, timing and conversation flow convincing enough to capture reusable secrets and relayable factors in the same session they are entered. The weak point is no longer just the credential, it is the human decision at the moment of login.
That matters because many organisations still treat OTPs as a meaningful step up from passwords even when the attacker can run a real-time relay or session interception workflow. Once the factor can be replayed, proxied or induced on demand, the login event no longer proves the authentic user is in control.
For teams comparing controls, phishing-resistant methods are the important break point, not just “more factors.” Guidance around stronger authentication and relay-resistant methods is most useful when you are deciding whether a login signal should be trusted for sensitive access at all, rather than whether it merely satisfies a policy requirement.
What this means for access decisions and assurance
When the login path is exposed to AI-generated social engineering, the organisation should stop treating passwords and OTPs as dependable assurance for privileged or high-impact actions. Their value drops sharply when the attacker can initiate the interaction, sustain the deception and exploit the user’s trust faster than the defender can intervene.
In practice, that shifts the question from “did the user enter the right secret?” to “does this authentication event resist real-time phishing, relay and coercion?” If the answer is no, the control may still be usable for low-risk access, but it is no longer a strong basis for step-up approval, recovery flows or access to sensitive systems.
That is why password plus OTP combinations often look compliant while still failing in the scenarios that matter most. The control can be technically correct and operationally weak at the same time, especially when the adversary uses automated conversation, cloned branding and immediate token relay.
Where agencies usually misjudge the failure mode
Agencies tend to underestimate how little effort is needed to turn login into a live phishing channel. A convincing prompt, a fake help-desk escalation or a “verify your account” flow can be enough to pull a password and then an OTP before the session expires.
MFA Guide is useful here because it distinguishes between factors that merely add friction and factors that actually resist phishing, relay and token theft. The operational mistake is assuming all MFA meaningfully changes the threat model. In reality, OTPs remain relayable, while phishing-resistant methods are designed to bind the authentication to the origin, device or ceremony.
Agencies also misread “user awareness” as a control boundary. Under AI phishing pressure, the attacker is not depending on clumsy spam. They are exploiting the fact that a legitimate person can be manipulated in real time, during a workflow that looks normal enough to satisfy habitual behaviour.
Risk and Threat Considerations
AI phishing compresses the time between initial contact and credential use, which makes reusable secrets and relayable factors especially fragile. The practical risk is account takeover, session hijack and unauthorized access to sensitive workflows even when an OTP was used.
Failure mechanism: The attacker persuades the user to reveal a password or approve an OTP, then relays or reuses that factor immediately before it expires, often while the victim believes they are completing a legitimate verification step.
Impact: Sensitive access can be granted on the strength of an event that looks authenticated but is not trustworthy, which increases the chance of data exposure, privileged misuse and downstream compromise.
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, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Passwords and OTPs fail when secrets are captured or relayed during phishing. |
| NHI-04 — Insecure Authentication | The question is about authentication methods that remain vulnerable under AI phishing. | |
| NHI-07 — Long-Lived Secrets | Reusable passwords are long-lived secrets that AI phishing can harvest and reuse. | |
| Recommendation — Reduce secret exposure paths and replace replayable login factors with phishing-resistant authentication. Adopt phishing-resistant authentication for sensitive access and retire relayable factors. Shorten secret lifetime and remove reusable credentials from high-impact access paths. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Authenticator assurance and phishing-resistant methods directly address whether login can be trusted. |
| Recommendation — Use phishing-resistant authenticators for sensitive access and step-up decisions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Agency users accessing sensitive systems need stronger authentication than passwords and OTPs provide. |
| IA-5 — Authenticator Management | Password and OTP weaknesses are authenticator lifecycle issues, including issuance and reuse. | |
| IA-9 — Identification and Authentication (Service and Service Accounts) | AI phishing often leads to stolen credentials used against services and machine-access paths too. | |
| Recommendation — Strengthen organizational-user authentication for accounts that protect sensitive systems. Manage authenticators to limit reuse, exposure and relayable login factors. Apply stronger service authentication where stolen secrets could enable automated abuse. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero trust emphasizes never trusting a login event solely because a secret was entered. |
| Recommendation — Continuously verify access and treat authentication as one signal, not proof of trust. | ||
| MITRE ATT&CK | T1556 — Modify Authentication Process | AI phishing commonly abuses the authentication step by redirecting or relaying login flows. |
| Recommendation — Map phishing-and-relay activity to authentication abuse and monitor for hijacked login workflows. | ||
Practitioner Guidance
What to prioritise: Treat phishing-resistance as the decision point for any account that can reach sensitive data, admin functions or recovery paths. If a factor can be relayed in real time, do not let it serve as the final trust signal for high-impact access.
What to verify: Confirm whether the organisation can distinguish ordinary MFA from phishing-resistant authentication in policy, telemetry and exception handling. A control only matters if the login method can be tied to a resistant authenticator rather than a user-entered code.
Common mistake: Teams often keep passwords and OTPs in place while adding more prompts, more approvals or more user training. That increases friction, but it does not remove the core problem that the attacker is operating through the user’s own interaction channel.
Practitioner takeaway: When AI phishing can reach the login ceremony, the control objective is not “add another factor,” it is “remove the attacker’s ability to replay trust in real time.”
Related resources from NHI Mgmt Group
- What breaks when organisations keep relying on traditional incident response for modern cloud and AI threats?
- What breaks when organizations keep relying on passwords as they scale fast?
- What breaks when organisations let users keep relying on passwords for federated cloud access?
- What breaks in operational technology when organisations keep relying on passwords and manually managed keys?