What happens when a bank tries to use step-up authentication against account takeover without strong liveness checks?

Why Step-Up Authentication Fails When Liveness Is Weak

Step-up authentication only helps if the extra check actually distinguishes a live user from an impersonation artifact. If the bank accepts a static face match, a replayed video, or a relayed session as “good enough,” the attacker can satisfy the challenge after already taking over the account. The control appears to work, but it does not materially raise the fraud bar.

The core issue is that account takeover is often followed by an interactive prompt designed to confirm intent, possession, or presence. Without strong liveness, that prompt becomes just another surface an attacker can automate, relay, or spoof. Stronger phishing-resistant authentication guidance in NIST SP 800-63 Digital Identity Guidelines and practical workforce patterns in Workforce Identity Security Guide both point to the same operational truth: step-up must raise assurance, not just add friction.

For banks, that means the authentication decision is not the only thing that matters. The bank also has to consider whether the response is being generated by a real person at the point of risk, whether the channel can be proxied, and whether the step-up can be replayed or reused. If those properties are not enforced, the attacker keeps the session and the bank keeps the illusion of control.

Where the Attack Breaks Through

In practice, the weakness shows up when the bank uses a low-assurance factor to confirm a high-risk action, such as a password reset, device enrollment, or payment approval. A photo, screen recording, deepfake video, or injected browser session can satisfy a weak check even though the attacker is remote and the real customer is absent. That is why the difference between authentication and proof of presence matters so much in fraud-sensitive flows.

Attackers also benefit from the fact that the step-up often happens after they already possess a valid session, token, or reset path. Once the initial takeover is complete, the second factor is no longer defending the perimeter, it is defending a live transaction. If the bank’s control can be relayed or replayed, the attacker converts the step-up into a speed bump. Incidents such as GitLocker GitHub extortion campaign and Uber Breach show the broader pattern: once identity assurance is bypassed, the attacker can move from access to impact quickly.

For banks, the practical lesson is that step-up authentication should be evaluated as an anti-abuse control, not just an authentication control. If the design does not resist replay, relay, or proxying, it may still be useful for nuisance reduction, but it is not dependable against a determined account-takeover campaign.

What Strong Liveness Changes for Fraud Controls

Strong liveness changes the decision quality of the step-up itself. It helps the bank verify that the challenge is being answered by a present human rather than an image, recording, bot-assisted relay, or compromised browser session. That materially improves the bank’s confidence that the person approving a risky action is the account holder or at least physically present.

That said, liveness is not a standalone guarantee. It works best when paired with risk-based step-up logic, device binding, anomaly detection, and recovery flows that are harder to socially engineer than the primary login. A bank that treats liveness as a cosmetic add-on often still loses to session theft, help desk abuse, or token replay. The more sensitive the action, the more the bank should prefer phishing-resistant authentication paths and limit how much trust is placed in a single biometric or camera-based check.

In financial environments, this aligns with broader control expectations in PCI DSS v4.0, EU Digital Operational Resilience Act (DORA), and CIS Controls v8, all of which emphasize stronger access control, account management, and resilience against misuse of legitimate access paths.

Risk and Threat Considerations

Weak liveness creates a false sense of assurance. The bank may believe it has stopped account takeover while the attacker is simply passing a low-assurance check with a replayed or injected interaction, then completing fraud from inside an apparently authenticated session.

Failure mechanism: The step-up control accepts a signal that can be imitated, replayed, or proxied, so the attacker satisfies the challenge without proving real-time human presence.

Impact: The bank approves the very action the control was meant to block, which can lead to unauthorized transfers, beneficiary changes, token theft, or durable account control.

Practitioner Guidance

What to verify: Treat every step-up method as a fraud-control decision, not just an MFA variant. Verify whether it resists replay, relay, screen injection, and prerecorded media for the specific transaction being protected.

Decision rule: If the step-up can be completed without strong proof of live presence, do not rely on it for high-value account changes or recovery actions. Move those flows to stronger authentication or add out-of-band verification with tighter device and risk checks.

Practitioner takeaway: The right question is not whether step-up exists, but whether it meaningfully increases assurance at the exact moment an attacker would try to convert takeover into fraud.

Related resources from NHI Mgmt Group

• What happens when account takeover is attempted without enough step-up authentication?
• What happens when help desks handle sensitive account changes without step-up authentication?
• When should organisations use step-up authentication for shared-account risk?
• How should security teams implement step-up authentication in a Next.js app without relying only on client-side checks?