The history of Akamai Bot Manager: from the 2016 Cyberfend acquisition to today

Akamai did not start as a security company. It started as a content delivery network, born out of MIT in 1998 to move bytes closer to users. So how did a CDN end up running one of the most studied bot-detection systems on the public web, the thing that sits between a Python script and a sneaker drop and quietly decides which one you are? The short version is that the same edge that caches your images also sees every request before your origin does, and that vantage point turned out to be worth more for catching automation than for serving JPEGs.

The longer version runs through a small Santa Clara startup, a credential-stuffing epidemic, and a decade of an arms race that pushed Akamai’s client-side sensor from a few hundred kilobytes of readable JavaScript into a per-tenant, self-rotating virtual machine. This post walks that history in order. It is a reference, not a how-to: where the internals are public I cite them, and where they are not I say so and stick to what observed traffic and vendor docs actually support.

The sections below go roughly chronological. First the pre-Cyberfend baseline and the February 2016 launch of Bot Manager. Then the December 2016 Cyberfend acquisition and what it actually bought. Then Bot Manager Premier in 2017 and the mobile SDK. Then the move from a signature directory to a behavioral score, the sensor’s version history, and the products that grew out of the same telemetry: Account Protector, Content Protector, and the rest. A closing section on where the line sits in 2026.

The CDN that could see everything

Before there was a product called Bot Manager, there was a network that happened to be in the right place. Akamai’s edge terminates connections for a large slice of the world’s high-traffic commerce, travel, and media sites. Every request to a protected origin passes through an Akamai server first. That means Akamai sees the raw shape of a connection (its TLS handshake, its HTTP/2 frame ordering, its header casing) before any application code runs, and it sees those signals across many tenants at once. A scraper that hammers one airline looks like a single visitor to that airline. To Akamai it can look like the same client hitting forty airlines.

The early bot defenses were coarse. Rate limits, IP reputation lists, blocklists of known data-center ranges. These are server-side and stateless: they judge a request by where it came from and how fast it arrives, not by what the client is. They catch the loud, cheap bots and miss everything else. By the mid-2010s the loud bots were no longer the problem. The problem was automation that looked, at the protocol level, exactly like a browser, because it often was a browser, driven by a script.

Akamai’s answer, announced on February 17, 2016, was Bot Manager. The pitch leaned against the binary that came before it: until now, Stuart Scholly (then SVP of Cloud Security Solutions) said, companies could “block them or suffer in silence.” Bot Manager shipped with a directory of more than 1,300 pre-defined bot signatures across 15 categories of known web services, and the selling point was management rather than a wall. You could identify a category of bot and choose a response per category: serve it, slow it, feed it alternate content, or drop it. Good bots (search crawlers, partner integrations, uptime monitors) got a lane. Bad ones got friction.

That first release was still mostly a catalog. A signature directory is a known-knowns system. It is excellent at labeling the Googlebots and the Bingbots of the world and useless against a bespoke scraper that has never been seen before. Akamai knew this. The interesting part of the 2016 product was the part that did not depend on the catalog: real-time detection of unknown bots, which needed a way to look at a client and decide it was automated without a matching signature. That capability is what the company went shopping for at the end of the same year.

*The detection surface widened over time rather than swapping one method for another. Server-side reputation is still the first filter; the client sensor is the layer that the 2016 catalog could not provide.*

December 2016: what Cyberfend actually bought

On December 18, 2016, Akamai announced it had acquired Cyberfend, a privately funded startup based in Santa Clara. Financial terms were not disclosed; it was an all-cash deal. Cyberfend was tiny and specialized. It built bot and automation detection for web and mobile, and its flagship, BotFender, was aimed squarely at credential abuse: account takeover, payment fraud, the attacks where the bot’s job is to test stolen passwords or card numbers at scale against a login or checkout endpoint.

