Audits

The User Audit page (route /user-audits) searches a single user’s audit records to diagnose problems or assess the damage from a breach.

Purpose

Audit records are used to diagnose problems a user may be having, or the security damage caused by a breach. The User Audit page centres on one person: you search for a user by email, and the page assembles everything relevant to them: the applications and resources they can access, their authentication preferences, their sessions, and their audit log entries. It is also where you can update a user’s multi-factor authentication information.

Why use it

Diagnose why a user cannot access a resource: review what they are authorised for and what the audit log records.
Investigate a breach: see what a user could reach and when they were active.
Verify the access a user currently has across applications and resources.
Review authentication preferences and reset multi-factor authentication enrollment or deadlines.

When to use it

When a user reports a problem and you need the record of what happened (see Audit and diagnostics).
During an incident response, to reconstruct a user’s access and activity.
When onboarding a user’s replacement, to see what access needs to be replicated.
After a security review, to reset a user’s multi-factor authentication preferences.

What the Access audit records

The Access audit records actions: who did what, to which resource, when, from where, and whether it was allowed. Each record carries the target resource name and type, the resource id, the action, the source address, the token and the session. When the session passes through a connector, the record identifies the connector as the source.

This is the audit for desktop and Secure Shell sessions. A desktop launched from Profile does not have its own OpenID Connect client, so it does not appear in the Authentication audit. Profile asks the Applications service for a client configuration, Applications mints a token scoped to that one resource, and the connector records the session here when the connection closes. The same pattern applies to Secure Shell, database and file share resources.

Authentication audit and Access audit

Use the Authentication audit for identity: who signed in, how they proved the identity, and whether the sign-in succeeded. Use the Access audit for resource activity: who reached which resource, and whether it was allowed. The two records share the token and session identifiers, so you can move from a connection back to the sign-in that created it.

Filter on the target resource type to isolate desktop, Secure Shell, database or file share activity.
Filter on the connector to get everything behind one connector.
Use the token and session identifiers to correlate a connection with the Authentication audit.

Both audits are available through the API: /v1/audits for access records and /v1/auth_audits for authentication records. Audit destinations can stream both to a SIEM.

Prerequisite: permission to view audits (an owner or administrator role).

How to use it

Open Access > Audits from the left navigation.
Type a user’s User Email into the search field.

Select SEARCH. The page loads the user’s record: their name and email, a VIEW PERMISSION GRAPH button, and a set of sections.

Reading the results

Application Access Overview lists each application the user can access and the role they hold. The table shows one column per application.

Resource Access Overview lists the resources the user can reach and at what level.
Permission Graph shows a visual map of the user’s permissions.
Authentication Preferences shows multi-factor authentication state and the enrollment deadline, with RESET MFA PREFERENCES, RESET (deadline), and UPDATE RESULTS actions.
Sessions Audit lists the user’s sessions.
Logs shows the raw audit log entries for the user, with search and pagination.

Updating multi-factor authentication

In the Authentication Preferences section you can reset a user’s enrolled multi-factor authentication methods, reset their enrollment deadline, or update the shown results after changes. These are immediate, so confirm the user understands they will need to re-enrol at next sign-in.

Fields and controls reference

Control	Purpose	Required	Default	Valid values	Notes
User Email	The user to search for	Yes	n/a	A user’s email address	Autocomplete as you type
SEARCH	Runs the search	n/a	n/a	n/a
VIEW PERMISSION GRAPH	Opens the permission graph view	n/a	n/a	n/a
RESET MFA PREFERENCES	Clears the user’s multi-factor authentication enrollment	n/a	n/a	n/a	The user re-enrols at next sign-in
Enrollment deadline	The date by which the user must enrol	No	n/a	A date	Reset or update from this section
UPDATE RESULTS	Refreshes the displayed sections	n/a	n/a	n/a

Dialogs and popups

Confirmation dialogs: resetting multi-factor authentication preferences confirms before acting.

Configuration versus diagnostics versus confirmation

Configuration: updating a user’s multi-factor authentication preferences and enrollment deadline.
Diagnostics: the access overviews, permission graph, sessions audit, and logs are read-only records of the user’s state and activity.
Confirmation: resetting multi-factor authentication is immediate and affects the user’s next sign-in. Confirm before applying.

Pagination and async behaviour

The application, resource, sessions, and log tables page at 25 rows per page.
Searching a user with a large audit history can take some seconds to assemble. After resetting multi-factor authentication or updating the deadline, select UPDATE RESULTS or reload to confirm.

Troubleshooting

No results: confirm the email is spelled correctly and the user exists in the organisation (see Users).
The user cannot sign in: check the authentication audit for sign-in failures, then review the sessions audit here for stale sessions. Revoke sessions from the Users page if needed.
A permission is missing: review the application and resource access overviews, then adjust on Application permissions or Resource permissions.
Multi-factor authentication is not working: reset the user’s preferences here and ask them to re-enrol.