Under eIDAS 2.0, any organisation that wants to request attributes from an EUDI Wallet — a bank checking age, a marketplace verifying a professional licence, a platform confirming employment status — must first register as a Relying Party. This is not a formality bolted onto the technical integration; it is a legal precondition. Without registration, a wallet will not even present the consent screen for your request, because the wallet app checks the requester's certificate against the national trust infrastructure before showing the user anything.
What Relying Party registration actually is
Registration is the process by which a national supervisory body verifies your organisation's identity, the legal basis for the attributes you intend to request, and your conformance with the technical and security requirements of the Architecture and Reference Framework (ARF). Once approved, your organisation is entered into a national Relying Party register — a public or semi-public list, feeding into the broader EU Trust List infrastructure — and issued the credentials needed to request presentations from wallets.
- It establishes who you are as a legal entity requesting personal data.
- It establishes why you are entitled to request specific attributes (your legal basis or legitimate interest per use case).
- It results in issuance of a Relying Party access certificate used to sign presentation requests.
What data you actually submit
Requirements vary slightly by Member State, but the core dossier is consistent:
- Corporate identity documents and proof of legal establishment.
- A description of each use case: which attributes you request, from which attestation types, and the legal basis for each request (contract, legal obligation, consent).
- Technical conformance evidence: how your relying party software validates signatures, checks revocation, and handles the OpenID4VP presentation flow.
- Data protection documentation: retention periods, DPIA where applicable, and confirmation that you request the minimum attribute set necessary.
- Named contacts for security incidents and supervisory correspondence.
Every attribute request you register has to be justified individually — you cannot register a blanket 'identity verification' use case and later request whatever you like. If your onboarding flow evolves, expect a registration amendment.
Timelines
Processing times are not standardised across the EU, and early implementations show wide variance. As a planning baseline:
- Initial dossier preparation: 4-8 weeks internally, mostly legal and product work rather than engineering.
- Supervisory review: several weeks to a few months, depending on the national body's caseload and whether clarifications are requested.
- Certificate issuance and technical onboarding to the national trust infrastructure: additional weeks.
- Renewal and amendment cycles: recurring, not one-off — certificates expire and use cases evolve.
Registration timelines behave like regulatory licensing, not like signing up for an API key. Budget quarters, not days.
The per-Member-State duplication problem
This is where the process becomes expensive for any business operating across borders. Each Member State runs its own register, its own supervisory body, and — in the early years of the ecosystem — its own interpretation of ARF requirements. A company operating in France, Germany, Italy and Spain does not register once; it runs four separate dossiers, with four sets of contacts, four renewal calendars, and four certificate lifecycles to track. None of this duplication adds security — it is purely administrative overhead created by the absence of a single EU-wide Relying Party register in the near term.
- Four legal reviews of essentially the same use cases, adapted to local wording requirements.
- Four certificate rotation schedules with different expiry cadences.
- Four points of contact to maintain for supervisory correspondence and incident notification.
Access certificates in practice
Once registered, your Relying Party status is expressed technically through an access certificate: every presentation request your service sends to a wallet must be signed with this certificate, and the wallet validates it against the trust infrastructure before showing the consent screen. Certificates have defined validity periods and must be rotated before expiry — a lapsed certificate silently breaks your entire onboarding flow, not just a single feature.
Why most companies outsource this
Given the duplication across Member States and the ongoing maintenance burden, most product and compliance teams conclude that direct registration only makes sense if wallet verification is core to their regulated business model (e.g. a bank). For everyone else, registering through an intermediary Relying Party — an organisation already registered in each relevant Member State that performs the presentation request on your behalf — collapses four dossiers and four certificate lifecycles into a single API integration. This is the model Arkadiz operates: we hold the registrations and certificates, and your team integrates once.