The founders were Sreenath Kurupati, the CEO, and Sridhar Machiroutu. Kurupati’s background is worth a line because it explains the technical flavor of what Cyberfend brought. Before the startup he had been a chief architect in Intel’s Digital Home Group and led computer-vision work there. Cyberfend’s own description leaned on that lineage: it called its approach a combination of human cognitive science and machine learning, and claimed BotFender was already protecting close to a billion login and payment transactions a month for large e-commerce and payment customers.

That last claim is the one that mattered to Akamai. Cyberfend’s models were not a research prototype. They were running in production against real credential-stuffing traffic, which meant they had been trained on the thing that signature directories cannot catch: bots that behave like people. The acquisition rationale from Stuart Scholly was narrow and honest about it. The point of buying Cyberfend was “a better way to spot and stop credential abuse.” Not a grand unification of security; a specific gap in the 2016 Bot Manager, filled by a team that had already solved it elsewhere.

There is a structural detail here that shaped everything after. Cyberfend’s detection was behavioral and client-aware. To decide whether a login attempt was a human or a script, you have to collect something about the client beyond its IP, and you have to collect it from inside the page. That is a fundamentally different data path from the stateless edge filters Akamai already had. It needs JavaScript running in the browser, gathering signals, and shipping them back to be scored. The Cyberfend acquisition is the moment Akamai’s bot defense committed to a client-side sensor. Everything about the _abck cookie, the sensor_data payload, and the obfuscated script that people reverse-engineer today descends from that commitment.

*The behavioral path in orange is the architectural debt the Cyberfend deal took on: a client-side sensor that has to run in the page, collect signals, and post them back to be scored. The stateless filters above it stayed.*

If you want the modern shape of that POST in detail, two sibling pieces go deeper than this history will: one on Akamai’s sensor_data payload and its telemetry sources, and one on the _abck cookie and the validation handshake. Here the point is just the lineage.

2017: Bot Manager Premier and the credential-stuffing era

Cyberfend’s technology shipped inside a new tier. On October 10, 2017, Akamai announced Bot Manager Premier. The emphasis had shifted hard toward fraud. The original 2016 product talked about content scraping and aggregation; Premier talked about credential abuse, gift-card and stored-value balance checking, and login-page fraud. The context was a credential-stuffing wave that the whole industry was feeling. Akamai cited a Ponemon survey in which 54% of respondents said credential-stuffing attacks were getting worse and 70% thought their existing tools were inadequate. The company’s own CEO, Tom Leighton, put a startling number on it: across the Akamai platform, roughly two-thirds of login attempts were malicious.

The headline capability in Premier was behavior anomaly analysis, the direct product of the Cyberfend acquisition. Akamai described it as detecting bots disguised as human interactions, even when those bots keep changing their behavior to evade detection. Under the hood it used custom algorithms with both supervised and unsupervised machine learning. Supervised models learn from labeled good and bad traffic; unsupervised ones flag clients that simply do not fit the population. That pairing is the same idea Account Protector would later sell on its own.

The other thing Premier got right was deployment. Josh Shaul, then VP of web security, made the point that the credential-abuse protections ran at the Akamai edge during normal content delivery, so customers did not have to change their applications to get them. For a security product this is most of the battle. The reason organizations tolerate a 20,000-line obfuscated script on their checkout page is that turning it on was a config change, not an engineering project. The edge was already in the request path; Bot Manager just started doing more there.

Premier also reached off the web. In April 2018, as part of Akamai’s spring release, the Bot Manager Premier SDK arrived for native mobile apps. The mobile SDK takes the same behavioral telemetry idea and bakes the collection component into the app binary. Instead of a browser running JavaScript, the compiled app calls the SDK to gather device characteristics, orientation, accelerometer readings, and touch events, then ships that sensor data to Akamai to be scored the same way. This is an important branch in the family tree. The web sensor and the mobile SDK are siblings, both producing a sensor_data-style payload, which is why people working on mobile API automation run into Akamai’s BMP collection in places that have no browser at all.

From a catalog to a score

