Lidar threat detection in the console

Audit tells you what happened. It does not group a burst of failures, a hop across continents, or a pile of MFA prompts into one finding you can triage. Lidar correlates authentication activity per environment and surfaces Signals operators can work next to the SIEM dashboards they already have.

This is the longer note behind the August 8 changelog entry.

How it works

Lidar is environment-scoped. Monitors define which detectors run. Auth events are classified, grouped (by IP, subject, or environment), and turned into findings when a detector marks the group suspicious. Findings are deduplicated into the threats store and shown as Signals.

Hosted sign-in and sign-up emit richer auth-request signals so those detectors have something to correlate.

Seeded monitors include (among others):

• Brute force
• Impossible travel
• Bots
• MFA fatigue
• Breached password, rate-limit spikes, unrecognized device, stale-account reactivation, repeat signup, credential stuffing, privilege change

Each monitor has a query that starts with detection:<id> and optional threshold tokens (window:, attempts:, and similar). Operators enable or disable monitors and edit query and severity.

The console module is labeled Lidar; the route is /dashboard/security. After the feature is approved, the default tab is Signals. Monitors is the detector catalog. SIEM-oriented views (Scan Logs, Scan Runs) show analysis-run history. Until access is approved, the page is a request landing, not a tab.

Lidar is native detection inside Authdog. Streaming the same event trail to Datadog, Splunk, or Sentinel is a SIEM channel, not a second Lidar.

Set it up

Lidar is sales-gated (lidar). If you see the locked landing, request access from that page (see plan-based feature access).

After approval, in the Authdog console:

1. Open Lidar.
2. On Monitors, enable the detectors you care about and tune the query.
3. Open Signals, set the top-bar time range, and filter by severity, detection type, origin, or user.
4. Use Scan Logs / Scan Runs when you need the analysis-run history next to an external SIEM.

Operator walkthrough: Lidar in the console. Model: Lidar concepts.

Trust boundaries

A Signal is a detector verdict on correlated auth activity. It is not an AuthZEN deny and not a session revoke by itself. Use Signals to investigate; use policies, bot protection, and account controls to block.

Findings are environment-scoped. Do not assume a dev Signal exists in prod.

Lidar complements bot protection and rate-limit policy. A captcha add-on filters the front door; Lidar correlates what still landed.

Do not treat a missing Signal as proof the action never happened. Dedup can fold repeats into one finding; older events keep the records they were written with.

Try it

Enable a brute-force or MFA-fatigue monitor in a non-production environment, generate traffic you expect to fire, and find the Signal. Start from Lidar concepts. The original release note is in the changelog.