Under eIDAS 2.0, Regulation (EU) 2024/1183, which amends Regulation (EU) 910/2014, audit and logging requirements apply to qualified trust service providers (QTSPs), wallet providers, and relying parties that operate within the European Digital Identity ecosystem. These parties must record, protect, and retain detailed logs of identity transactions, credential exchanges, and trust service operations. The requirements are designed to ensure accountability, enable regulatory oversight, and support incident investigations across the entire digital identity chain. Responsibility for meeting these obligations is shared across multiple actors, including the European Commission, EU Member States, national competent authorities, wallet providers, issuers of Person Identification Data and attestations, QTSPs, and relying parties. This article walks through the key questions organizations need to answer to stay compliant.
What types of events must be logged under eIDAS 2.0?
Under eIDAS 2.0, organizations must log any event that affects the integrity, security, or validity of a trust service or identity transaction. This includes the issuance and revocation of qualified certificates, the creation and validation of electronic signatures and seals, wallet interactions involving Personal Identification Data (PID) and electronic attestations of attributes (EAA), and any access to, or exchange of, identity credentials through the EUDI Wallet ecosystem.
More specifically, the types of events that typically fall within scope include:
- Issuance, suspension, and revocation of qualified certificates
- Authentication events and identity verification outcomes
- Presentation and verification of credentials via EUDI Wallets
- Electronic signature creation and validation events
- Access to national trusted lists and the EU List of Trusted Lists (LOTL)
- Security incidents, anomalies, and breach notifications
- Changes to system configuration or access rights
The underlying principle is comprehensive traceability. Every meaningful action within a trust service or identity transaction must leave a verifiable record, so that regulators, auditors, and supervisory bodies can reconstruct what happened, when, and by whom. For organizations operating EUDI Wallets or acting as relying parties, this means logging the interactions that occur when users present credentials to access services, in addition to internal system events. The legally binding requirements for what must be logged are set out in the implementing acts adopted by the European Commission. The Architecture and Reference Framework (ARF) provides the technical elaboration of those requirements but is not itself legislation.
Who is responsible for audit logging under eIDAS 2.0?
Responsibility for eIDAS 2.0 audit logging is shared across multiple actors depending on their role in the ecosystem. Audit logging governance reflects the broader structure of the EUDI Wallet framework, in which the European Commission sets the legal framework and adopts implementing acts, EU Member States provide or mandate wallet solutions and supervise actors within their jurisdiction, and national competent authorities oversee compliance at the national level. QTSPs carry the heaviest obligations, but wallet providers, relying parties, and public sector bodies that issue or accept credentials all have defined logging responsibilities under the regulation and its implementing acts.
For QTSPs, the obligation is direct and well-established. They must maintain detailed operational logs as part of their conformity requirements, which are assessed by accredited conformity assessment bodies. Supervisory bodies then review these logs as part of ongoing oversight and periodic audits.
Wallet providers are responsible for logging events related to wallet integrity, credential issuance, and user interactions at the wallet level. This includes recording when credentials are added, presented, or revoked within the wallet environment. Wallet providers operate within a framework certified and notified by their respective Member State, and supervisory oversight remains national rather than centrally managed by a single European authority.
Relying parties, meaning the organizations that request and verify identity attributes from users, also bear logging obligations. When a relying party receives and processes identity data from a wallet, they must record that transaction in a way that supports accountability and, where applicable, compliance with other regulatory frameworks such as AML or KYC obligations. Under CIR (EU) 2025/848, adopted on 6 May 2025, a relying party must register with the national authority of its Member State of establishment before requesting wallet data, and must register per intended use which attributes and attestations it will request. Relying party registration remains connected to the applicable national registration framework, and sector-specific legislation continues to apply alongside eIDAS 2.0.
Issuers of Person Identification Data and electronic attestations of attributes also carry logging responsibilities for the credentials they issue and the events associated with their lifecycle. In short, if your organization touches the digital identity chain under eIDAS 2.0, whether as an issuer, verifier, wallet provider, or QTSP, you likely have audit logging responsibilities. Understanding your specific role is the first step toward building a compliant logging infrastructure.
How long must audit logs be retained under eIDAS 2.0?
eIDAS 2.0 does not prescribe a single universal retention period for all audit logs. Instead, retention requirements depend on the type of trust service, the nature of the logged event, and any sector-specific regulations that apply alongside eIDAS 2.0. For qualified trust services, the regulation and its implementing acts generally require that records be kept long enough to support legal proceedings and regulatory investigations, which in practice often means a minimum of several years after the relevant service or certificate has expired.
For qualified electronic signatures and seals, long-term preservation is particularly important. The value of a signed document may need to be provable years or even decades after the original signing event, which means the associated audit trail must remain valid and verifiable over time. This is why eIDAS 2.0 includes provisions for qualified preservation services, which are specifically designed to maintain the legal validity of signatures and their audit evidence over extended periods.
Organizations should also factor in the retention requirements of other applicable regulations. For example, financial services firms subject to AML obligations may need to retain identity verification records for five years or more. Healthcare organizations face their own sector-specific rules. The practical approach is to identify the longest applicable retention requirement across all relevant frameworks and design your logging infrastructure accordingly.
What are the technical requirements for eIDAS 2.0-compliant audit logs?
eIDAS 2.0-compliant audit logs must be tamper-evident, timestamped, and structured in a way that supports independent verification. The implementing acts reference specific technical standards for trust services, and audit logs are expected to meet those standards in terms of integrity, authenticity, and accessibility for supervisory review. The ARF provides technical elaboration on how these requirements translate into implementation, but the legally binding obligations are contained in the implementing acts themselves.
Integrity and tamper-evidence
Audit logs must be protected against unauthorized modification. This typically means using cryptographic mechanisms, such as digital signatures or hash-chaining, to ensure that any tampering with a log entry is detectable. A log that can be altered without detection has no value as evidence, either for internal compliance or for regulatory oversight.
Qualified timestamps
Events must be timestamped accurately and verifiably. eIDAS 2.0 includes specific provisions for qualified electronic time stamps, which bind a date and time to data using a trusted source. For audit logging purposes, this means that the recorded time of an event must be traceable to an accurate and certified time source, rather than a local system clock that could be manipulated or misconfigured.
Beyond these two core requirements, compliant audit logs should also be structured to allow efficient querying and export. Supervisory bodies and conformity assessment bodies need to be able to review logs without requiring extensive manual effort. Logs should therefore be stored in formats that support automated analysis, and access controls must ensure that only authorized parties can retrieve or review them.
How do eIDAS 2.0 audit requirements interact with GDPR?
eIDAS 2.0 audit requirements and GDPR create a genuine tension that organizations must manage carefully. Audit logs often contain personal data, including identity attributes, transaction records, and authentication events linked to individual users. GDPR requires that personal data be collected only for specified purposes, retained no longer than necessary, and protected against unauthorized access. These principles apply fully to audit logs, even when those logs are required by eIDAS 2.0.
The key to managing this tension is data minimization and purpose limitation. Audit logs should capture what is necessary for accountability and compliance, without recording more personal data than the logging purpose requires. For example, a log entry confirming that a credential was successfully verified may not need to include the full content of the credential itself, only a reference or hash that allows the event to be traced without exposing unnecessary personal information.
Organizations also need to establish clear retention policies that satisfy both frameworks. A log retained for eIDAS 2.0 compliance purposes must still be deleted or anonymized once the retention period expires, in line with GDPR’s storage limitation principle. Building this into your logging infrastructure from the start will save significant effort during audits and regulatory reviews.
It is also worth noting that users have rights under GDPR, including the right to access information about how their data is processed. If audit logs contain personal data about a specific individual, that data may be subject to a subject access request. Organizations should have processes in place to handle this scenario without compromising the integrity of the audit trail itself. A relying party requires its own GDPR legal basis for processing identity data received from a wallet. Approval of a data request in the wallet is a separate act from consent as a GDPR legal basis.
What happens if an organization fails to meet eIDAS 2.0 audit obligations?
Failure to meet eIDAS 2.0 audit and logging obligations can result in loss of qualified status, supervisory sanctions, and potential legal liability. For QTSPs, non-compliance with logging requirements identified during a conformity assessment can lead to suspension or removal from the relevant national trusted list, which is part of the EU List of Trusted Lists (LOTL), effectively meaning the loss of the ability to offer qualified trust services in the EU market.
For wallet providers and relying parties, the consequences depend on the nature of the failure and the supervisory framework in the relevant Member State. Each Member State is responsible for certifying, notifying, and supervising wallet solutions and actors within its jurisdiction. Supervisory bodies have the authority to investigate, impose corrective measures, and in serious cases refer matters for further enforcement action. Organizations in regulated sectors such as finance or healthcare may face compounding consequences if an audit logging failure also constitutes a breach of sector-specific obligations, for example under AML or data protection rules.
Beyond regulatory penalties, inadequate audit logs create practical risk. In the event of a security incident or disputed transaction, an incomplete or tampered audit trail leaves an organization unable to demonstrate what actually happened. This weakens its position in any investigation or legal proceeding and can undermine trust with customers, partners, and regulators alike.
The reputational dimension should not be underestimated either. Organizations that operate in the digital identity space rely heavily on trust. A compliance failure that becomes public, particularly one involving the integrity of identity records, can cause lasting damage to customer and partner relationships.
How the ID Connector supports eIDAS 2.0 audit and logging compliance
Getting eIDAS 2.0 audit and logging requirements right requires a clear understanding of your role in the identity ecosystem, the applicable standards set out in the implementing acts, and how your logging infrastructure connects to broader compliance obligations. The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.
In the context of audit and logging compliance, the ID Connector supports organizations with:
- Mapping audit obligations to your specific role, whether you are a QTSP, wallet provider, relying party, issuer of Person Identification Data or attestations, or a public sector body issuing credentials
- Implementing tamper-evident, timestamped audit trails that meet the technical standards referenced in eIDAS 2.0 and its implementing acts
- Designing retention policies that satisfy both eIDAS 2.0 and GDPR requirements without creating unnecessary data exposure
- Integrating audit logging into your broader compliance infrastructure, including AML, KYC, and sector-specific frameworks relevant to financial services, healthcare, and government
- Preparing for conformity assessments and supervisory reviews with audit-ready evidence that supports your qualified status
The ID Connector handles verification against national trusted lists, revocation status checks, and validation of wallet unit attestations, giving your organization a structured basis for the audit trail that eIDAS 2.0 requires. If you want to understand exactly what your organization needs to do to meet its eIDAS 2.0 audit obligations, get in touch with our team for a practical conversation about your situation.