Monosign audit, reporting and troubleshooting
What changed
Every content update is versioned. Select a version to compare it with the one before.
Version 3 → 4
Update5 lessons updated
Content update. Enrolled learners were notified.
Every product action writes an audit row. Reports → `Audit` lists these rows newest first, with filters on the object, the actor, the audit type, the application and a time frame. The same list appears on a user's page as the `Audit` tab.
::shot aud-audit-list
### What you can do on the page
- **`Details`** opens one row with its data and its `Correlation Id`, the value that ties together the rows of one request.
- **`Schedule`** mails an audit digest: a list of audit rows of the types you pick, sent instantly, at a threshold or on a time basis.
- The list has **no file export**. When someone needs audit rows as a file, build a Report Studio report on the `Audit Events` data source. The next module covers that.
### Permissions for a support role
Opening the page and reading the rows are two different permissions. The page route needs `System.Management.Report.Audit`. The list needs `System.Management.User.AuditList`, and since v2026.10 so does `Details` on a single row. Up to v2026.09 any signed-in Management user could open a row by its id. After an upgrade, a custom support role that only read single rows gets HTTP 403 until you add `System.Management.User.AuditList`. Do not look for an API to list audits: the API reads one row by id or writes rows for external systems.
### Retention
Audit rows stay until the `Audit` rule under System → `Data Retention` removes them. Each rule has `Enable` and `Remove older than N days`. Deletion is permanent: nothing is archived first, and nothing is exported for you.
So agree the order of work with the customer. If compliance must keep evidence longer than the rule's period, set up the export first, for example a scheduled Report Studio report on `Audit Events`, and only then enable the rule.
::diagram aud-retention-order
> Tip: Write down the retention period and the export schedule in the same handover document. An auditor will ask for both.
An assignment list shows who has access **today**. Sessions and sign-in audits show who **signed in**. Neither answers the classic audit question: *who held access to this application on a given past date?* That is the job of Dashboard → `Timeline`, the page titled `Access Timeline`.
::diagram aud-three-questions
The timeline records every grant and revoke of roles, permissions, groups, applications and resources, and profile value changes, as events. Because it knows when each access started and ended, it can show the same data in several views:
| View | Use it for |
| --- | --- |
| `Events` | The raw list, filtered by date range, user, source, application or event type |
| `Timeline` | Access as intervals from granted to revoked |
| `Snapshot` | The state of access at one point in time |
| `Compare` | What was added and removed between two dates |
| `Unused` | Application access nobody signs in with |
| `Pinned` | Events you pinned with an investigation note |
`Export CSV` writes the current view to a file, up to 100,000 rows.
::shot aud-access-timeline
### Limits to tell the auditor
- The page was introduced in v2026.07. `Build history` rebuilds events from the current data, so earlier access can be shown, but rebuilt rows and events written before v2026.09 show `System` as the actor.
- **Group removals made before v2026.09 were not recorded and cannot be rebuilt.** `Build history` does not bring them back. If the evidence you need is such a removal, say so and look for other evidence, such as the audit log.
- Only application sign-ins count for `Unused`. Role and permission usage is not tracked.
- No data retention rule removes timeline events, so a gap is never the result of a purge.
- Anyone who may open the page sees the whole tenant.
> Tip: For a point-in-time question, start with `Snapshot` on the date, then use `Compare` against today to show what changed since.
Reports → `Report Studio` is where you build your own reports. A report reads one **data source**: one of the predefined sources, such as `Audit Events`, or a data source the customer composed under `Custom Data Sources`. You cannot type SQL, and reports are not available through the public API.
::shot aud-report-studio
### Two kinds of report
- **`Report Builder`**: one table with columns, filters, grouping, aggregates and sorting, shown as a `Table`, `Bar`, `Line` or `Pie`.
- **`Composite Report`**: a document made of blocks, such as headings, text, tables, charts and a KPI digest. This suits a management summary, for example MFA coverage next to risky users.
System templates are ready to run and cannot be edited.
### Running
A run produces `CSV`, `Excel`, `PDF` or `HTML`. Runs are queued and rendered in the background, and the files appear under `Run History`, a button on the `Report Studio` toolbar. Without the permission to manage all reports you see only your own runs. Files are not kept forever: expired artifacts are removed.
### Personal data is masked by default
Columns that hold personal data are masked. The builder has a toggle `Unmasked PII`, and it is saved with the report. That does not mean every run is unmasked:
- Whether a run is unmasked is decided **when the run is queued, from the permission of the person who runs it**.
- For a user without the unmasked-export permission the saved toggle is ignored, and their run is masked.
- Every unmasked run writes the audit `REPORT_EXPORT_UNMASKED`.
So the same report can show full names to its author and masked names to a junior analyst. This is the intended behaviour, not a fault. Give the permission to the few people who need it, and review that audit type.
::diagram aud-unmasked-run
> Tip: Share a report with roles, not with individuals, and keep the unmasked permission out of those roles unless the report needs it.
A manager who wants the same summary every Monday should not have to sign in to Management, and nobody should export it by hand. A report schedule runs a Report Studio report on a calendar and delivers the result. The sidebar has no item for schedules: open the report in `Report Studio` and choose `Schedule (admin)`, or use `More` → `Schedules` on the toolbar.
::shot aud-report-schedules
### What a schedule holds
- **Recurrence**: daily, weekly or monthly, at a time in the schedule's own time zone. There is no raw cron expression.
- **Format**: one of the run formats, for example `PDF`.
- **Recipients**: the owner plus additional addresses.
- **Delivery**: `Download link` or `Email attachment`.
- Optionally a **webhook** that is called when the run completes.
### Choosing the delivery
| Delivery | What the recipient gets | Works for |
| --- | --- | --- |
| `Download link` | A link that requires a Management sign-in | People who have an account and the right to the run |
| `Email attachment` | The files in the mail when they total 10 MB or less, otherwise links | Anyone with a mailbox, including an external auditor with no account |
| Webhook | Metadata and authenticated URLs, never the report data | Systems that react to a finished run |
The common mistake is `Download link` for a recipient who has only an email address. That person cannot pass the sign-in and never sees the file. Switch the schedule to `Email attachment`, and keep the report small enough to stay under the limit.
### Subscriptions
A user with access to Report Studio can also `Subscribe` to a report for themselves. A subscription always sends a link, is always masked, and needs an account, so it is not a way to reach outside readers.
### When a schedule stops
A schedule pauses itself after 5 consecutive failures, when its owner is deactivated, or when the report is deleted, and it stores the reason. Check `More` → `Schedules` when someone says the Monday report did not arrive.
> Tip: Give schedules an owner who will stay, such as a service administrator, not the consultant who built them.
When an account may be compromised, three tools matter: the session list, the password, and a live view of what the user is doing. Each has a behaviour you must know before the incident.
### Finding a session
Management → `Sessions` shows `Active Sessions`. Without a user filter, the list shows only sessions that were **started or updated in the last 30 minutes**. A session that is still valid but has been idle longer is not on this page.
The same session is visible from the user's own page: Users → user → `Sessions` → `Active`, because that route filters by the user. So do not conclude that a user has no session until you have looked there. Sessions live in one shared table, so the data center you are connected to makes no difference.
From either place you can close one session, close all sessions of a user in an application, or close them all. Closing writes a logout audit and revokes the session's tokens.
::shot aud-active-sessions
### A password change does not end sessions
A new password, whether the user changed it, an administrator set it or it came from a reset, does **not** end the sessions that were already open. They stay valid until they expire or someone ends them.
For a suspected compromise, do both: change the password **and** end the user's sessions. If you only reset the password, the audit log can keep showing activity from the attacker's session.
::diagram aud-incident-steps
From v2026.10 the password policy has two related switches: `End Active Sessions When Locked After Failed Attempts` (off by default) and `End Active Sessions When an Administrator Locks the Account` (on by default). They concern locks, not password changes.
### Live Tracking
Directory → Users → `Live Tracking` lets you pick one user and watch that user's audit events arrive in real time. Two limits:
- **Nothing is stored by the page.** It shows only events raised while it is open. Past activity is in the audit log.
- **Events raised in another data center never appear.** In a deployment with two data centers, find out which one the user is reaching, and open Management there, before you conclude that nothing is happening.
> Tip: During a support call, start tracking first and then ask the user to repeat the action.