What happens when customers use cardless ATM access on a lost or stolen phone?

What cardless ATM access changes when the phone is lost or stolen

Cardless ATM access shifts the trust point from a plastic card to the mobile device, the banking app, and the approval workflow around them. That means the main question is not whether the phone is physically present, but whether the app session, device lock, and withdrawal authorisation still hold under loss conditions. If those controls are weak, a stolen handset can become a path to account misuse; if they are well designed, the phone loss should be an inconvenience rather than a cash-out event.

For customers, this matters because cardless withdrawal usually depends on more than one factor, such as a device-bound app, a PIN, biometrics, a one-time approval, or a short-lived code. The practical security outcome depends on whether the bank can distinguish the legitimate customer from someone holding the handset. Banks also need a reliable way to revoke or invalidate app access quickly when the phone disappears. In practice, many teams discover the real weakness only after a lost device case forces them to test how fast revocation, step-up verification, and fraud monitoring actually work.

How the withdrawal flow behaves when the handset is no longer in the owner’s hands

Cardless ATM access typically works by combining the customer’s mobile app with an ATM-side check, such as a withdrawal code, QR-based approval, app push confirmation, or device-linked authentication. A stolen phone does not automatically grant withdrawal rights, but it can help an attacker if the app remains logged in, the device itself is unlocked, or the approval path is too weak. The important distinction is between possession of the handset and possession of an authenticated, still-valid session.

• If the banking app requires fresh authentication for each cash withdrawal, the thief may still be blocked by biometrics, a PIN, or transaction approval.
• If the app keeps an active session and the device lock is weak, the attacker may be able to open the app and attempt a withdrawal or approval replay.
• If the bank supports remote revocation, the customer or bank can invalidate the device before the next ATM use.
• If the ATM flow relies on a short-lived token or code, that token should expire quickly enough that theft of the phone alone is not sufficient.

Good design also separates device access from transaction approval. A device can be trusted enough to display the banking app while still requiring step-up verification before cash is dispensed. That separation limits the damage from a lost phone because the attacker must defeat more than one control path, not just unlock the handset.

The guidance becomes less reliable when banks treat the phone as a single proof of identity. Any design that allows a long-lived session, weak fallback authentication, or slow revocation increases the chance that a stolen phone can be used before the loss is reported and the credentials are disabled. For the customer, the key issue is not the loss itself but whether the account remains bound to the rightful user after the device is gone.

When the usual answer breaks down

Tighter mobile convenience often increases reliance on the phone as a trust anchor, so organisations have to balance faster withdrawals against stronger session and revocation controls.

Not every cardless ATM implementation behaves the same way. Some banks require an in-app approval for every withdrawal, while others allow a pre-authorised code that remains valid for a short window. The latter can work safely, but only if expiry is short and the bank can cancel the code immediately after the phone is reported lost. Where there is no immediate revocation path, the risk window is defined by how long the credential or approval remains usable.

There is also a governance trade-off between convenience and recovery speed. Strong device binding reduces opportunistic abuse, but it also means customers need a clear lost-device process that works even if they no longer have access to the app. Where identity checks fall back to helpdesk workflows, the bank must avoid making account recovery easier than fraud prevention. This is especially important when the customer uses the same phone for both notification and approval, because losing the device can also break the very channel needed to stop misuse. For broader mobile-access governance, the relevant control problem is the same one highlighted by OWASP Non-Human Identity Top 10: long-lived access paths without timely revocation create avoidable exposure, even when the original authentication was sound.

Where this guidance breaks down is when the bank has no meaningful step-up verification, no remote session kill switch, or a legacy ATM flow that treats the device as proof enough to dispense cash.

Risk and Threat Considerations

The material risk is unauthorised cash withdrawal after device loss, especially when the banking app retains an active session or supports a reusable approval token. A stolen phone does not need to reveal the customer’s full banking credentials if the app, session state, or fallback path is already trusted too much.

Failure mechanism: The attacker exploits the gap between possession of the handset and revocation of its banking authority. That can happen through an unlocked device, weak app re-authentication, a long-lived token, or delayed disablement of the mobile session.

Impact: Cash can be withdrawn before the customer reports the loss or before the institution invalidates the device, creating direct financial loss and a recovery burden that depends on fraud monitoring, dispute handling, and support responsiveness.

Practitioner Guidance

What to verify: The critical check is whether cardless withdrawal requires fresh approval at the time of cash dispense, not just prior device enrolment. If the phone loss leaves any reusable approval path in place, treat that as a high-risk design choice rather than a convenience feature.

What good looks like: A lost phone should trigger rapid session invalidation, short token lifetimes, and a fallback path that lets the customer stop device-based access without reusing the compromised handset. The control is working when the bank can show that a stolen device cannot complete a withdrawal without a new, independent verification step.

Common mistake: Teams often assume the device lock is enough, but mobile wallet and banking risk usually depends on the weakest link across app session handling, recovery flows, and cancellation speed. A strong screen lock does not compensate for a weak transaction approval model.

Practitioner takeaway: Treat cardless ATM access as a revocable authorisation problem, not a phone-loss problem alone; the real test is whether the bank can stop cash-out fast enough after the device disappears.

Related resources from NHI Mgmt Group

• What happens when adaptive access rules block legitimate customers during sign-in?
• How should security teams use NIST CSF 2.0 to turn privileged access risks into a practical control plan?
• What happens when service accounts are left without ownership or access reviews?
• What happens when a TOTP secret is shared without proper access controls and audit trails?