Point-in-time identity checks — passwords, biometrics, liveness — were once a meaningful barrier because fraudsters had to steal real identity evidence to pass them. AI changed the economics: exposed credentials can now be combined with synthetic media engineered to defeat verification. A passed check captures a moment, not the trustworthiness of the account behind it.
A single convincing interaction can be faked; a consistent pattern of legitimate behavior is far harder to manufacture. That asymmetry is the argument for moving from stateless decisions to a stateful trust model, in which each interaction is reassessed against historical behavioral, network, and device patterns. Cloudflare's Account Abuse Protection (AAP) implements this by building stateful account overviews for login and signup activity.
Customers supply an identifier from their existing flow — email address, username, or phone number — which Cloudflare cryptographically hashes into a per-domain Hashed User ID. The Hashed User ID acts as the account anchor: every login or signup adds an event plus the network and device signals observed at Cloudflare's edge. Accumulated over time, that history defines what normal looks like for an account, which is what makes deviations legible to fraud teams in Security Intelligence, Investigations, Trust & Safety, or Risk & Compliance.
The fraud dashboard introduced today for AAP, available first to Early Access customers, is the workspace for that work. It consolidates account overviews drawn from configured login and signup flows, letting analysts survey the whole user population, spot suspicious trends, and descend from aggregate patterns into individual account investigations.
Investigating a credential stuffing campaign
The dashboard is structured as an investigative funnel. Analysts start with population-level metrics — total login and signup volume, how many accounts generated those events, and the unique IP addresses and devices observed — plus country and ASN breakdowns for geographic and network context.
Typical starting questions at this level include: did login or signup volume change unexpectedly? Are failed logins or leaked credential matches rising? Which accounts have the highest login failure rates? Are events concentrated in specific countries, ASNs, or times of day? Did a signup spike coincide with shared characteristics? Which accounts may have been affected?
The answers establish the campaign's scope, prioritize accounts for manual review, and set up reconstruction of what happened inside specific accounts.
An increase in failed logins sends the team to Leaked credential check results on login events.
In the example shown, roughly 2.4K events yield a leaked username or password result while 11.7K are classified clean. That ratio is a lead, not proof of compromise. The team pivots to the matching accounts: are many of them tied to the same IP addresses or ASNs? Does one account suddenly appear across an unusually high number of IP addresses? These relationships bound the campaign and flag accounts for review. Concentration across IP addresses, ASNs, locations, or devices is visible in the same view.
Filters then narrow the population to the accounts with the most concerning signal combinations. One example: at least three failed logins, at least three leaked credential matches, and observation from at least five unique IP addresses.
From the filtered cohort, analysts pick the Hashed User IDs needing the most urgent attention.
Account-level review follows. Analysts examine login attempts, note new devices or locations, and reconstruct the sequence — comparing early clean events against later suspicious ones to find when the pattern started and whether it was a single event or repeated attempts. Each event carries a Ray ID, Cloudflare's per-request identifier, which can be looked up in Security Events. If compromise is confirmed, the team starts its recovery process and can reference the Hashed User ID in a WAF rule to challenge or block future requests tied to it.
The individual account view adds a further layer: login success rate, leaked credential matches, and the networks, locations, and devices most frequently associated with the account. Behind the summary is the event log, with timestamps, Ray IDs, and any mitigation applied. It answers whether activity was a one-off or a series, whether a login introduced a new country, network, IP, or device, whether behavior changed afterward, what preceded and followed a suspicious event, whether concentrated logins followed shortly after signup, and whether signup and later logins differ in network or device characteristics.
Together these signals indicate whether an account needs recovery, access restrictions, or another handling — a choice left to each customer. Where evidence is sufficient, the Hashed User ID can be used in a WAF rule to challenge or block subsequent requests.
Access control and PII exposure
AAP supplies account-level context while letting customers govern who sees it. Two roles ship with this launch. Account Abuse Protection controls dashboard access. Account Abuse Protection PII controls access to additional account-level PII such as email, and is also required to create or update Logpush jobs containing PII. Cloudflare recommends Customer Administrators assign both on a need-to-know basis, which keeps least privilege in place across both the dashboard and export workflows.
The dashboard is available first to Account Abuse Protection Early Access customers; Bot Management Enterprise customers can sign up for Early Access, and prospective Bot Management Enterprise customers can use the same form to reach the team. Bot detections establish whether activity is automated — AAP adds the account-level overview that helps fraud teams judge whether login and signup activity is consistent with legitimate use, covering human-driven abuse alongside automated abuse.
