Logs and audit trails
Self-service log inspection is on the LuxID roadmap. Today, you request log extracts from LuxID by emailing LuxID with the time window, Application, and the type of log you need. The three log streams described below are real - the change is the interface, not the data.
Overview
The future LuxID Console will expose three distinct log streams under a Logs section. Each stream answers a different operational question:
| Stream | Question answered |
|---|---|
| Authentication logs | Did a specific user successfully log in to my Application, and if not, why? |
| Subscription logs | When did a user connect or disconnect from my Application? |
| Audit logs | Who changed what configuration on my Partner or Application, and when? |
All three streams are scoped to your Partner. You cannot see log data from other Partners.
Logs in the Console are a pull interface - you query them on demand. For event-driven updates (SIEM integration, fraud detection, automated alerting), the LuxID Event Hub is the complementary mechanism: Console logs for investigation, Event Hub for event-driven updates. Today the Event Hub emits a single event type (ClaimValuesChanged) over a pull model; a broader event catalogue and signed-webhook push are planned but not yet available. See Events and Event Hub.
Authentication logs
What is recorded
Every authentication attempt directed at one of your Applications generates a log entry. This includes successful logins, failed attempts, and step-up authentication events.
Each entry contains the following fields:
| Field | Description |
|---|---|
| Timestamp | Date and time of the event (UTC, ISO 8601). |
| Transaction ID | The identifier of the authentication transaction, surfaced both in this log and on the user-facing authentication error dialog ("Connection error with LuxID"). If a user contacts support with a failed sign-in, the Transaction ID links their error to this log entry. This is distinct from the WAF Support ID (shown on block / masked-500 pages) and the developer-only Global Transaction ID (in HTTP headers) - see the identifiers reference. |
| Application | The name and Client ID of the Application that initiated the authentication, including which environment (Production or UAT) was used. |
| User | The Application-scoped pseudonymous identifier (sub) of the authenticating user. The user's email address is not stored in authentication logs. |
| Authentication method | The method used: password, OTP (SMS/voice), TOTP (authenticator app), passkey, LuxTrust. |
| Authentication level reached | The auth_level value (2/3/4/8/9) achieved at the end of the flow, reflecting the strength of the factors presented. See Authentication levels for the scale. |
| Outcome | Success or Failure. |
| Failure reason | Present on Failure entries. Examples: invalid_credentials, mfa_timeout, account_locked, redirect_uri_mismatch. |
| IP address | The IP address of the user's browser at the time of the authentication request. |
| User agent | The browser/device user agent string. |
Transaction IDs
The Transaction ID is particularly important for support workflows. When LuxID displays an authentication error to a user (the "Connection error with LuxID" dialog), that screen shows both an Error ID (a short symbolic code for the scenario) and a long hexadecimal Transaction ID. The Transaction ID in the authentication log corresponds to this value.
Do not confuse it with two neighbouring identifiers: the Support ID returned by the WAF on block / masked-500 pages, and the developer-only Global Transaction ID carried in HTTP response headers for LuxID's own tracing. The identifiers reference lays out all four.
When a user reports an authentication failure, ask them for the Error ID and the Transaction ID shown on the dialog. Use the Transaction ID to filter the authentication log to the specific event, then inspect the failure reason and surrounding context.
Filtering and searching
The authentication log supports filtering by:
- Date range - select a start and end date/time.
- Application - filter to a specific Application.
- Outcome - Success, Failure, or both.
- Failure reason - filter to a specific error code.
- Transaction ID - direct lookup by the Transaction ID shown on the authentication error dialog.
- User sub - filter to all events for a specific pseudonymous user identifier.
Combine filters to narrow results. For example: failures on a specific Application in the past 24 hours.
Export
Select Export CSV to download the current filtered result set. The CSV contains all columns listed above. Large exports (over 10,000 rows) are queued and delivered by email to your Console account address.
Subscription logs
What is recorded
A Subscription is the link between a user and an Application - it is created when the user first consents to share their data with the Application, and revoked when the user withdraws consent or the Application decommissions the Subscription.
The Subscription log records:
| Field | Description |
|---|---|
| Timestamp | Date and time of the event (UTC). |
| Event type | subscription_created, subscription_revoked, or subscription_suspended. |
| Application | The Application to which the Subscription applies. |
| User | The pseudonymous sub identifier. |
| Actor | Who triggered the event: the user (self-service via https://account.luxid.lu/ (opens in a new tab)), the Application (via API), or the LuxID operations team. |
| Reason | Present on revocation events. Example: user_requested, application_decommissioned, policy_violation. |
Use cases
- Confirm that a user who reports they "can no longer log in" has not revoked their Subscription.
- Verify that your Application's API-triggered Subscription revocations are being processed.
- Generate a count of active Subscriptions per Application for reporting purposes (export to CSV and aggregate externally).
Audit logs
What is recorded
The audit log records configuration changes made to your Partner and its Applications via the Console or via the Partner API. Every change entry includes:
| Field | Description |
|---|---|
| Timestamp | Date and time of the change (UTC). |
| Actor | The Console user (identified by email address) who made the change, or system for automated operations. |
| Resource | The entity that was changed: Application, Claim Template, Group, Redirect URI, Certificate, Member, or Partner settings. |
| Resource ID | The identifier of the specific resource (for example, the Application's Client ID). |
| Action | The operation: created, updated, deleted, rotated (for credentials), revoked. |
| Change detail | A structured description of what changed - for example, "redirect_uri added: https://app.example.lu/callback". |
Use cases
- Investigate when a configuration change was made and by whom (for example, "who added that redirect URI last Thursday?").
- Demonstrate to an auditor that credential rotation events occurred on schedule.
- Correlate a production incident with a configuration change made around the same time.
- Satisfy GDPR accountability obligations for data-sharing configuration changes.
Immutability
Audit log entries cannot be deleted or modified by Partner administrators. They are an immutable record maintained by LuxID. If you require a certified copy of audit records for legal or compliance purposes, contact LuxID.
Log retention
Authentication and Subscription logs are retained for 6 months. Audit logs are retained for 6 months.
Events older than the retention period are purged automatically. If you need to retain log data beyond 6 months for compliance purposes, export regularly to your own SIEM or long-term storage.
GDPR considerations
End users have the right to access data LuxID holds about them. The authentication log contains data attributable to individual users (via the sub identifier and the associated LuxID Account). If a user submits a Subject Access Request (SAR) to your organisation as a Partner, the relevant authentication log entries fall within scope.
Users can also view and manage their own Subscriptions and session data via the LuxID Account portal at https://account.luxid.lu/ (opens in a new tab). This does not replace your obligation to handle SARs for data held in your own systems.
For further guidance, see Governance, trust and compliance.
Relationship to the Event Hub
Console logs are designed for human investigation and periodic export. The Event Hub is designed for machine consumption - it delivers events to your endpoint in real time via webhooks or streaming APIs.
If you are building a security monitoring pipeline, automated user provisioning workflow, or real-time fraud detection system, the Event Hub is the appropriate tool. Console logs remain available for retrospective investigation regardless of whether you use the Event Hub.
See APIs and advanced for Event Hub configuration.