How should digital banking teams reduce the risk of malware stealing customer credentials from connected devices?

Why malware on a customer device changes the banking risk equation

When the endpoint is infected, the bank is no longer defending only the browser session. It is defending the customer’s credentials, cookies, and any trust the session inherits from that device. That is why a layered response matters, starting with device protection and continuing through stronger authentication and session controls. The OWASP Non-Human Identity Top 10 is not the right lens here, but the same credential abuse problem shows up clearly in banking session theft.

Malware can capture passwords as they are typed, steal browser-stored data, hijack sessions, or trigger unauthorized transactions after login. In practice, the risk is not just first-factor compromise. It is the attacker’s ability to reuse whatever the device exposes, which is why banks should treat connected-device compromise as a session and credential problem, not only an endpoint hygiene problem. CIS Controls v8 supports this layered view through account management, malware defense, and access control.

For digital banking teams, the key distinction is whether the control reduces theft, reduces reuse, or limits blast radius after theft. Endpoint protection and runtime application self-protection help stop or slow capture in the device path. Strong authentication and transaction confirmation help ensure that even if a credential is stolen, the attacker still cannot easily move from login to meaningful account abuse. That is also where RFC 6749: The OAuth 2.0 Authorization Framework becomes relevant as a design reference for safer delegated access patterns, even though consumer banking flows are not a pure OAuth problem.

Where theft actually happens: password capture, session replay, and transaction abuse

Malware rarely needs to defeat the whole bank stack. It only needs one weak point in the customer journey. Common failure modes include credential keylogging, clipboard interception, man-in-the-browser manipulation, token theft, and invisible transaction redirection after the user has authenticated. If the bank relies on a password alone, the attacker’s job is straightforward. If the bank also binds the session to device signals, challenge steps, or transaction context, the attacker has to defeat more than the stolen secret.

Stolen credentials often arrive with enough surrounding context to be useful immediately. Saved sessions, autofill data, and browser tokens can reduce the attacker’s effort from account takeover to simple session reuse. That is why the strongest controls are the ones that make a stolen secret less reusable on a different device or in a different session. The Token and Session Security Guide is useful here because it frames the operational difference between credential theft and session misuse, which is exactly the gap malware tries to exploit.

Another practical issue is that banking malware often targets the transaction flow rather than the login page. A customer may authenticate successfully and still have payment details, payee data, or confirmation steps altered before submission. In that scenario, behavioral authentication, step-up verification, and out-of-band confirmation matter because they increase friction only at moments where the transaction becomes high risk. The CIS Controls v8 also aligns with this by emphasizing secure access and resilient protection across endpoints and accounts.

What banking teams should optimise for in controls and customer experience

The best control mix is not the one that simply adds more prompts. It is the one that makes theft less valuable while keeping legitimate banking usable. Strong authentication should be resistant to replay and device theft, but it should also be tuned so that routine actions stay low-friction and only high-risk actions trigger stronger proof. If a bank adds too many interruptions, customers will bypass or abandon them, which creates a different kind of exposure.

Teams should also prioritise controls that reduce the lifetime of any stolen secret. Short-lived tokens, credential rotation where practical, and device-bound or transaction-bound mechanisms all reduce the window in which malware can cash out stolen access. That is the same logic captured in API Key Management Guide and Secrets Management Guide: reduce secret lifespan, scope, and replay value. The banking analogue is not literal API keys in the customer app, but the same principle of limiting secret usefulness applies.

For connected devices specifically, the user device is part of the trust boundary, even when the bank does not control it. That means customer education, browser hardening guidance, fraud analytics, and device-aware risk scoring all have a role. The practical question is whether the bank can detect when a login comes from a device that is acting unlike the customer’s normal environment, and whether it can step up verification before money moves. Device and IoT Identity Guide is a useful adjacent reference because it reinforces the value of device trust and lifecycle thinking.

Risk and Threat Considerations

Malware on customer devices creates a direct path from credential theft to fraud, because the attacker can exploit whatever the browser or banking app has already trusted. The practical risk is strongest when the bank treats login as the main control and gives transaction approval the same trust level as ordinary browsing.

Failure mechanism: Malware captures credentials, session material, or transaction details, then reuses them or alters them before the user notices.

Impact: Account takeover, unauthorized payments, session hijack, and higher fraud losses can follow even when the original password was never shared with the attacker.

Practitioner Guidance

What to prioritise: Put your first effort into controls that break replay value, not just controls that detect malware after the fact. If a stolen secret can still authorize a payment from a new device, the bank has not reduced the attack value enough.

What to verify: Confirm that step-up authentication is triggered by transaction risk, device anomaly, or session change, not only by login success or failure. Also verify that any session token or remembered device state expires fast enough to be operationally useful.

Common mistake: Treating endpoint protection as a complete answer. Endpoint tooling helps, but banking teams still need controls that limit what an attacker can do after the device is compromised.

Practitioner takeaway: The safest design assumes customer devices can be infected and focuses on making stolen credentials, tokens, and sessions difficult to reuse for meaningful account abuse.

Related resources from NHI Mgmt Group

• How should security teams reduce identity theft risk when customer or employee credentials are used to open accounts or move money?
• How should security teams reduce IoT risk in environments where IT, OT, and connected devices overlap?
• How should OT teams reduce the risk created by insecure digital products connected to critical operations?
• How should security teams reduce the risk of malicious packages stealing cloud credentials and SSH keys during installation?