Device Binding vs. Device Intelligence

Account Takeover & Session Security: Attack Vectors and Risks

Account Takeover (ATO) has evolved in lockstep with the defenses built to stop it. As authentication has hardened, attackers have shifted away from the login gate, where they now meet stiff resistance, toward a less-guarded area of the perimeter: the authenticated session. There, techniques ranging from cookie replay to full Identity Impersonation allow attackers to bypass any MFA or security check, landing straight into the authenticated session. This is due to a structural security gap that most web applications have.

Every authenticated session on a modern web platform ultimately rests on a bearer credential: a session cookie or token that authorizes whoever presents it. The server has no way to tell the legitimate user apart from anyone else holding a copy.

For any application handling sensitive data or privileged operations, the consequences of that gap are severe. A single stolen session grants an attacker everything the account can do, acting as the user: from accessing confidential data to initiating or redirecting privileged actions, with no password prompt and no MFA challenge.

Session theft no longer requires sophistication. The dominant vectors capture everything in a single grab:

• /Infostealer malware (LummaC2, StealC, Vidar) reads the browser's cookie and storage database directly off disk. Stolen bundles are sold on darknet markets within minutes, from around ten dollars per device.
• /Malicious browser extensions with cookie permissions read every domain's cookies, including HttpOnly ones — capturing session and identity-provider cookies together.
• /Adversary-in-the-Middle phishing kits (Evilginx-class) relay the entire login — including MFA — in real time and capture the resulting session token.
• /Application-layer XSS exfiltrates the session cookie for the affected domain.

Once the session material is in an attacker's hands, it is imported into their own browser and used directly. The attack that once required network positioning and live interception now needs only a purchase and a browser import.

This is why post-authentication session compromise is among the fastest-growing categories of account takeover (127% YoY growth in 2026). Session vulnerability is a high-severity, largely unaddressed risk for any platform holding sensitive data, performing critical actions — both for individuals and enterprises — or exposing privileged capabilities.

Device Intelligence: Capabilities and Limitations

Most platforms mitigate session security today with Device Intelligence / Fingerprinting and risk-based alerting. These tools, such as Fingerprint.js, LexisNexis ThreatMetrix, or Abnormal AI, evaluate sessions based on device and user attributes — ranging from simple device fingerprint, to device reputation signals, and user behavioral patterns. They score the risk profile, ultimately allowing companies to correlate active sessions with known devices.

The approach is valuable, but it is probabilistic detection, not prevention, and it carries four structural limitations:

• /Imperfect protection. Fingerprinting reads observable, replayable values. Impersonation-as-a-Service (IMPaaS) and anti-detect browsers reproduce a victim's full fingerprint: user-agent, canvas, WebGL, timezone, behind a matching proxy. This way, the stolen session looks like the legitimate user to a scoring engine. The signal it depends on is exactly the signal an attacker can copy.
• /The friction / risk trade-off. Every risk threshold is a compromise. Set it tight and legitimate users are challenged or blocked; set it loose and real attacks pass. No single setting avoids both.
• /False-positive load. Risk scoring is inherently noisy. High-sensitivity policies generate large volumes of probabilistic alerts that require human triage, tuning, and step-up flows, which are ultimately an ongoing operational cost that scales with traffic.
• /Cost that scales with volume. Device-intelligence platforms typically bill per API call / per risk decision. As traffic grows, cost grows linearly, whether or not the evaluated events carry any real risk.

In general, Device Intelligence answers "does this device look suspicious?" It cannot answer "is this the device the session was issued to?" That second question is the one that actually stops session attacks, and it requires a different kind of defense.

Relock: Cryptographic Device Binding

Relock closes the gap at its root. Instead of trying to detect a stolen session after the fact, Relock makes a stolen session structurally unusable.

On first load, Relock generates a set of cryptographic keys inside the user's browser, bound to the device. Every subsequent request carries a fresh, one-time proof that only that system can produce, and the proof is verified on every request. A session token replayed from any other device (however faithfully its fingerprint is reproduced) arrives without valid proof and is rejected.

• /Deterministic, not probabilistic. The outcome is binary: a request either carries a valid device proof or it does not. There is no risk score to tune, no threshold, and no false-positive / false-negative trade-off.
• /Non-reproducibility, not secrecy. Relock's defense does not rest on hiding an observable value an attacker can copy. It rests on possession of device-bound keys that cannot be fully exported, decrypted, and/or reproduced on a different machine.
• /High-frequency rotation and clone detection. Relock keys advance on a continuous schedule, so a stolen artifact goes stale within roughly 30 seconds. If an attacker uses extracted state, it triggers server-side key rotation and creates an immediate difference with the cryptographic state held by the legitimate client. The server inevitably sees the diverging cryptographic states and revokes the session that is bound to the keys.

Relock runs as an external layer on top of the existing session. It requires no change to the application code, identity provider, or session infrastructure: it augments them. This is a shift from detection to prevention: rather than noticing when a session is stolen, there is nothing of durable value left to steal.

Relock vs Device Intelligence: Comparisons and Outcomes

Without any changes to application code, identity providers, or session infrastructure, Relock delivers both significant session security gains and lower costs.

The figures below present a conceptual view of how Device Fingerprinting is currently positioned for session security (Figs. A, B), and how Relock closes the post-authentication gap while cutting costs (Figs. C, D).

Fig. AFig. BFig. CFig. D

Fig. A – Fingerprinting at login only. Fingerprinting at login only keeps costs low (usage capped at 1 API call/login) and mainly feeds network risk-assessment engines, but provides no session-level protection. Once a session is compromised, there is no re-verification moment to stop the attack. This setup is exposed to the full spectrum of in-session attacks: cookie replay, session hijack, Identity Impersonation, and Adversary in the Middle.

Fig. B – Fingerprinting at critical actions. Fingerprinting at every critical action provides moderate session security, as repeated checks allow correlation between the expected fingerprint and the session. It can detect cookie replay and session hijack but only produces risk signals that the security team must still evaluate and action, increasing workload. The higher check frequency also raises costs significantly. This setup remains exposed to attacks that bypass fingerprinting: Identity Impersonation and Adversary in the Middle.

Fig. C – With Relock. On first deployment, Relock establishes cryptographic keys for each device, saves the fingerprint, and binds the session to its origin. Keys are re-verified on every request at no added cost (flat-fee license), so attacks are prevented (not just detected) the moment a stolen session is weaponized. Session security is maximized, fingerprinting costs drop sharply (kept at login only, as in Fig. A) and, when in "enforcement" mode, the security team's workload will be reduced too (i.e., no need to investigate and act on suspicious session activities). This setup is designed to protect against the full spectrum of in-session attacks.

Fig. D – Relock across sessions. Beyond the gains in Fig. C, Relock's chain of cryptographic keys persists across sessions. Even after a session ends, the keys remain in the user's browser, and security checks resume at the start of the next session. This means each device can be fingerprinted to check its risk profile only once per lifecycle, reducing fingerprinting needs by 95%+.

Summary of Outcomes

About Relock

Relock replaces probabilistic, risk-based session security with cryptographic certainty.

By binding every session to device- and origin-bound keys and re-verifying a fresh, one-time proof on every request, Relock makes a stolen session structurally unusable, therefore shifting account takeover defense from detection to prevention. It deploys as an external layer over any existing infrastructure, requiring no changes to application code, identity providers, or session management, and operates on a flat-fee license.

Relock activation is invisible and fully frictionless to the end-user, and is purposefully built to extend session protection to any individual, device, and browser, invisibly.