Step back and the 2016-to-2018 arc is a single move: Akamai stopped asking “is this a bot I have a name for?” and started asking “how automated does this client look?” The signature directory did not disappear. It became one input among many. The output that matters today is a number.

Akamai’s current description of Bot Manager makes this explicit. The product assigns a Bot Score to each request, on a scale where one end is human and the other is bot, and customers pick a response posture (the public product page names Cautious, Strict, and Aggressive tiers) that maps score ranges to actions. The score is fed by several streams at once: server-side reputation and protocol fingerprinting, the JavaScript behavioral sensor injected into the page, and intelligence aggregated from what Akamai describes as billions of bot requests and logins seen daily across its network. The cross-tenant view from the CDN, the thing that made Akamai well placed for this in the first place, is one of the score’s inputs.

The mechanics of turning collected signals into that number are covered in the companion post on Bot Manager scoring; the exact server-side model is not public, and that post is careful about the boundary between documented behavior and inference. For this history, the relevant shift is conceptual. A signature match is a boolean: you are Googlebot or you are not. A score is a probability, and a probability degrades gracefully. It lets the edge be unsure about a client and respond proportionally (a soft challenge, a slowdown) instead of a hard block that a determined operator will simply detect and route around. The score range and response postures (Cautious, Strict, Aggressive) decide where the band boundaries fall, and they are configurable per tenant, which is why the same client gets challenged on one site and waved through on another. The whole second decade of Bot Manager is the consequence of that design choice.

The sensor’s own version history

The part of Bot Manager that the public reverse-engineering community tracks most closely is the client sensor, and it has a version history of its own. The numbers people use (v1, v2, v3) are community labels for successive generations of the script and its sensor_data format, not official Akamai product versions. With that caveat: the trajectory has been steadily toward making the payload harder to forge and the script harder to read.

The visible structure is well established. A protected page loads a heavily obfuscated script. Community write-ups in 2025 and 2026 put its size in the hundreds of kilobytes (one figure circulating is around 512KB) and its signal count above 100 browser, device, and behavioral properties. The script collects telemetry through a global object commonly seen as bmak, packs it into the sensor_data field, encodes the result, and POSTs it to Akamai’s validation endpoint. The response sets or updates the _abck cookie, which the edge then re-checks on subsequent requests. That loop is documented in the sibling posts and visible to anyone who opens a network panel.

What changed across versions is the encoding and the anti-tamper. The earlier formats were obfuscated but comparatively static, which made a deobfuscate-once, replay-many approach viable for a while. The later format (the one the community calls v3) tightened that. Per public 2026 write-ups, the script is delivered per-tenant, the obfuscation seed rotates, and the encoding of the payload is seeded from session state (a hash derived from the bm_sz cookie value is described as feeding the character-substitution step), so a payload captured for one site or one session does not validate elsewhere. The honest caveat here is large: the exact byte layout of sensor_data and the precise encryption are not documented by Akamai. Everything in this paragraph is inferred from observed traffic and from third-party deobfuscation, and Akamai actively works to keep it that way.

That last point is the whole strategy, and Akamai is open about the principle even if not the details. The company describes Bot Manager’s dynamic obfuscation of code and telemetry as a defense against reverse engineering, with the explicit goal of keeping effectiveness high over time. The logic is economic, not cryptographic. Obfuscation does not make the script impossible to read; it makes reading it expensive and perishable. An operator who deobfuscates today’s script and ports its virtual machine to a server-side runtime has a working forgery until the seed rotates or the layout shifts, at which point the work has to be redone. The defender’s bet is that they can rotate faster than the attacker can re-tool. The community write-ups from 2026 that warn against chasing the deobfuscator are making the same observation from the other side: the moving target is the point.

This is also where a defensive piece like this one draws a hard line. The mechanism above is described so a defender understands what their _abck and sensor_data are doing and why a transplanted cookie fails. It is not a recipe. Generating a valid sensor for a tenant you do not control is the forgery Akamai’s obfuscation exists to make uneconomical, and walking through it is not what this blog is for.

