Dashboard

What does an identity and access analytics dashboard show in Metabase?

An identity and access analytics dashboard shows the health of your login perimeter: failure rates and spray-shaped spikes, MFA adoption by factor, privileged actions, and deprovisioning lag for departed users. It's built from authentication rollups synced from tools such as Okta, Auth0, and CrowdStrike.

For: IAM engineers, security teams, and compliance leads. Grain: daily authentication rollups per app, outcome, and factor, plus one row per user.

What does an identity and access analytics dashboard look like?

Here's the layout this guide builds, at the grain of a daily authentication rollup: who holds accounts and how they authenticate, then the shape of login success and failure, then the privileged actions and the offboarding lag that follow. Read it daily for spray-shaped spikes, and monthly for the access review.

Identity and access dashboard in Metabase showing account types, MFA adoption, login failures, and privileged activity.
An example identity and access analytics dashboard in Metabase, built from Okta and Auth0 data. Figures are illustrative.

Which cards belong on an identity and access analytics dashboard?

  • Login success / failure rate per day (line)
  • Failed-login spikes by source — spray detection (bar)
  • MFA adoption by factor type (bar)
  • Sign-in volume by application (bar)
  • Admin and privileged actions per week by actor (table)
  • Deprovisioning lag — departed users with active accounts (table)

What data does the dashboard need?

  • auth_events_rollups — daily counts per app, outcome, and factor type.
  • users — status, mfa_enrolled, last login, and account type (human vs. service).
  • admin_events — privileged actions with actor and timestamp.

How do you build it?

  1. Roll up authentication events daily by app, outcome, and factor — sync the rollups, not the raw system-log firehose.
  2. Flag service accounts in the user table so MFA and login cards can filter to humans.
  3. Join users to the HR termination feed to compute deprovisioning lag — identity data alone can't tell you who should be gone.
  4. Build the failure-rate trend and MFA adoption cards first; add spray detection and privileged-action views next.

Example card SQL

Daily failed-login rate with 7-day moving averagePostgreSQL
WITH daily AS (
  SELECT
    event_date,
    COALESCE(SUM(event_count) FILTER (WHERE outcome = 'failure'), 0)
      AS failures,
    SUM(event_count) AS attempts
  FROM auth_events_rollups
  WHERE event_date >= CURRENT_DATE - INTERVAL '90 days'
  GROUP BY event_date
)
SELECT
  event_date,
  ROUND(100.0 * failures / NULLIF(attempts, 0), 2) AS failed_login_pct,
  ROUND(
    100.0 * SUM(failures) OVER w / NULLIF(SUM(attempts) OVER w, 0), 2
  ) AS failed_login_pct_7d_avg
FROM daily
WINDOW w AS (
  ORDER BY event_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
)
ORDER BY event_date;

Metrics

Integrations

Dashboards

FAQ

What is an identity and access analytics dashboard?
It's the trend view over your identity provider: login success and failure rates per day, MFA adoption by factor type, privileged-action volume, and how long departed users keep working accounts. The admin consoles in Okta and Auth0 answer "what happened to this user" — this dashboard answers "is the population getting safer," which is the question a security analytics program and every auditor actually asks.
Should you sync raw identity system logs into the warehouse?
No — the raw system log is an event firehose (every sign-in, token refresh, and API call) that's expensive to store and slow to scan. Build auth_events_rollups instead: daily counts per app, outcome, and factor type. That's a few hundred rows a day, answers every card on this dashboard, and keeps forensic detail where it belongs — in the identity provider's own log search. Metabase reads the rollups from your SQL warehouse, not from the identity provider directly.
How do you tell user friction from attack signal in failed logins?
Segment by source and shape. Broad, shallow failures — many accounts, few attempts each, often from one ASN or IP range — look like password spraying; deep failures on a handful of accounts right after a password-policy change look like friction. The spike card slices failed-login rate by source so the two patterns separate visually, and confirmed spray windows are worth annotating and cross-checking against the incident response trends dashboard to see whether detections fired.
How do you measure deprovisioning lag?
Join the identity provider's user table to the HR system's termination dates — the joiner-mover-leaver feed. Deprovisioning lag is deactivated_at − termination_date per departed user, and the card lists anyone past termination with an active account, which auditors treat as a finding. This is the one card on the dashboard that cannot be built from identity data alone: without the HR join you only know who was deactivated, not who should have been.
Why exclude service accounts from MFA adoption?
Service accounts authenticate with keys and tokens, not interactive MFA challenges, so counting them drags MFA adoption rate down without describing any real gap. Filter the denominator to active human users, and track service accounts on their own card — count, ownership, and last-credential-rotation age — since unowned service accounts are their own risk. A 94% adoption number that includes 200 service accounts is really a 99% human number hiding an unmanaged-automation problem, and the compliance posture dashboard needs the honest human figure.