Most Akamai security deployments stall in the same place. App & API Protector is in alert, Bot Manager is in monitor, the contract renews every year, and nobody wants to be the person who switched on blocking and took down checkout. The protection exists on the invoice and in the dashboard, but not in front of the application.
Getting from there to enforcement is less about any single setting than about the order in which things are done, and about having evidence for each step before taking the next. This is the sequence we follow as Akamai security architects.
Start with the security configuration itself
A security configuration is a set of policies, each matched to hostnames and paths, and the first job is usually to find out why there are as many of them as there are. Policies split for a reason that no longer applies, exceptions written to silence one alert during an incident and never revisited, custom rules that duplicate what a managed rule now does: each one is either justified or removed before anything moves to deny. A configuration nobody can explain is not one anybody will agree to enforce.
Move App & API Protector one attack group at a time
Adaptive Security Engine scores requests against the managed rules and keeps them current, which removes the most tedious part of running a WAF. It does not decide which false positives are acceptable. That still takes someone reading the alerts.
Take them from Web Security Analytics or from your SIEM, trace each recurring one to the exact parameter, header or path that triggers it, and write the exception at that scope. A rule disabled for the whole site to stop one form field from triggering it is the most common weakness we find in inherited configurations. Once an attack group’s alerts are understood, it goes to deny, it is watched for a while, and only then does the next one follow. New rule-set versions are run in evaluation alongside the active policy before they are accepted.
Around the managed rules sit the controls tuned to the application rather than to the internet in general: rate policies on login, search, password reset and pricing APIs; client lists for partners, monitors and your own scanners; geographic controls where the business case is real rather than reflexive; API definitions so requests are checked against what the API actually accepts; and the penalty box for clients that keep trying after the first deny.
Teams still on Kona Site Defender usually gain the most from moving to App & API Protector, mainly because Adaptive Security Engine keeps the rules current without someone maintaining them by hand, the part most Kona deployments quietly stopped doing. The migration is safest when the new policy runs in evaluation against live traffic first and only the exceptions that still have a reason to exist are carried over.
Settle the bots that have a name
Bot traffic is not one problem. Search engines, monitoring services and social previews should simply pass, and Bot Manager’s directory of known bots covers most of them. Partners, aggregators, payment callbacks and your own uptime checks belong in custom bot categories with an explicit action; anything left unclassified will look like an attack at the worst possible moment. Requests claiming to be a search engine crawler from outside that search engine’s network are impersonators and can be denied outright. That is usually the first action that blocks anything, and about as safe as blocking gets.
Protect endpoints, not the site
The automation that matters concentrates where a transaction happens: credential stuffing on login, card testing on checkout, inventory hoarding and scalping on limited releases, price scraping on search. Define these as protected endpoints so requests to them get the full set of detections, including client reputation, browser impersonation and HTTP anomaly detection, and the active detection that relies on the script Bot Manager injects into protected pages. Native mobile apps cannot run that script and need the mobile SDK.
Then choose the response per endpoint, because the right answer differs. A challenge suits a login page, where a person can solve it once. Tarpit and slow cost an attacker time on checkout without showing where the threshold is. Serving alternate content works better for scrapers, which otherwise learn they have been detected and change tactics within hours. Deny is for what is unambiguous. Conditional actions let the response tighten as the bot score rises instead of switching from nothing to block at one threshold.
Credential stuffing, the case that brings most teams here
Credential stuffing relies on password reuse. Lists of addresses and passwords leaked from other services circulate freely, and the attacker guesses nothing: every pair is tried against your login and the ones that work are kept. The result shows up as drained loyalty points and stored value, login infrastructure loaded by traffic no customer generated, and a wave of support calls from people locked out of their own accounts.
The old version was easy to stop, with many attempts from one IP address in a short window and a per-IP rate limit to match. The current version is built to avoid exactly that. Traffic runs through residential proxy networks, so each attempt appears to come from a different home connection; the tooling uses headless browsers or libraries that imitate a real browser’s fingerprint; and the pace is kept under the usual thresholds. Request by request it looks almost normal. It gives itself away only when signals are combined: a fingerprint that does not match the browser it claims to be, headers in an order no real browser sends, a detection script that never runs or runs somewhere nothing human is present, and a login failure rate far above that of real users.
Those are the signals Bot Manager scores on a protected login endpoint, before the request reaches the application. A challenge is usually the right response there, tightening to deny as the score rises. Rate policies from App & API Protector still belong on login and password reset: they no longer stop a distributed attack on their own, but they limit the damage when something slips past detection.
Know what Bot Manager does not do
Bot Manager decides whether a request comes from automation. It does not decide whether a human logging in with the correct password is the account’s owner. When valid pairs are tried by hand, or by people paid to do it, the problem has left bot territory. Account Protector scores each login against the account’s own history, multi-factor authentication makes a password alone insufficient for sensitive actions, the application can step up verification when the context is unusual, and checking new passwords against known breach lists shrinks the very supply these attacks feed on. Configuring these to fit together, rather than expecting Bot Manager to cover all of it, avoids disappointment with a product that is working as designed.
Measure every step
Each change should come with the question it is meant to answer. After challenging automation on login, did failed attempts per hour fall while successful logins stayed where they were? After serving alternate content on search, did scraping volume drop or simply move to another path? For credential stuffing specifically, watch the ratio of successful to failed logins per hour and per source, the number of distinct accounts tried from one class of traffic, and password reset requests in the hours after a spike in failures. Bot Manager’s reporting answers part of this; the rest needs the application’s own numbers, which is why Akamai’s security events belong in the same SIEM as the application logs they affect.
Make every change reversible
Every change follows the same path: inventory and a baseline of normal traffic first, the change written in Terraform and reviewed, activated on the staging network and tested there, then promoted to production with the previous version ready to restore in minutes. Security events stream into the SIEM so the evidence sits where the security team already works, and a weekly tuning review continues until the policy is stable. A policy that can be put back to yesterday’s version in minutes is one that people are willing to tighten.
We do this work on Akamai, and the equivalent on Cloudflare, CloudFront and Fastly, as part of our CDN management and edge security service.