Bot Detection & Fingerprinting

Behavioral Bot Detection:
How Platforms Score
Your Sessions

Cloudflare, Akamai, and DataDome don't run one bot check, they run a composite score. This is how the network, device, and behavioral layers underneath that score actually work, with the real numbers behind each one.

Hirusha Sasanka | Junior Developer | August 13, 2026 | 16 min read

Abstract glowing data lines converging into nodes, representing multiple detection signals feeding into one composite bot score.

Key Takeaways

A platform doesn't run one bot check, it runs a composite score. Cloudflare's Bot Score (1-99) and Akamai's Bot Manager score (0-100) both combine network/protocol, device, and behavioral signals into one number before deciding whether to allow, challenge, or block a session.
TLS/JA4 fingerprinting alone is already strong. A 2026 study trained classifiers on 227,404 JA4 fingerprints and hit 98.63% accuracy, but its own authors flag the ceiling: it can't catch tools that fully emulate a real browser's TLS stack.
That ceiling is why the behavioral layer exists. DataDome's own documentation describes collecting 35+ behavioral signals per session, mouse trajectory, scroll velocity, keystroke timing, scored against known human and bot baselines in real time.
Bots made up 53% of global web traffic in 2026, and AI-driven bot attacks grew 12.5x year over year (Thales/Imperva 2026 Bad Bot Report). As static signals get cheaper to fake, behavioral scoring carries more of the classification weight.
A clean IP does not offset a bad behavioral score. The composite model weighs session realism, not just network reputation, which is why two requests from the same IP can score differently.

Half the requests hitting a website in 2026 aren't from a person. Bots accounted for 53% of global web traffic this year, up from 51% in 2024, while AI-driven bot attacks grew 12.5-fold year over year, with the daily average of blocked AI-related incidents climbing from roughly 2 million to 25 million (Thales/Imperva 2026 Bad Bot Report). Every major bot-management platform, Cloudflare, Akamai, DataDome, HUMAN Security, responded to that shift the same way: not with a single yes/no check, but with a composite risk score assembled from multiple independent layers of evidence.

This piece is about how that score actually gets built, at the signal level. It's written for developers evaluating or building automation, not for someone deciding which proxy to buy, so if you're specifically working through "my IP is clean, why am I still blocked," our companion piece on why a clean IP still gets flagged by Cloudflare, DataDome, and Akamai covers that angle directly. Here, the question is different: what specific signals go into the score, how are they weighted, and why did the industry converge on behavioral biometrics as a load-bearing layer instead of a nice-to-have.

Bots overtook nearly half of all measured web traffic in 2026. Source: Thales/Imperva 2026 Bad Bot Report.

What "Behavioral Bot Detection" Actually Means

🔐

Behavioral Bot Detection

The practice of classifying a session as human or automated by analyzing how a visitor interacts with a page over time, mouse movement, scroll physics, keystroke timing, click cadence, rather than only what the visitor's request looks like at a single point in time (IP, headers, TLS handshake).

That distinction matters because it separates behavioral detection from the two layers it usually sits on top of. Network and protocol signals (IP reputation, TLS/JA4 fingerprint) describe the connection. Device signals (headless-browser tells, canvas/WebGL rendering, execution timing) describe the client software. Behavioral signals describe the person, or the absence of one, driving that client across an entire session, not just a single request. A request can pass every network and device check and still fail behaviorally if the mouse path is too straight, the keystrokes are too evenly timed, or there's no scroll jitter at all.

The Three Layers a Composite Score Actually Combines

No major platform scores behavior in isolation. Cloudflare's machine learning engine ingests request headers, session characteristics, and browser signals together to produce its 1-99 Bot Score; Akamai explicitly combines multiple detection layers into one score rather than relying on any single one (Cloudflare Bot solutions docs; Akamai Bot Manager documentation). The practical architecture looks like this:

How a Composite Bot Score Gets Built

Editorial synthesis based on Cloudflare, Akamai, and DataDome public documentation.

Each layer catches what the layer before it misses. That's the actual reason behavioral detection exists as a distinct discipline, not just a marketing category: network and device signals are the easiest to fake with enough engineering effort, and behavioral signals are, so far, the hardest.

Layer One: Network and Protocol Fingerprinting (JA3 to JA4)

