Auth0’s Detection Catalog Ships the Queries and Leaves You the Hard Part

Read the announcements and the pitch is clean: Auth0 just handed SOC teams a repo of ready-to-run detection rules, so you can stop writing credential-stuffing queries from scratch and start hunting. Plug them into Splunk, map them to MITRE, done.

That reading is half right and it will get people hurt. The detection logic in the Customer Detection Catalog is the easy 20% of the problem. The part nobody’s talking about — and the part that actually decides whether this is useful in your tenant — is everything the rules quietly assume you’ve already built.

What’s actually in the box

The catalog delivers what it promises. It’s open source, it’s organised around attack patterns you genuinely care about — credential stuffing, brute force, token and session abuse, anomalous login behaviour — and where it makes sense the rules are tagged to MITRE ATT&CK techniques. That tagging matters more than it sounds. It means a detection engineer can slot these into an existing ATT&CK-aligned coverage matrix and see where the Auth0 blind spots are, instead of treating identity as a separate universe.

And the detections are written against Auth0’s log event types, which is the genuinely valuable thing here. If you’ve ever tried to reverse-engineer what limit_wc versus limit_mu versus fp actually mean, you know the schema is terse to the point of hostile. The meanings below come from Auth0’s own log event type code reference, not the catalog — but a worked example that says “these three codes, correlated this way, is a credential-stuffing signal” is documentation Auth0 should have shipped years ago. The catalog is a better schema reference than the schema reference.

1
2
3
4
5
6
7

s         Successful login
f         Failed login
fp        Failed login (incorrect password)
limit_wc  Blocked account — too many failed attempts (per user)
limit_mu  Blocked IP — suspicious activity (per IP)
pwd_leak  Breached-password login attempt (credential found in a breach corpus)
fsa       Failed silent auth

The queries don’t run on an empty tenant

Here’s where the clean narrative falls apart. Every rule in that repo is a query over logs that are sitting in your SIEM. If you haven’t configured a Log Stream, you have nothing to run them against — and per Auth0’s log retention documentation, tenant logs are kept for a window measured in days to a few weeks depending on your subscription, not the 90-to-365 your incident responders will ask for. That’s exactly why streaming to external storage exists, and it’s the pipeline the brief itself warns you not to assume.

So before any of this is real, you set up streaming. In the dashboard this lives under Monitoring → Streams (Auth0 log streams docs), or do it properly with the Management API so it’s in source control:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

POST https://YOUR_TENANT.auth0.com/api/v2/log-streams
Authorization: Bearer {mgmt_api_token}
Content-Type: application/json
​
{
  "name": "siem-prod",
  "type": "splunk",
  "sink": {
    "splunkDomain": "your-instance.splunkcloud.com",
    "splunkToken": "{hec_token}",
    "splunkPort": "8088",
    "splunkSecure": true
  }
}

The exact type and sink fields are documented per provider; Splunk, Datadog, Sumo, a generic HTTP endpoint, and the AWS EventBridge / Azure Event Grid buses are all supported sink types. Sentinel and Elastic typically land via the HTTP sink or an event bus. Get streaming working and retained first. The rules are worthless draining into a bucket nobody queries.

A rule you paste unmodified is a rule that lies to you

This is the line the “ready to run” framing crosses. These are templates, not detections. The templates don’t know which client_id is a batch job that logs in ten thousand times an hour, or that your mobile connection generates fsa events by design, or that one B2B partner genuinely signs in from four countries before lunch.

So budget for tuning, not deployment:

• Scope by tenant and connection. Filter on your tenant_name and the specific connection or strategy values in play. A credential-stuffing threshold that fits a consumer database login is a false-positive machine against an enterprise SSO connection.
• Allowlist your own noise. Service accounts, CI/CD clients, and known scanners by client_id and IP before you alert, not after the third 3 a.m. page.
• Join on your claims. If you stamp org_id, tenant, or role into custom claims, carry those into the detection so an analyst gets “which customer, which app” instead of a raw user_id.
• Calibrate thresholds to your baseline. Run each rule in count-only mode for two weeks and read the distribution before it ever fires an alert.

What it quietly says

The interesting part isn’t the repo. It’s the admission underneath it: Auth0 is telling you the identity layer is a shared-responsibility boundary now, and detection on your side of that line is your job. That’s the right call — nobody knows your traffic baseline better than you — but don’t mistake the handoff for a safety net. A catalog of queries is not a SOC, it doesn’t cover threats Auth0 doesn’t log, and a detection that fires into a channel nobody watches is theatre.

Take the schema map, build the pipeline, tune the rules against two weeks of your own traffic. Then they’re detections. Until then they’re very good documentation.