---
title: "eIDAS Audit Entry Types"
description: "Understand the fields in CREDENTIAL_ISSUED, CREDENTIAL_LIFECYCLE, and PRESENTATION_VERIFICATION_COMPLETED audit entries."
stack: "Enterprise Stack (commercial) — version 1.1.1"
stack_version: "1.1.1"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/enterprise-stack/administration/events-and-metrics/eidas-audit-log/entry-types
generated: 2026-10-01
---
# eIDAS Audit Entry Types

Every audit entry shares a common envelope and then adds type-specific evidence. Use this page when reviewing a query response and deciding whether the recorded evidence answers your compliance question.

## Shared Fields

| Field | Meaning |
|:------|:--------|
| `entryType` | Entry discriminator: `CREDENTIAL_ISSUED`, `CREDENTIAL_LIFECYCLE`, or `PRESENTATION_VERIFICATION_COMPLETED` |
| `id` | Unique entry ID |
| `organizationId` | Organization that owns the integrity chain |
| `target` | Service instance that produced the entry (for example `waltid.tenant1.issuer1`) |
| `timestamp` | When the action was recorded (Unix epoch milliseconds) |
| `sequenceNumber` | Monotonic position in the organization chain — gaps indicate missing entries |
| `prevEntryHash` | Hash of the previous entry, or `GENESIS` for the first entry in the organization |
| `entryHash` | Hash of this entry linked to `prevEntryHash` |

---

## `CREDENTIAL_ISSUED`

Recorded when a signed credential payload is successfully delivered to a wallet via OID4VCI.

| Field | Meaning |
|:------|:--------|
| `sessionId` | OID4VCI issuance session ID — correlates with operational issuance events |
| `credentialConfigurationId` | Credential configuration that was issued |
| `credentialIndex` | Position in a batch credential response (`0` for a single credential) |
| `format` | Credential format, e.g. `dc+sd-jwt` or `mso_mdoc` |
| `credentialPayloadHash` | SHA-256 of the signed credential bytes — proves what was delivered without storing claims |
| `holderBindingPublicKeyJwk` | Holder device-binding public key (JWK). `null` when cryptographic holder binding was not required |
| `proofType` | Proof used during issuance, e.g. `jwt` |
| `callId` | Optional correlation ID for application logs |
| `loaAchieved` | Level of Assurance recorded for this issuance — see below. Defaults to `NOT_APPLICABLE` |
| `identityProofingRefId` | Optional reference to an external identity-proofing session / log (for example an eID or passport chip verification). `null` when not supplied |

### Level of Assurance (`loaAchieved`)

Identity proofing often happens outside walt.id. Callers pass the achieved LoA on the Issuer2 issuance request or credential-offer runtime overrides; the value is copied onto the audit entry when the credential is issued.

| Value | Meaning |
|:------|:--------|
| `HIGH` | High level of assurance |
| `SUBSTANTIAL` | Substantial level of assurance |
| `LOW` | Low level of assurance |
| `NOT_APPLICABLE` | No LoA was supplied for this issuance (default) |

**How to use it in a review**

- Confirm a specific credential configuration and format were issued in a given session.
- Use `credentialPayloadHash` if you need to prove which signed payload was delivered, without retaining personal claims in the audit store.
- Use `holderBindingPublicKeyJwk` to show the credential was bound to a specific wallet key / hardware instance.
- Use `loaAchieved` and `identityProofingRefId` to bind the issued credential to the external onboarding / identity-proofing session that established the holder's assurance level.

**Note:**

The signed credential itself is never stored in the audit log. Only its hash is retained.

---

## `CREDENTIAL_LIFECYCLE`

Recorded when a credential's lifecycle state changes.

| Field | Meaning |
|:------|:--------|
| `sessionId` | Related issuance session identifier |
| `credentialConfigurationId` | Credential configuration affected by the transition |
| `event` | New lifecycle state — see below |
| `reasonCode` | Optional free-form legal or technical reason (typically set for suspension/revocation), e.g. `key_compromise` |
| `operatorId` | Operator or system identity that triggered the transition, when available |

### Lifecycle Events

