Auth activity

In one sentence

The Auth Activity page is a read-only feed of every authentication-related event in your organization — policy changes, passkey step-up confirmations, role changes, password resets — for the moments when an auditor or incident responder needs to ask "what changed, and who did it?"

Three things to remember

It's narrower than the global activity log. Auth Activity only shows the four event types that materially affect how people sign in or prove identity. Day-to-day record activity (NCR submitted, document approved, etc.) belongs elsewhere — see the per-record History tab for that.
Identity is snapshotted at write time. Every entry carries the actor's name and (where relevant) the target's name as they were at the moment of the event. Deleting the user later doesn't erase the trail.
Loading the page is itself logged. The audit-of-audit at Audit Log Access records every load of this page, so nobody can read the auth trail invisibly.

What gets recorded

Four event types appear on the page, each with its own badge:

Event	When it's recorded
Auth policy changed	An admin saved a change to the org's auth policy at Admin → Organization → Auth Policy — sign-in methods, allowed email domains, or the require passkey for approvals toggle
Passkey step-up confirmed	A user completed a passkey step-up confirmation on a sensitive action (approve, close, etc.). Captures the device name of the credential used
Role changed	An admin changed a member's base role (Admin / Standard User) at Admin → Users
Password reset	An admin reset a member's password from Admin → Users

The list is intentionally tight. If an event you'd expect to see isn't on this page (an SSO sign-in, a passkey enrollment, a successful login), it's recorded elsewhere or not yet captured.

The Detail column — what each event carries

Auth policy changed — a compact diff showing what changed:

Methods: [password, passkey] → [password, passkey, microsoft_sso]
Domains: ∅ → [acme.com]
Require passkey: off → on

If the admin enabled require passkey for approvals while some approvers had no enrolled passkey and chose to proceed past the soft warning, the entry carries an additional amber line: "Saved over N approvers without an enrolled passkey: <names>". That's the proceed-anyway breadcrumb the two-tier guard writes when an admin overrides the warning — preserved verbatim for audit reconstruction.

Passkey step-up confirmed — the device name of the credential used: "Confirmed using MacBook Air", "YubiKey 5", "iPhone". The credential itself stays private (only the device label is recorded, not the underlying key material) but the device is identifiable to the user.

Role changed — target name + from-role → to-role, e.g. Sam Adler: standard_user → admin.

Password reset — target name, e.g. Reset for Sam Adler.

When you'd actually open this page

Three typical reasons:

Inspection — a customer or regulator auditor asks for the auth-events trail. Sort by date, screenshot or print.
Incident response — "someone changed our SSO method last weekend". Filter by event type; the diff column tells you exactly what changed and who did it.
Compliance review — quarterly internal review of admin actions. Walk the policy-change events to spot drift from the org's standing rules.

The page shows the most recent 200 events. For deeper history, raise an export request with your account contact.

Who can read this page

Gated on the Access audit admin permission. The default Admin role has it; Standard User doesn't. If you've granted a custom role responsibility for security review, grant Access audit admin and they can open this page without full admin elsewhere.

The same permission gates the related inspection pages: Audit Log Access, Document Downloads, and per-record History via Record History.

What it doesn't capture

Regular sign-ins and sign-outs. Successful login events aren't surfaced here today. If a customer audit wants this level, the underlying database has session activity that can be exported separately.
Passkey enrollment. Adding or removing a passkey on your profile isn't a tracked auth-activity event yet — only the use of one for step-up confirmation is. If this matters for your inspector, raise it; the data is captured at a lower level and can be surfaced.
SSO callbacks and policy-failure rejects. A user who tries to sign in via SSO and gets rejected for being out-of-domain isn't recorded on this page. SSO-callback edge cases are visible in server logs.
Failed step-up attempts. Only successful confirmations are recorded. A user who failed their fingerprint scan three times doesn't appear; only the one that succeeded does.