TLS fingerprinting was the first widely deployed layer, and it's still doing real work. The idea is simple: when a client opens a TLS connection, it sends a Client Hello packet listing its cipher suites, extensions, and supported versions, in a specific order. Different TLS libraries and browser builds produce different orderings, so the fingerprint of that handshake can identify the client software independent of whatever User-Agent header it sends.

JA3, the original version of this fingerprint, broke in 2023: Chrome 110 shipped ClientHello extension order randomization, which meant a real Chrome browser could generate a different JA3 hash on every connection, destroying its reliability as a stable identifier. JA4 fixed this by sorting extensions and ciphers alphabetically before hashing, so the output stays stable regardless of the browser's internal randomization, while compressing the result into a readable 36-character string. By 2026, JA4 had been adopted across Cloudflare, AWS WAF, VirusTotal, and Akamai, and DataDome folds it into its own signal stack alongside TCP/IP-level and HTTP/2 frame fingerprinting (Auth0, "Strengthening Bot Detection with JA4 Signals").

How good is protocol fingerprinting on its own? A 2026 academic study trained CatBoost and XGBoost classifiers on 227,404 labeled JA4 fingerprints (roughly 22% bad bots, 65% benign traffic, with known good bots excluded from training) and evaluated them on a held-out 20% test split. The CatBoost model reached 98.63% accuracy, 96.70% precision, 98.00% recall, and an AUC of 0.998, with the cipher-suite hash and extension count among the most predictive individual features (arXiv, "When Handshakes Tell the Truth: Detecting Web Bad Bots via TLS Fingerprints", 2026).

Source: arXiv, "When Handshakes Tell the Truth: Detecting Web Bad Bots via TLS Fingerprints," 2026.

That's a strong result, and it's also where the paper's own authors put the boundary: the method cannot detect bots running full browser-stack emulation, tools like Playwright or Puppeteer driving a genuine browser engine, or advanced TLS-spoofing tools built specifically to mimic a legitimate fingerprint. A real browser produces a real, valid JA4 hash no matter what's driving it. That's precisely the gap the next two layers exist to close.

A computer monitor displaying lines of programming code, representing the protocol and browser-level signals a bot-detection engine inspects before a page ever loads.

Layer Two: Device and Browser Signals

The second layer stops asking "what does the connection look like" and starts asking "what is actually rendering this page." Cloudflare's JavaScript Detections engine, for example, runs a lightweight, invisible script client-side specifically to identify headless browser automation that a network-layer check would miss entirely, since a headless Chromium instance can still produce a technically valid JA4 fingerprint (Cloudflare Bot solutions docs). Akamai's transparent detection layer looks for a broader set of request-level tells that don't require any client-side script: out-of-order headers, framework signatures, and mismatches between a claimed browser version and its actual behavior, all fed into calibrated risk scoring before a response is decided.

🌐

Headless Detection

Identifying browser automation frameworks (Puppeteer, Playwright, Selenium) by probing for the subtle rendering, timing, or API differences between a headless browser instance and a real, human-driven one, typically via injected JavaScript that a normal page visit wouldn't trigger.

Newer implementations push further into execution-level fingerprinting. Industry reporting on HUMAN Security's Bot Defender (formerly PerimeterX) describes an approach that measures the execution speed of specific mathematical operations inside WebAssembly to infer the true underlying browser engine, independent of whatever the User-Agent string claims, alongside a JavaScript sensor collecting device, browser, and behavioral signals together and posting them to a collector for scoring (HUMAN Security product documentation). For a deeper side-by-side of what each major vendor checks at this layer, see our comparison of what Cloudflare, DataDome, and HUMAN Security actually check, and our dedicated piece on browser fingerprinting in 2026 goes further into canvas and WebGL-specific checks than fits here.

Why This Layer Isn't Enough Alone

Device-level checks answer "is this genuinely a human-driven browser instance," but they say nothing about what happens after the page loads. A real Chrome window under full programmatic control, mouse events dispatched by a script rather than an OS-level cursor, passes every device check while still behaving nothing like a person. That's the gap behavioral detection is built to close.

Layer Three: Behavioral Biometrics, Mouse, Keystroke, and Scroll Dynamics

