Bank Logins Are Hardened. Bank Sessions Aren't, Yet
Banks are among the most phishing-targeted and security-mature consumer platforms on the web. We tested the 43 most security-mature consumer banks across the US, UK, Eurozone, Canada, Australia and the Nordics. Zero of them cryptographically bind the live browser session to the device that created it.
These banks already run heavy device intelligence: behavioral biometrics, bot defense, device profiling, mobile app attestation. But scoring a device is not the same as binding the session. The post-login cookie is still a bearer token: whoever holds it is treated as the user. A session stolen by phishing, an infostealer, or an adversary-in-the-middle kit replays on the attacker's device without ever defeating login.
In this whitepaper:
Results of our test of the 43 most security-mature consumer banks: 0/43 cryptographically bind the web session (the strict DBSC-style layer).
Why authentication is not session integrity, and how modern account takeover bypasses the login moment entirely.
The three meanings of "device-bound," and the category error that lets "fingerprinting exists" pass for "the session is bound."
Five ways a valid session ends up on the wrong device: infostealer logs, adversary-in-the-middle phishing, residential proxy replay, anti-detect browsers, and on-device malware.
Where Device Bound Session Credentials (DBSC) fit, the adoption timeline, and what the gap means for banks and the Fortune 1000.
Get the whitepaper
Fill out the form to get the full device-bound web sessions report.
Functional cookies required
This form needs functional cookies to load. Update your cookie preferences to continue.
Open the form in a new tabThe form didn't load
Your browser may be blocking the embedded form. Try refreshing the page.
Open the form in a new tabIn one plain question
Is each user's auth token bound to the device, or can it move to another browser?
An auth token is the key a browser stores in a cookie or local storage once a user clears the password and 2FA. It's a bearer token: whoever holds it is treated as that user, on any device. Copy it into another browser and that browser is them. For the 43 banks we tested, nothing in the web session stops it.
The core issue
Banks score the web device. They generally do not cryptographically bind the live web session. The login moment is hardened; the session that follows is not.
The bank sweep, in four numbers
The strongest cohort still leaves the browser session as a bearer cookie.
What the banks already do well
Login & transaction
MatureBehavioral biometrics, bot defense, device profiling, step-up auth, and passkeys in some markets.
Mobile channel
Bound~98% bind the app credential to Secure Enclave / Keystore, often with app attestation on top.
Browser session
Open gapThe post-login web cookie is still a bearer token, accepted without proof of the originating device.
The channel separation is the crux. "Banks bind devices" can be true for mobile and false for browser sessions at the same time.
Five ways a valid session ends up on the wrong device
Infostealer logs
Malware harvests browser cookies from the victim device.
Adversary-in-the-middle phishing
The kit proxies MFA / passkey flows and steals the resulting session.
Residential proxy replay
The cookie is presented from a plausible network location.
Anti-detect browsers
Fingerprints are tuned to avoid an obvious mismatch.
RAT / on-device malware
The attacker operates from the legitimate device.
The attacker economy has moved to stolen and relayed cookies. The defense has not moved with it.
Get cross-browser DBSC with cside
DBSC binds the browser session to the device, but today only in Chrome. cside extends device-bound session protection to every browser as first-party JavaScript: detect stolen-cookie replay, evidence the real session, and shut down account takeover that survives the login. No DNS or traffic-path changes.