Cloudflare opens an account-abuse dashboard for fraud teams

Cloudflare has opened a fraud dashboard for Account Abuse Protection, the security product it built to judge whether a login or signup looks like the work of a real person rather than an attacker holding stolen credentials.

From a single check to a pattern of behaviour

In a blog post dated 2 October 2026, Cloudflare argued that point-in-time identity checks are no longer enough: passwords, biometrics and liveness tests capture a moment, and widely available AI now lets fraudsters pair leaked credentials with synthetic media to imitate a legitimate user convincingly. One convincing interaction can be faked, the company said, but a consistent pattern of legitimate behaviour is much harder to manufacture. Its answer is a stateful trust model that asks not only whether someone can pass a check now, but whether the activity fits what is already known about that account.

A hashed identifier, not a raw one

Account Abuse Protection works from an identifier taken from a customer's existing login or signup flow — an email address, a username or a phone number. Cloudflare hashes that value to create a per-domain Hashed User ID, so the account is anchored to activity without the raw identifier being stored. Each login or signup adds the event plus the network and device signals observed at Cloudflare's edge, and the accumulated history becomes the baseline against which deviations stand out.

An investigative funnel

The new dashboard is built as a funnel. Fraud teams start with a population overview showing total login and signup volume, the number of accounts behind those events, and the unique IP addresses and devices seen across them, with country and ASN breakdowns for context. Filters then narrow the field — for example, accounts with at least three failed logins, at least three leaked-credential matches and activity from at least five unique IP addresses — before an analyst opens a single account and reconstructs what happened from a table of events, each carrying a timestamp, a Ray ID and any mitigation applied.

Cloudflare illustrates the flow with a credential-stuffing investigation in which roughly 2,400 events returned a leaked username or password against 11,700 classed as clean. It is careful to call that pattern a lead rather than proof: the point is to define the likely scope of a campaign, prioritise which accounts need review and decide how to respond. Where the evidence justifies it, the Hashed User ID can be dropped into a WAF rule to challenge or block later requests tied to that account.

Two new roles, and an Early Access gate

The launch adds two access levels. The Account Abuse Protection role governs the dashboard itself, while the Account Abuse Protection PII role governs additional account-level personal data such as email and is also required to create or update Logpush jobs containing PII. Cloudflare recommends assigning both on a need-to-know basis to keep the dashboard and data-export workflows under least-privilege access. The dashboard is available first to Account Abuse Protection Early Access customers, and Bot Management Enterprise customers can apply through the same form.

Our opinion

The interesting move here is philosophical rather than technical: Cloudflare is arguing that identity is a process, not a checkpoint, and quietly retiring the idea that passing a login screen means the account behind it can be trusted. Framing the dashboard as a funnel is the right shape, because the hard part of account abuse was never spotting a single odd login — it was working out how far a campaign spread without drowning in individual accounts. The privacy design is the part to watch: hashing the identifier per domain keeps Cloudflare out of the raw data, but the PII role and the Logpush caveat show how easily convenience reintroduces the exposure the hashing was meant to avoid.