This is the layer that actually watches how a session unfolds, not just what it's running on. DataDome's own documentation describes collecting 35+ behavioral signals per session, spanning mouse trajectory, speed, and micro-movements, scroll velocity and depth, keystroke inter-key timing and press duration, and click coordinates, then feeding all of it into machine learning models trained on billions of requests to build a real-time behavioral profile for every visitor (DataDome bot-detection and behavioral-classification documentation).

The specific patterns that separate the two classes are well-documented across vendors:

Mouse dynamics. Real human mouse movement produces curved, slightly erratic paths with natural acceleration and deceleration, along with small involuntary micro-movements while hovering. Scripted or replayed mouse paths tend toward straight lines or mathematically perfect curves, and the complete absence of micro-movements is itself a signal.
Keystroke dynamics. Human typing varies in inter-key timing and includes natural pauses, hesitations, and corrections. Automated form-filling tends to produce keystrokes at suspiciously uniform intervals, a pattern that's straightforward to model statistically once you're logging timing at the keystroke level rather than just the submitted value.
Scroll and interaction timing. How long a session waits between page load and its first interaction, and how scroll velocity changes across a page, both feed the same behavioral model, since bots that don't bother rendering realistic delays stand out against a human baseline built from real traffic.

Peer-reviewed research backs the strength of this signal class. One 2025-2026 comparison of keystroke-dynamics and mouse-trajectory classifiers for bot detection reported test-set accuracy of 99.98% for its keystroke-timing model and 99.72% for its mouse-movement model (Springer, "Behavioral Biometrics: A Comparison of Keystroke Dynamics and Mouse Trajectories for Bot Detection," 2025-2026), figures reported in a controlled research setting rather than adversarial production traffic, but directionally consistent with why every major platform now treats this layer as load-bearing rather than supplementary.

Vendor	Composite Score Range	Behavioral Signals Documented	Notable Layer Emphasis
Cloudflare	1-99 (ML-generated)	Session characteristics, request patterns via `__cf_bm` cookie	Supervised ML trained on billions of daily requests across the network
Akamai	0-100	Movement patterns on transactional endpoints (Behavioral Detection, Premier tier)	Score persistence: repeated bad activity from the same client raises the score over time
DataDome	Proprietary, tiered	35+ signals mouse, keystroke, scroll, click, documented per session	Real-time ML profile built and compared against baselines per session
HUMAN Security	Proprietary risk score	Mouse, scroll, touch pressure, keystroke cadence via JS sensor	WebAssembly execution-timing fingerprinting layered under behavioral signals

A close-up of a hand typing on a keyboard, representing the inter-key timing and press-duration signals behavioral engines log at the keystroke level.

How the Composite Score Actually Gets Computed

Once all three layers have reported in, a platform still has to turn that into one number and one decision. Cloudflare's documented scale runs 1-99: a score of 1 means the system is "quite certain" the request was automated, 2-29 indicates likely automated traffic, and 30-99 indicates increasing confidence the request came from a human (Cloudflare Bot solutions docs). Scores of exactly 1 or 29 typically come from the heuristics engine matching a known malicious fingerprint pattern rather than the ML model itself, and the __cf_bm cookie smooths the score across a session's requests to reduce false positives from a single noisy data point.

Akamai's Bot Manager scale runs 0-100, where 0 represents high confidence in a human and 100 represents high confidence in a bot, and the score is explicitly designed to move: as the volume of requests attributable to the same client grows, the score can climb further, a persistence factor that punishes sustained automated behavior more than a single suspicious request (Akamai Bot Manager documentation).

👤

From Our Team

The part that surprised me when I first instrumented a test session against a bot-managed site wasn't that behavioral signals mattered, it was how fast the score moved once I stopped generating any mouse events at all between page loads. A clean TLS fingerprint and a real browser engine bought maybe the first two or three requests. By the fourth, with zero scroll and perfectly timed navigation, the composite score had already dropped enough to trigger a challenge, well before anything about the network layer had changed.

Why a Clean IP Doesn't Save a Bad Behavioral Score

This is the part that trips up a lot of setups that otherwise look solid on paper: a residential or ISP IP with a good reputation is one input into the network layer, not a multiplier on the whole score. If the behavioral layer is reporting perfectly linear mouse paths and uniform click timing, a clean IP doesn't offset that; it just means the network layer contributes less risk than it otherwise would. The composite model doesn't average away a bad layer, it factors all of them in, and a strong human-behavioral score can carry a session through checks that a weak one fails even from the same network origin. Our companion piece on why a clean IP still gets you blocked by Cloudflare, DataDome, and Akamai walks through that failure mode from the buyer's side in more depth than fits here.

What This Means When You're Building or Evaluating Automation

Practical Takeaway

Session realism now matters as much as network reputation, and on some platforms more. A script that dispatches synthetic mouse events with linear interpolation, types at fixed intervals, and never scrolls off-path is giving the behavioral layer everything it needs to flag the session, regardless of how clean the underlying IP and TLS fingerprint are.

Three things follow directly from how the composite model works:

Network-layer hygiene is necessary but not sufficient. A static, ASN-registered IP or a real residential connection still matters for the protocol layer, since a datacenter-hosted IP with a mismatched ASN is an easy signal to weight heavily. But treat it as one input among three, not the whole answer. This is the practical reason a lot of automation setups pair ISP proxies or residential IPs with genuine behavioral realism rather than relying on IP reputation alone.
Full browser-engine emulation closes the device-layer gap, not the behavioral one. Running Playwright or Puppeteer against a real Chromium build defeats headless-detection checks, but it does nothing about mouse and keystroke timing unless the automation script specifically injects realistic interaction patterns.
The behavioral layer is the hardest to fake cheaply, which is exactly why the research in this piece keeps landing on it as the deciding factor. Our full anti-detection stack guide goes further into what a realistic interaction profile actually requires end to end.

Frequently Asked Questions

Partially, and vendors actively defend against the obvious version of this. Simply recording and replaying a real human's mouse and keystroke data is a known evasion attempt, which is why platforms like Akamai explicitly note that behavioral analysis is built to detect bots "even when they attempt to mimic human behavior or replay previously validated telemetry," rather than trusting raw signal shape alone.

Not automatically, but it starts at a disadvantage. A headless browser instance can still produce a valid TLS/JA4 fingerprint, so device-layer checks specifically exist to catch the rendering and timing differences headless mode introduces. Combined with the behavioral layer's expectation of realistic mouse and scroll activity, a headless session with no injected interaction data tends to accumulate risk quickly even if it passes network-layer checks cleanly.

This varies by vendor and isn't fully public, but Akamai's own documentation describes persistence as a factor: a client's score can climb as more requests accumulate evidence of automated behavior, meaning the system is tracking a session (or a device/network combination) over time rather than scoring each request independently from a clean slate.

No, and the research in this piece is fairly direct about why. A CatBoost classifier trained purely on JA4 fingerprints reached 98.63% accuracy, but its authors explicitly note it cannot catch bots running full browser-stack emulation or advanced TLS-spoofing tools, since those produce a technically valid fingerprint from a real browser engine. That's precisely why device and behavioral layers exist on top of it.

Summary

A composite score, not a single check. Cloudflare (1-99) and Akamai (0-100) both combine network/protocol, device, and behavioral layers into one number before deciding whether to allow, challenge, or block.

TLS/JA4 fingerprinting is strong but bounded. A 2026 study hit 98.63% accuracy on JA4 fingerprints alone, but its authors flag that full browser-stack emulation defeats it.

Behavioral biometrics carry real weight. DataDome documents 35+ per-session signals, and research on keystroke/mouse classifiers reports accuracy above 99% in controlled test sets.

A clean IP doesn't offset a bad behavioral score. The composite model factors in all three layers; network reputation reduces risk at that layer specifically, not across the whole score.

Bot traffic crossing 53% of the web in 2026, with AI-driven attacks growing 12.5x year over year, is why this architecture keeps getting more layers rather than fewer. Understanding where each layer's blind spot sits, and why behavioral signals close the gap that protocol and device checks leave open, is the difference between debugging a block by guesswork and actually knowing which layer flagged the session.

TorchProxies runs residential and ISP proxy plans built for the network layer of this stack: Standard, Premium, and Plan X residential for rotating and sticky sessions, and static, ASN-registered ISP Proxies when a dedicated IP is what the workload needs. Neither replaces realistic session behavior, but both give the network layer of a composite score less reason to flag you before the behavioral layer even gets a look.

Behavioral Bot Detection:How Platforms ScoreYour Sessions