Audit Log
What this screen is for
The Audit Log is your tenant's record of what happened: cryptographic operations performed with your keys, administrative changes to your tenant, and access events such as sign-ins. Events are signed when they are recorded, so tampering can be detected, and nothing on this screen changes or removes them.
Use it to answer who did what, to which key or object, when, and with what outcome. Operations that failed or were refused are recorded too, with their outcome.
Some administrative actions a platform administrator takes on your tenant are recorded on the platform side and do not appear in this trail.
What must exist first
Tenant administrators and key managers open this screen from their tenant's navigation. It is offered to SIMPLE and STANDARD tenants alike.
- The permission to read at least one audit trail, which is what shows this screen. Cryptographic operations, administrative changes and access events are each a separate permission, and one further permission reads all three. Each tab on the screen is a trail you are permitted to read; a trail you are not permitted to read has no tab.
- The permission to trace a request by its correlation identifier also puts this screen in your navigation, but on its own it opens no trail.
- The permission to read audit integrity, for the integrity status shown beside the title.
The built-in key manager role carries no audit permission, so a key manager needs a role that adds one. The tenant administrator role holds them all.
Decisions you make here
Choosing what to look at
All shows every trail you may read together, and Crypto, Admin and Access show one each. Narrow the list with the search box, a Date range and an outcome; on Crypto you can also filter by operation, and on Admin by action and entity type. Each filter offers only the values the trail actually records.
Events are listed newest first, and Load older fetches the next page.
The figures above the list summarize the cryptographic and administrative trails over the date range you set: Total Events, the events of Today or, once you set a range, In selected window, and Failed Operations. With no date range, Failed Operations covers the last 30 days. It counts failed operations and refused cryptographic operations, but selecting it narrows the list to failed outcomes only; use the outcome filter to list the refused ones.
Reading an event
Selecting an event opens its details: when it happened, the actor and user behind it, and its outcome. Depending on the trail, they add the key, algorithm and material version a cryptographic operation used; the reason an operator gave and what an administrative change changed; or the principal, address and endpoint of an access event. An event that did not succeed also shows its error code.
The correlation identifier in the details is shared by the events one request produced.
Exporting
With the same permissions that show the list, Export CSV downloads the events that match the tab, filters and date range on screen, as one CSV file. An export needs a date range of at most 365 days, so set one before you export.
The file has the same fixed set of columns whichever tab you export from, and it does not include the details column. An export stops at a row limit set for your installation; when it does, the console warns that the file is not the whole result, so narrow the date range or the filters and export in parts.
Checking integrity
With the permission to read audit integrity, the status beside the title says whether your tenant's audit records were last verified intact, which trails that verification covers, and whether older events were removed by the retention policy. A platform administrator starts the verification; this screen only shows its result.
How it relates to other screens
Operations are attributed to the cryptographic actor that performed them:
A key's lifecycle decisions, including the reason given for a suspension or a revocation, are recorded here, and each key's own history is also available from its detail:
An operation refused because no capability grant authorized it, or because a constraint policy condition was not met, is recorded here with its outcome:
An internal use case's own administrative history is also shown on its Activity tab: