Cloudflare announced a new dashboard within the Account Abuse Protection (AAP) service, enabling fraud prevention teams to investigate account abuse by linking login and account creation events to a historical record of behavior, network, and device activity. The dashboard is initially available to customers in the Early Access program.
The move comes in response to the growing use of artificial intelligence by fraudsters to imitate identities and bypass traditional identity checks. Cloudflare believes that passing a password, biometric check, or liveness test proves what happened at a particular moment, but is not sufficient on its own to determine an account’s trustworthiness.
From a Momentary Check to a Continuous Behavioral Picture
AAP uses an identifier selected by the customer from the login or account creation flow, such as an email address, username, or phone number. Cloudflare transforms this value into an encrypted Hashed User ID specific to each domain, so that it represents the account within the service without exposing the original value.
With each login or account creation, the service adds the event and the network and device signals that Cloudflare observes at the edge. Over time, a record is built showing the account’s usual behavior, helping analysts distinguish deviations rather than treating every request as a separate incident.
The Investigation Path from the Overview to the Account
Cloudflare designed the dashboard as an investigative path that begins at the user-group level and then moves to individual accounts. Teams can review the total number of login and registration attempts, the number of accounts that generated these events, and unique IP addresses and devices, along with distributions by country and internet service provider or autonomous system number (ASN).
In a credential stuffing attack scenario, the dashboard displays indicators such as failed login attempts and matches for leaked credentials. The example included in the material shows approximately 2.4 thousand events that resulted in a match for a leaked username or password, compared with 11.7 thousand events whose credentials were classified as clean. Cloudflare cautions that this result guides the investigation and does not prove that all affected accounts were compromised.
Analysts can then narrow the scope using filters, such as selecting accounts that recorded at least three failed login attempts, three leaked-credential matches, and appeared from at least five unique IP addresses. They can then examine the selected accounts using the Hashed User ID, compare prior and subsequent events, and identify new devices or locations.
What Changes Practically for Security Teams?
The individual-account view displays the login success rate, leaked-credential matches, and the networks, locations, and devices most associated with the account. It also includes an event log with the timestamp, Ray ID, and any mitigation action applied, allowing the event to be linked to additional information in Security Events.
If the investigation confirms that the account was compromised, the team can begin its established recovery procedures. Hashed User ID can also be used in a WAF rule to enforce a challenge or block future requests associated with it.
Access Controls and Limitations
Cloudflare provides two new roles for controlling permissions: Account Abuse Protection for access to the dashboard, and Account Abuse Protection PII for access to additional personally identifiable information, such as email addresses. The latter role is also used to create or update Logpush jobs that include personal data.
This structure reinforces the principle of least privilege, but does not eliminate the need to interpret indicators carefully; a leaked-credential match or an account appearing from multiple networks is not, by itself, conclusive evidence of compromise. Current availability is also limited to Early Access customers, while Cloudflare indicates that interested Bot Management Enterprise customers can apply for these capabilities.