*The loop is observable; the encoding is not documented. The orange bar is the defensive bet: rotate the target faster than an operator can re-tool against it.*

Account Protector: the same telemetry, pointed at humans

By 2021 Akamai had a sensor that could tell a script from a person fairly well. The next move was to use that same machinery against a problem bots are only half of: account abuse by actual humans. A credential-stuffing bot and a fraudster manually logging into a stolen account both want the account, but only one of them is automated. Bot detection alone misses the human attacker who logged in by hand.

Account Protector launched on June 15, 2021, and it was explicitly positioned as an extension of Bot Manager rather than a separate product. Where Bot Manager asks “is this client automated,” Account Protector asks “does this login look like the legitimate owner.” It does that with three layers. User behavioral profiles model an individual’s normal signals: the locations, networks, devices, and activity times previously seen for that account. Population profiles model the whole user base, so a first-time login with no individual history can still be judged against what the population does. Reputation data brings in Akamai’s cross-network view of malicious activity: a single user connecting from many places in a short window, attempts to touch a large number of accounts, a high failed-login rate. Eric Graham, then VP of security product management, pitched it as reducing remediation burden and adding trust without friction for good users.

The supervised-plus-unsupervised pattern from Premier is visible here too. The individual and population profiles are the unsupervised side (anomaly relative to a baseline), and the reputation signals are closer to labeled bad behavior. It is the Cyberfend idea, generalized: collect rich client and behavioral signals, build a baseline, score the deviation.

Account Protector kept growing along the account’s whole lifecycle. On October 29, 2024, Akamai announced an expansion past the login moment. The update added risk evaluation at account creation (to catch fake-account and account-opening abuse), and three new API-side detections for sensitive post-login actions: Account Update, to flag an imposter editing account details; Password Change, to catch the password reset that often follows a takeover; and Payment, to flag fraudulent transactions. The argument in the announcement was that static risk checks at login alone are no longer enough, so risk has to be re-evaluated continuously across the session. That is a meaningful shift from the 2021 product, which was anchored to the login event.

The product line fans out

The same telemetry-and-score core kept spawning specialized products, each aimed at a particular flavor of unwanted automation. The clearest recent one is Content Protector, announced on February 6, 2024, and pitched as the first Akamai product built specifically for scraping rather than general bot management. The threats it names are the scraping-specific ones: competitors undercutting prices, inventory hoarding through constant surveillance, counterfeiters lifting catalog data, and the raw load of bots hammering endpoints.

Its detection stack reads like a consolidation of everything the lineage had learned. Protocol-level assessment fingerprints how the client connects, checking OSI-layer parameters against what a real browser or mobile app should look like (the network-layer signal that overlaps with TLS and HTTP/2 fingerprinting). Application-level assessment checks that the client can actually run JavaScript business logic and that its claimed device and browser characteristics hold up. User-interaction analysis looks at touch, keyboard, and mouse patterns, with absent or abnormal interaction reading as automation. And it outputs a risk classification (low, medium, high) rather than a hard verdict, the same proportional-response philosophy as the bot score. Rupesh Chokshi, SVP and GM of application security, sold it as a business enabler more than a security control, which tells you the buyer Akamai had in mind was the revenue side of the house, not just the security team.

Content Protector is also a direct response to a shift in who is doing the scraping. The 2024-2026 surge in demand for training data and the bots that feed retrieval systems gave Akamai a market for a scraper-specific product that the 2016 catalog never anticipated. Brand Protector, launched in the same period, points the impersonation-detection machinery at phishing sites and fake storefronts rather than at traffic hitting the customer’s own origin. The pattern across all of them is consistent. Build a rich signal-collection and scoring core once, then aim it at successive problems: known bots, unknown bots, credential stuffing, human account abuse, scraping, brand impersonation. Each product is a new lens on the same telemetry.

