Skip to main content


Authentication Cloud creates log events of service interactions. This gives you the possibility to view and analyze your data for potential issues, without the need to contact the customer support team. You can also use the logs to provide data for support, or for audit purposes. You can access the logs on the Management Console under the Logs sidebar item.

Log event latency

Events are registered and processed asynchronously. Because of this, a delay of several minutes can happen between the interaction and its appearance in the log.

The log overview table contains the following data:

  • Date: the date and time of the event.

  • Category: the category of the event. The category can be registration, authentication, or management. If the event cannot be categorized, the category is None.

  • Event: the status and name of the event. The status can be succeeded or failed, and it is indicated with a green or red icon respectively.

  • Channel: the authentication channel used for the event.

  • Initiated by: the type of the actor that initiated the event. This can be user, admin, API, or app.

    • User: the action was initiated by an end-user.
    • Admin: the action, under the Management category, was initiated through the Management Console.
    • API: the action was initiated through a REST API request.
    • App: the action was initiated on a mobile app, such as the Access App.
  • Target user: the username of the target user. If the event does not have a target user, this field is marked as Unknown.

When you click on a log entry, you can access the log details with additional data.

You can search for specific events using a free-text search, or use the filtering options to narrow down the list of events.

Operations with multiple events

Registration, authentication and approval operations include multiple subsequent events that are logged separately. The entire operation is only successful if every event is successful. In some cases, for example, when an operation is aborted, not every event is logged. For more information, see the Logging unfinished operations section.

A registration operation includes the following events:

  1. Registration created
  2. Registration redeemed (only applicable when the channel is app)
  3. Registration verified

An authentication or approval operation includes the following events:

  1. Authentication created
  2. Authentication redeemed (only applicable when the channel is app or push)
  3. Authentication verified

Reaching the push or SMS rate limit includes the following events:

  1. Authentication created with status=failed
  2. SMS or push authentication rate limited

List of log events

The following table shows the events that are logged:

CategoryEventChannelnameEvent summary
RegistrationRegistration createdApp or pushuaf.registration.createdRegistration started
RegistrationRegistration redeemedApp or pushuaf.registration.redeemedRegistration token redeemed
RegistrationRegistration verifiedApp or pushuaf.registration.verifiedRegistration finalized
AuthenticationAuthentication createdApp or pushuaf.authentication.createdApproval started
AuthenticationAuthentication redeemedApp or pushuaf.authentication.redeemedApproval token redeemed
AuthenticationAuthentication verifiedApp or pushuaf.authentication.verifiedApproval finalized
ManagementDe-registration createdApp or pushuaf.deregistration.createdDevice de-registration requested
ManagementDe-registration verifiedApp or pushuaf.deregistration.verifiedDevice de-registered
NoneFacetIDs viewedApp or pushuaf.facet_id.viewedFacet ID requested
AuthenticationPush authentication rate limitedPushuaf.authentication.ratelimitedRate-limited push authentication attempt
ManagementRate limit reset for userPush or SMSuser.ratelimit.deletedUser unblocked
RegistrationRegistration createdFIDO2fido2.registration.createdRegistration started
RegistrationRegistration verifiedFIDO2fido2.registration.verifiedRegistration finalized
AuthenticationAuthentication createdFIDO2fido2.authentication.createdApproval started
AuthenticationAuthentication verifiedFIDO2fido2.authentication.verifiedApproval finalized
RegistrationRegistration createdSMSsms.registration.createdRegistration started
RegistrationRegistration verifiedSMSsms.registration.verifiedSMS registration verified
AuthenticationAuthentication createdSMSsms.authentication.createdApproval started
AuthenticationAuthentication verifiedSMSsms.authentication.verifiedSMS authentication verified
AuthenticationSMS authentication rate limitedSMSsms.authentication.ratelimitedRate-limited SMS authentication attempt
RegistrationRegistration createdRecoveryrecovery_code.createdRegistration started
RegistrationRegistration verifiedRecoveryrecovery_code.verifiedRecovery code verified
ManagementRecovery codes deletedRecovery or emptyrecovery_code.deletedRecovery codes deleted
ManagementUser deletedUnknownuser.deletedUser deleted
ManagementDevice deletedUnknowndevice.deletedDevice deleted
ManagementDevice renamedUnknowndevice.updatedDevice renamed
ManagementLogs exportedUnknownlogs.exportedLogs exported

In some cases, the Event column might not match the name and the description field. For more information, see the Logging failed events with integration errors section.

Exporting logs

To export your logs to CSV, click the three vertical dots menu in the top-right corner. The following options are available:

  • Export logs: Export every log generated in the last 24 hours.
  • Export filtered logs: Export the currently filtered logs. This option is only enabled if a filter is applied.

The maximum number of records that can be exported in a single export is limited. The default limit configured on each instance is 10000 records. If you want to customize this limit, submit a request on our Support portal.

You can export logs with an API call as well. For more information, see the Log export endpoint documentation.


CSV exports are protected from code injection through a full escaping solution. See How are the logs and reports functions protected from code injection for details.

Data retention

Log entries are retained for 550 days.

Logging failed events with integration errors

When an registration, approval, or verification operation fails due to an integration error, the Event column in the table and the corresponding name and description fields in the JSON file might not be accurate. Instead, these fields have the following default values, regardless of the authentication channel:

Registration startedRegistration createduaf.registration.createdRegistration created
Approval startedAuthentication createduaf.authentication.createdAuthentication created
SMS or recovery code verifiedAuthentication verifiedsms.authentication.verifiedAuthentication verified

This inaccuracy can happen in the following cases:

  • The provided userId does not exist. For example, the user was deleted.

  • The request is badly formed with issues such as the following:

    • channel is missing or incorrect

    • displayName is missing or incorrect for fido2 channel

    • userId or authenticatorId is not a UUID

    • statusToken is included for recovery channel

      For more information on the use of parameters, see the Developer documentation.

Logging unfinished operations

An operation can include multiple events. For example, an approval operation includes an event for starting the approval, redeeming the token, and finalizing the approval. Each of these events are logged separately. If the entire operation is unfinished, an event can be still logged as succeeded. In this case, the subsequent event or events are not logged. The following example demonstrates this use case:

  1. The user starts and completes an approval operation.
  2. The Approval started event is successful and it is logged.
  3. The user aborts the operation but does not redeem the approval token.
  4. The Approval token redeemed and the Approval finalized events are not logged.