Akamai Bot Manager runs on more than 1.2 million sites per BuiltWith — airlines, banks, ticketing services, e-commerce, news. Most of the 2022-2023 bypass techniques don't work on them anymore. TLS fingerprint is captured before the first HTTP byte. sensor_data is validated server-side. Datacenter IPs are flagged by ASN. What follows is what Akamai actually checks in 2026 and what bypass approaches apply at each level of difficulty.
What Akamai detects in 2026
Akamai Bot Manager today is five detection layers running in parallel, each independently. A request passes only if it's clean across all five.
TLS fingerprint (JA3, JA4, JA4+). The primary vector. Akamai captures the TLS handshake fingerprint before the client sends a single HTTP byte. ClientHello carries cipher suites, extensions, EC curves, TLS version — all hashed and matched against a database of real browsers. Standard Python requests, urllib, httpx have their own characteristic JA3, and Akamai classifies them as "not a browser" instantly.
HTTP/2 fingerprint. SETTINGS frame, WINDOW_UPDATE, PRIORITY frames. Every HTTP/2 client opens a session with a set of parameters carrying specific values: SETTINGS_HEADER_TABLE_SIZE, SETTINGS_INITIAL_WINDOW_SIZE, SETTINGS_MAX_FRAME_SIZE. Chrome, Firefox, Safari each have a distinct signature, and standard HTTP clients have a third. The Black Hat EU 2017 paper documents this in detail and follow-up research has expanded on it since.
sensor_data plus the _abck cookie. A 58-element array assembled by JavaScript on the page: canvas fingerprint, motion trajectory (mouse, clicks, scroll), hardware properties, browser capabilities. The array is encrypted with Akamai's proprietary algorithm and POSTed to an endpoint. The response sets the _abck cookie. Convincing sensor_data leads to a valid _abck and lets subsequent requests through. Unconvincing sensor_data results in either a 403 or in requests that pass but with 5-10 seconds of added processing latency.
Behavioral signals. The behavioral layer evaluates flow: which page you came from, in what order you click, how the mouse moves, whether you spend time looking at the page before acting. Bots tend to act either too fast or too uniformly. This layer runs on top of sensor_data and assesses the entire session, not single requests.
IP reputation. ASN scoring. Akamai knows AS14061 (DigitalOcean), AS16509 (AWS), AS14618 (Amazon EC2), AS396982 (Google Cloud) and equivalents are datacenters. Requests from those ASNs get a poor score automatically. Residential ISP blocks and mobile ASNs get a good score.
All five layers run simultaneously and feed into a combined risk score. Akamai doesn't block on a single bad signal but doesn't pass when several add up.
What stopped working
Standard Python requests, urllib, httpx. Falls on TLS fingerprint within the first second. No User-Agent header rescues it — TLS is checked before HTTP.
Selenium with puppeteer-extra-stealth or playwright-stealth. JS-layer patches close navigator.webdriver and fake plugins, but the TLS fingerprint stays "headless Chrome" and canvas/audio create their own anomalies. On Akamai BMP sites, detection is unreliable to inconsistent at best.
Datacenter IPs alone with any rotation strategy. ASN scoring closes the question on the first request.
User-Agent spoofing alone. Akamai sees TLS before headers.
JA3Proxy in isolation. It spoofs TLS, but doesn't close HTTP/2 fingerprint or behavioral.
Minimum working stack
For most Akamai sites, three out of five layers must be closed by the client side: TLS, HTTP/2, and IP reputation. sensor_data and behavioral are closed either by a real browser or by a commercial service. Without a correct TLS+HTTP/2 fingerprint nothing else matters — the request is rejected at layer one.
TLS and HTTP/2 fingerprint. Solved by a library with native TLS impersonation of real browsers. The most common is curl_cffi for Python (supports Chrome, Firefox, Safari, Edge in various versions). Alternatives: tls-client for Go, scrapy-impersonate for Scrapy, curl-impersonate as the baseline tool. They modify the TLS handshake itself and the HTTP/2 SETTINGS frame to match a specific browser version.
IP reputation. Residential proxies with sticky sessions. A sticky session means one user-flow runs through one IP — Akamai dislikes IPs changing mid-login or mid-checkout. Geo-locale of the proxy must align with the browser's claimed locale: en-US headers with an IP in Germany is a basis for an anomaly score.
Headers and navigation flow. Warm up the homepage before hitting the target. Set Referer and Accept-Language to match the impersonated browser. TLS-impersonation libraries set most headers automatically but Referer and Accept-Language usually need tuning per target site.
On sites with basic Akamai BMP and lenient sensor_data validation, this stack is enough. Akamai issues an _abck on a clean "Chrome-like" TLS handshake, and session cookies carry through to subsequent requests automatically.
When you need to warm up cookies in a real browser
On sites with strict sensor_data validation (premium ticketing, major airlines, banks), Akamai won't issue a valid _abck on a bare TLS handshake. To make _abck valid, you need a real sensor_data POST, and that means canvas, motion trajectory, and JS execution. A TLS-impersonation library doesn't do that.
The fix is a two-stage flow. Stage one: open the page in a real browser with binary-level stealth patches, let JS run and the sensor do its work. You receive cookies (_abck, ak_bmsc, bm_sz). Stage two: transfer the cookies into a TLS-impersonation session and continue scraping at its speed without the overhead of a full browser.
A critical detail: the browser engine on stage one and the impersonate target on stage two must match. Akamai's own documentation (techdocs.akamai.com/cloud-security/docs/detection-methods) lists browser version mismatches as an anomaly detection signal. If sensor_data was POSTed with a Firefox fingerprint and subsequent requests come with a Chrome-impersonate TLS handshake, that's caught. Working pairs:
Camoufox (Firefox-based stealth browser) on stage one, impersonate=firefox-NNN in the TLS-impersonation library on stage two.
Patchright (Chromium-based stealth browser) on stage one, impersonate=chrome-NNN on stage two.
Plain Playwright or Puppeteer with JS-stealth plugins on stage one is not enough — Akamai detects them at the binary layer before they ever submit sensor_data.
The _abck cookie has a finite lifetime that depends on the site's configuration. When a 403 starts hitting on subsequent requests, the cycle repeats: back to a real browser, fresh cookies, transfer to the session.
Hard sites with aggressive behavioral
Top-tier Akamai targets (Ticketmaster, premium ticketing, major airlines, banks) deploy every layer at maximum strictness. Beyond strict sensor_data validation, the behavioral layer evaluates timing and flow across the full session. Cookie transfer from a browser to a TLS-impersonation library typically isn't enough on these sites — you either keep the session in a browser end-to-end or simulate behavior on top. Three options for these targets.
Open-source toolkits. Several active GitHub projects reverse-engineer sensor_data. The serious ones: github.com/xiaoweigege/akamai2.0-sensor_data, github.com/luluhoc/akamai_v2_toolkit, github.com/glizzykingdreko/akamai-sensordata-decryptor, github.com/reverse-god/akamai-sensordata. This path is for those who can read reverse-engineered Akamai algorithms and maintain code through Akamai's updates.
Real browser plus behavioral simulation. Camoufox over residential proxies, plus a library for plausible mouse, keyboard, and timing simulation. The output is a real sensor_data that passes even strict configurations. Higher time cost but stable.
Commercial bypass-as-a-service. Scrapfly ASP, ScraperAPI bypass-akamai, Bright Data Web Unlocker. They run their own Akamai parser and pay engineers to keep up with each update. You pay per request and receive ready HTML.
Alternative for those who skip DIY
Managed services cost more per request (cents on hard targets versus fractions of a cent for a residential request) but absorb the engineering.
Scrapfly ASP, ScraperAPI bypass-akamai, Bright Data Web Unlocker — working commercial options. The math works when engineering time costs more than the paid API.
TL;DR
Akamai in 2026 is five parallel layers: TLS fingerprint (JA3, JA4), HTTP/2 SETTINGS frame, sensor_data plus _abck cookie, behavioral signals, IP reputation. A request passes only when it's clean across all five.
Basic Akamai configurations: TLS-impersonation library (curl_cffi or equivalent) plus residential proxy with sticky session plus warmup on the homepage before the target. This stack closes TLS, HTTP/2, and IP, and passes sites where sensor_data validation is lenient.
Sites with strict sensor_data validation: warm up cookies in a real browser with binary stealth patches (Camoufox or Patchright), then transfer them to a TLS-impersonation session. The browser engine and the impersonate target must match — otherwise Akamai sees a browser version mismatch.
Top sites with aggressive behavioral: open-source toolkits, real browser with behavioral simulation, or commercial Scrapfly ASP / ScraperAPI / Bright Data Web Unlocker.
What doesn't work in 2026: plain Python requests, plain Selenium-stealth, datacenter only, User-Agent spoofing only, JA3Proxy alone.