*The dated spine of the product line. The two orange marks are the inflection points: the 2016 acquisition that made it behavioral, and the 2024 expansion into scraping and full-lifecycle account risk.*

Where the line sits in 2026

A decade on, the thing that started as a 1,300-entry signature catalog is a scoring system fed by protocol fingerprints, a per-tenant obfuscated JavaScript sensor, a mobile SDK, cross-network reputation, and behavioral baselines for both bots and human account abuse. The Cyberfend acquisition in December 2016 is the hinge the whole story turns on, not because it was large (it was small and the price was never disclosed) but because it committed Akamai to client-side behavioral collection. Everything downstream (the sensor_data POST, the _abck handshake, the obfuscation arms race, Account Protector, Content Protector) is a consequence of deciding that the edge alone could not see enough and the page had to report on itself.

The current state is best understood as a deliberate stalemate by design. Akamai cannot make the sensor impossible to forge; a script that runs in the user’s browser is, in principle, readable by anyone who controls that browser. So the defense is not secrecy but cost and decay. Per-tenant scripts, rotating seeds, payload encoding tied to session state, and dynamic obfuscation all aim at the same target: make a working forgery expensive to build and short-lived once built, so the economics favor the defender even though the cryptography does not. The public 2026 write-ups that call the deobfuscator a trap are not wrong, and they are agreeing with Akamai’s own stated rationale from the other side of the wire.

For anyone reading this to understand a system rather than to beat it, the useful takeaway is concrete. When you see _abck, bm_sz, and a sensor_data POST on a site in 2026, you are looking at the direct descendant of a Santa Clara startup’s credential-fraud models, ported to the edge, generalized into a score, and wrapped in obfuscation whose only job is to make sure the work of reading it never stays done. The cookie is long and looks like noise. Its history is not.

Sources & further reading

Akamai (2016), Akamai Revolutionizes Bot Management — the February 17, 2016 launch announcement, with the 1,300-signature directory and the “block them or suffer in silence” positioning.
Akamai (2016), Akamai Acquires Cyberfend — the December 18, 2016 acquisition press release naming the Santa Clara startup and its credential-abuse focus.
The Register (2016), Akamai buys bot-sniffing startup Cyberfend — contemporaneous trade coverage of the all-cash deal.
Y Combinator (n.d.), CyberFend company profile — background on Cyberfend, BotFender, and founders Sreenath Kurupati and Sridhar Machiroutu.
Akamai (2017), Akamai Combats Credential Stuffing with Introduction of Bot Manager Premier — the October 10, 2017 Premier launch and the Ponemon credential-stuffing figures.
Akamai Developer (2018), Product Deep Dive: Mobile Protection Module for Bot Manager Premier — how the BMP mobile SDK collects device and behavioral telemetry inside native apps.
Akamai (2021), Akamai Enables Organizations to Fight Fraud and Reduce Friction at the Edge with Account Protector — the June 15, 2021 Account Protector launch and its three-layer detection model.
Akamai (2024), Akamai Account Protector Adds New Capabilities to Power the Fight Against Fraud and Abuse — the October 29, 2024 lifecycle expansion with the Account Update, Password Change, and Payment detections.
Akamai (2024), Akamai Announces Content Protector to Stop Scraping Attacks — the February 6, 2024 scraping-specific product and its protocol/application/interaction detection stack.
Akamai (2026), Bot Manager product page — the current description of the Bot Score, response postures, and dynamic obfuscation of code and telemetry.
Scrappey (2026), How Akamai Bot Manager detects bots and scrapers — a 2026 third-party overview of the four scoring inputs and the sensor’s signal collection (treat technical specifics as inferred from observed traffic).
dev.to / xkiian (2026), Bypassing Akamai v3 sensor_data with TLS in 2026 — why the deobfuscator is a trap — a researcher write-up on per-tenant scripts and rotating obfuscation, cited here for the rotation argument, not for any bypass.