What breaks when MFA still depends on human approval and one-time prompts?

Human-dependent MFA breaks when attackers use fatigue attacks, deepfake social engineering, or browser-in-the-browser tricks to manipulate the user into approving access. The control may appear to work while giving a false sense of security. Once the attacker gets a session, post-authentication hijacking can bypass the original challenge entirely.

Why This Matters for Security Teams

When MFA still depends on a human clicking approve, entering a code, or validating a push, the control is only as strong as the user’s ability to detect deception in real time. That is a weak assumption against fatigue attacks, browser-in-the-browser phishing, and deepfake voice or chat prompts that turn “verification” into a social engineering target. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows how quickly identity controls fail once an attacker can pivot beyond the initial prompt.

The deeper issue is that human-dependent MFA creates a false boundary. It may confirm a person responded to a challenge, but it does not prove the request is legitimate, the device is trustworthy, or the session will remain safe after approval. That gap matters even more in environments aligned to the NIST Cybersecurity Framework 2.0, where identity assurance must support continuous risk reduction rather than one-time access checks. In practice, many security teams discover this only after a stolen session token has already been used to move laterally and bypass the original MFA event.

How It Works in Practice

Human-dependent MFA breaks because it verifies a moment, not a threat model. An attacker can coerce the user into approving a push, steal the one-time code through phishing, or replay a captured session after the challenge has completed. Once the session cookie or token is issued, post-authentication hijacking often becomes the real problem, not the original login prompt. The right response is to reduce reliance on human approval and shift toward device-bound, context-aware, and continuous verification.

Current guidance suggests pairing MFA with phishing-resistant methods such as FIDO2/WebAuthn, conditional access, and session re-evaluation. For sensitive workflows, treat approval as only one signal among many, not the control itself. That means checking device posture, geolocation anomalies, impossible travel, token age, and request context before granting or continuing access. Where possible, enforce step-up authentication only for high-risk actions rather than every login.

• Use phishing-resistant factors instead of codes or push-only approvals.
• Bind sessions to trusted devices and revoke tokens on risk change.
• Log MFA fatigue patterns, repeated prompts, and impossible approval timing.
• Limit the blast radius of any approved session with least privilege.

For identity-heavy environments, this also intersects with NHI governance because stolen human sessions are often used to reach service accounts, API keys, and automation paths. The Microsoft Midnight Blizzard breach is a useful reminder that session compromise and identity sprawl rarely stay contained to one account. These controls tend to break down in remote-access and helpdesk-heavy environments because attackers can time social engineering to match normal approval behavior.

Common Variations and Edge Cases

Tighter MFA often increases friction, so organisations have to balance stronger resistance to phishing against user workload, support tickets, and recovery complexity. That tradeoff is real, especially where legacy applications only support OTPs or approval prompts.

Best practice is evolving, and there is no universal standard for how much step-up friction is acceptable across all applications. High-risk admin actions, payroll changes, and production access should use stronger controls than low-risk sign-ins. In contrast, customer-facing or high-volume workflows may need a staged migration path that starts with reducing push fatigue, then adds phishing-resistant authentication, then retires legacy factors.

Edge cases include break-glass access, service desks that reset MFA, and shared administrator workflows. Those cases need compensating controls such as short-lived access, independent approval channels, and strong session revocation. If the organisation cannot detect token theft or invalidate active sessions quickly, even perfect MFA enrollment will not prevent post-authentication abuse.

For teams building identity programmes from the ground up, align policy design to continuous assurance rather than one-time approval using NIST Cybersecurity Framework 2.0 and the NHI lifecycle guidance in the Ultimate Guide to NHIs. The practical lesson is simple: if the attacker can trick the approver, the factor is no longer a factor.

Related resources from NHI Mgmt Group

• What breaks when SOC response still depends on human approval at every step?
• How should teams decide when one-time codes are still acceptable for MFA?
• Should organisations still use one-time passwords for MFA?
• What breaks when MCP approval is treated as a one-time consent step?