A relying party under eIDAS 2.0 is any public body or private operator that accepts credentials presented from an EU Digital Identity Wallet to authenticate a person or verify an attribute. Regulation (EU) 2024/1183 transforms that role from a voluntary integration choice into a mandatory infrastructure obligation for large parts of the European public sector and regulated industries, with acceptance deadlines converging on the end of 2026.
For compliance officers, CISOs and IT decision-makers, the central challenge is not simply integrating with a wallet ecosystem. It is doing so without delegating verification to foreign-controlled infrastructure, without exposing transaction data to non-EU jurisdiction, and without building cryptographic assumptions that a quantum computer will invalidate within the credential’s own lifetime.
What Regulation (EU) 2024/1183 Actually Requires from Relying Parties
The amended eIDAS Regulation mandates that public-sector bodies and regulated-sector operators in specified verticals accept EUDI Wallets as a valid means of authentication at assurance level High within 36 months of the relevant implementing acts entering into force. Given that four core implementing regulations, numbered (EU) 2024/2977, 2024/2979, 2024/2980 and 2024/2982, were published in late 2024, the practical compliance window closes around late 2026 for the first mandatory use cases: access to public services, qualified electronic signatures and mobile driving licences.
The European Commission states explicitly in the recitals of Regulation (EU) 2024/1183: “The wallet ecosystem must ensure that no single private entity, and in particular no entity outside the Union, can control the identity of EU citizens or residents.” That language is not rhetorical. It shapes the architecture requirement: verification must remain under EU jurisdiction.
The IBM Cost of a Data Breach Report 2024 found the global average cost of a data breach reached USD 4.88 million, the highest figure ever recorded. Identity-related incidents, where credential theft or session hijacking is the initial attack vector, consistently rank among the costliest categories. A misconfigured relying-party integration is precisely the kind of vulnerability that produces that exposure.
How ARF Protocols Create Foreign-Jurisdiction Data Flows
The EUDI Wallet Architecture and Reference Framework (ARF) specifies two protocols for the credential lifecycle: OpenID4VCI (OpenID for Verifiable Credential Issuance) for issuing credentials into the wallet, and OpenID4VP (OpenID for Verifiable Presentations) for presenting credentials to a relying party. Both protocols are standards-track IETF and OpenID Foundation specifications and are, in themselves, jurisdiction-neutral. The exposure arises not from the protocols but from where the verifier endpoint runs and what telemetry commercial identity broker products send to their cloud platforms.
When a relying party delegates OpenID4VP verification to a SaaS-based identity broker, the presentation token including the selective-disclosure proof and the holder-binding key confirmation travels to the broker’s servers. If those servers are operated by a US parent entity, the US CLOUD Act and FISA Section 702 give US authorities potential access to that data without mutual legal assistance treaty procedures. Even if data is nominally stored in an EU region, the legal control test under the CLOUD Act attaches to corporate domicile, not server location.
On-Premises Implementation Patterns that Eliminate the Exposure
A sovereign relying-party stack runs the OpenID4VP Verifier endpoint on infrastructure under the organisation’s direct control. The critical components are: a Verifier service that generates presentation request URIs and validates response tokens; a local cache of the EU Trusted List to verify issuer certificate chains without calling an external resolver; and a Status List client that queries credential revocation endpoints directly, rather than through a proxy.
The EU reference implementation libraries published under the EUDI Wallet open-source programme provide a starting point. Organisations with self-hosted Nextcloud or similar sovereign workspace infrastructure can integrate the Verifier component into the same on-premises perimeter, ensuring that no presentation data leaves the organisation’s network boundary during the authentication handshake.
Post-Quantum Cryptographic Requirements for WSCD and WSCA
The Wallet Secure Cryptographic Device (WSCD) is the tamper-resistant hardware element, typically an embedded secure element or a remote HSM, that holds the wallet’s private keys and performs signing operations. The Wallet Secure Cryptographic Application (WSCA) is the software layer that mediates between the wallet application and the WSCD. Implementing Regulation (EU) 2024/2982 sets out the security and certification requirements for both components, requiring conformance with Common Criteria protection profiles at assurance level EAL4 or above.
ETSI TR 103 619, ETSI’s dedicated analysis of post-quantum migration impacts on trust services, concludes that current RSA-2048 and ECDSA keys used in qualified certificates could be broken by a cryptographically relevant quantum computer within the validity period of long-lived credentials. The ETSI Electronic Signatures and Infrastructures Technical Committee has stated directly: “The migration to post-quantum algorithms in trust services is not a future concern; it is an immediate engineering challenge because data signed or encrypted today may be exposed once quantum capabilities mature.”
NIST finalised three post-quantum standards in 2024: FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for digital signatures) and FIPS 205 (SLH-DSA as a stateless hash-based alternative). The implementing acts under eIDAS 2.0 do not yet mandate specific PQC algorithms for WSCD or WSCA, but they do require cryptographic agility in the design. In practical terms, WSCA implementations should be capable of negotiating hybrid signature schemes, pairing classical ECDSA with ML-DSA, so that wallet credentials remain verifiable by both legacy and PQC-capable verifiers during the transition period.
Replacing Foreign QTSP Reliance with a Self-Hosted Verification Stack
Many organisations currently rely on commercial Qualified Trust Service Providers (QTSPs) from outside the EU, or on US-headquartered identity platforms that bundle QTSP validation as a cloud service. Under ETSI EN 319 401 and EN 319 411, QTSPs must meet strict baseline requirements for service continuity, audit and key management. However, the QTSP only issues and maintains the qualified certificate attached to the credential; the relying-party verification step is architecturally separate and does not need to involve the QTSP at runtime.
A sovereign organisation can build assurance level High verification without any runtime dependency on a foreign QTSP by following this pattern:
| Component | Commercial broker approach (foreign dependency) | Sovereign self-hosted approach |
|---|---|---|
| Presentation request generation | SaaS Verifier endpoint (US cloud) | On-premises Verifier service (EU jurisdiction) |
| Issuer trust validation | Broker calls external resolver | Local EU Trusted List cache, refreshed via ETSI-defined feed |
| Revocation check | Broker proxies Status List query | Direct HTTP fetch to issuer’s Status List endpoint |
| Attribute disclosure logging | Broker stores in cloud tenant | Local pseudonymised audit log, GDPR-scoped retention |
| Cryptographic agility | Dependent on broker roadmap | Organisation-controlled, PQC migration on own schedule |
The European Commission estimates that 80% of EU citizens should have access to a digital identity wallet by 2030 under the Digital Decade policy targets. Sovereign relying parties that build their own verification stack now will be positioned to onboard that user base without renegotiating commercial contracts or accepting updated data processing terms from a foreign provider.
GDPR Article 5 Obligations for Wallet Presentation Logging
Every time a holder presents credentials, the relying party processes personal data. GDPR Article 5(1)(b) requires that data be collected for specified, explicit and legitimate purposes and not further processed in a manner incompatible with those purposes. Article 5(1)(c) requires data minimisation: only attributes that are adequate, relevant and limited to what is necessary may be processed.
In the context of EUDI Wallet presentations, this has concrete implications. If a relying party verifies age eligibility, it must not log the holder’s full date of birth if a boolean “over 18” predicate would suffice. If it verifies professional qualification, it must not retain the entire credential dump when only the qualification type and expiry date are relevant to the transaction purpose.
Designing Retention and Deletion Policies for Wallet Logs
Audit logs for wallet presentation transactions should be structured to contain a pseudonymous transaction identifier, the credential type and schema, the verification outcome, and a timestamp. The record of processing activities (RoPA) required by GDPR Article 30 must document the legal basis for each logged field, the retention period and the deletion mechanism. Automated deletion at the end of the documented retention period is not optional: manual deletion processes fail in practice because staff turnover and system changes interrupt them.
For regulated-sector organisations subject to NIS-2 or DORA, audit log retention serves a dual purpose: GDPR compliance requires minimisation and deletion, while incident response and supervisory inspection require sufficient retention. The resolution is to maintain a GDPR-scoped operational log with a short retention period, for example 90 days, and a separate, attribute-free integrity log that records only cryptographic hashes of transaction records for the longer audit period required by sectoral regulation. That separation satisfies both frameworks without conflict.
Building Provable Compliance Across the Regulatory Stack
A sovereign EUDI Wallet relying-party implementation touches at least four regulatory frameworks simultaneously: Regulation (EU) 2024/1183 and its implementing acts for wallet acceptance obligations; GDPR for personal data processing during verification; NIS-2 for security of the verification infrastructure itself if the organisation qualifies as an essential or important entity; and, for financial institutions, DORA for ICT risk management and third-party dependency reporting.
The practical advantage of a self-hosted stack is that each component is auditable by the organisation’s own team and by supervisory authorities without requiring the cooperation of a foreign vendor. Log formats, cryptographic configurations and data flows can be documented in the organisation’s own language, attached to the RoPA, and presented to a data protection authority or a NIS-2 competent authority without redaction for commercial confidentiality reasons.
Sovereign identity infrastructure is, in this sense, not only a legal risk mitigation measure. It is a compliance asset: it makes conformity demonstrable rather than asserted.
FAQ: eIDAS 2.0 EUDI Wallet Relying Party Sovereignty
By when must relying parties accept EUDI Wallets, and does this apply to private-sector operators?
Regulation (EU) 2024/1183 sets an acceptance deadline of 36 months after the entry into force of the implementing acts, which puts the practical deadline at the end of 2026 or early 2027 for most mandatory use cases. Mandatory acceptance applies to public bodies and to regulated-sector operators in finance, healthcare and telecommunications where those sectors are named in the implementing acts. Broader private-sector reliance is voluntary but encouraged through the interoperability framework.
What makes a relying-party verification stack sovereign under the eIDAS 2.0 framework?
A sovereign stack processes OpenID4VP presentation requests and responses entirely on infrastructure under the relying party’s jurisdictional control, without forwarding presentation tokens, selective-disclosure proofs or holder-binding keys to a third-party broker or foreign cloud service. It operates its own Verifier component, validates issuer trust anchors against the EU Trusted List locally, and retains no personal data beyond the transaction purpose.
Are open-source relying-party implementations eligible for eIDAS 2.0 compliance at assurance level High?
Yes. Assurance level High is determined by the wallet and credential issuance process, not by the relying-party software. Open-source stacks that correctly implement OpenID4VP with the mandatory cryptographic suites and check revocation status against the issuer’s Status List satisfy the protocol requirements. The EU reference implementation libraries published under the EUDI Wallet open-source programme are a documented starting point.
How should a sovereign relying party handle audit logging without violating GDPR data minimisation?
Logs should record only a pseudonymous transaction identifier, the credential type verified, the result and a timestamp. Actual attribute values disclosed by the wallet holder must not be retained unless a separate documented legal basis exists for each attribute. Automated deletion at the end of the retention period, defined in the RoPA, is essential. For dual regulatory compliance with NIS-2 or DORA, a second attribute-free integrity log using cryptographic hashes of transaction records can satisfy longer audit retention requirements without retaining personal data.
What post-quantum algorithms are recommended for WSCD and WSCA components today?
NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in 2024. The eIDAS 2.0 implementing acts do not yet mandate specific PQC algorithms but require cryptographic agility in WSCA design. For WSCD hardware that must remain valid for many years, hybrid schemes pairing classical ECDSA with ML-DSA provide backward compatibility with existing verifiers while adding quantum resistance. ETSI TR 103 619 remains the primary technical reference for migration planning in the trust services context.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.