| `event` | Meaning |
|:--------|:--------|
| `PROVISIONED` | Issuance offer / binding step started for the wallet instance |
| `ISSUED` | Signed credential was delivered |
| `SUSPENDED` | Credential temporarily suspended |
| `UNSUSPENDED` | Suspension lifted |
| `REVOKED` | Credential permanently revoked |

**How to use it in a review**

- Reconstruct the timeline of state changes for a session.
- Identify who or what system triggered a suspension or revocation (`operatorId`, `reasonCode`).

---

## `PRESENTATION_VERIFICATION_COMPLETED`

Recorded when an OID4VP presentation session finishes (success or failure).

| Field | Meaning |
|:------|:--------|
| `sessionId` | OID4VP verification session ID |
| `nonceHash` | SHA-256 of the OpenID4VP nonce — supports lookup without retaining the raw nonce |
| `dcqlQuery` | Exact DCQL presentation request sent to the wallet (JSON string) |
| `requestObjectX5c` | Certificate chain (`x5c`) from the signed Authorization Request Object |
| `requestObjectHash` | SHA-256 fingerprint of the signed Authorization Request Object, when present |
| `verifierInfo` | `verifier_info` items from the authorization request (format and data) |
| `issuerSignatureEvidence` | Results of issuer signature policies that were actually executed |
| `issuerTrustEvidence` | Results of issuer trust policies that were actually executed (for example EU Trusted List / VICAL) |
| `holderBindingEvidence` | Results of holder-binding policies that were actually executed |
| `revocationStatusEvidence` | Results of credential status / revocation checks that were actually executed (for example Token Status List or Bitstring) |
| `verifierTrustEvidence` | Results of Verifier WRPAC / Relying Party registry validation policies that were actually executed |
| `pairwiseSubjectId` | Optional sector-specific or presentation-derived pairwise subject identifier — supports correlation without storing PII claims |
| `outcome` | Overall result: `SUCCESS`, `FAILED`, or `WALLET_ERROR` |
| `failureCategory` | When failed: `VP_POLICY`, `VC_POLICY`, `DCQL`, or `WALLET_ERROR` |
| `callId` | Optional correlation ID for application logs |

### Policy Evidence Objects

Each item in the evidence arrays looks like:

| Field | Meaning |
|:------|:--------|
| `policyId` | Policy that ran (for example `signature`, `credential-status`, or `dc+sd-jwt/kb-jwt_signature`) |
| `queryId` | Related DCQL credential query ID, when applicable |
| `credentialIndex` | Index of the credential in the presentation, when applicable |
| `success` | Whether that policy passed |
| `errors` | Human-readable failure details |
| `evidence` | Optional structured evidence object |
| `evidenceCapturedAt` | When the policy result was captured (Unix epoch milliseconds) |

**How to use it in a review**

- Read `dcqlQuery` to verify data minimization — for example that you requested `age_over_18` rather than a full date of birth.
- Use `requestObjectX5c` and `verifierInfo` as relying-party authentication / authorization evidence for the session.
- Use `revocationStatusEvidence` to show the credential's status list / revocation check was evaluated at verification time.
- Use `verifierTrustEvidence` when WRPAC / national RP-registry validation ran for the verifier certificate.
- Use `pairwiseSubjectId` to correlate the presentation with internal business actions without retaining real identity claims.
- Use the policy evidence arrays and `outcome` to show which cryptographic checks passed or failed.
- Correlate with a wallet transaction using `sessionId`, or look up by the original nonce via the [query API](https://docs.walt.id/enterprise-stack/administration/events-and-metrics/eidas-audit-log/query.md#look-up-a-verification-by-nonce).

**Note:**

`dcqlQuery` can contain constrained claim values from the request. Treat audit access and retention according to your organization's audit-data policy even though credential payloads are not stored.

---

## Next Steps

- **Retrieve entries** — [Query the Audit Log](https://docs.walt.id/enterprise-stack/administration/events-and-metrics/eidas-audit-log/query.md).
- **Confirm nothing was altered** — [Verify Integrity](https://docs.walt.id/enterprise-stack/administration/events-and-metrics/eidas-audit-log/verify-integrity.md).