eIDAS 2.0 Relying Party Registration: The Complete Guide

If you've decided to get your own WRPAC certificate and register as a Relying Party under eIDAS 2.0, you're embarking on a journey through Europe's most sophisticated digital identity compliance framework. This guide walks you through everything you need to know about Article 5b registration requirements, the step-by-step process, and the technical specifications you'll need to master.

Whether you're a large enterprise preparing for in-house compliance, a fintech navigating regulatory requirements, or a business exploring your options before committing to the aggregator path, this is your comprehensive resource.

Who Qualifies as a Relying Party?

Under eIDAS 2.0, a Relying Party is any natural or legal person that requests and validates identity attributes from EU Digital Identity Wallets for authentication or authorization purposes.

Common Relying Party Use Cases

You're a Relying Party if you:

• Verify age for alcohol, tobacco, gambling, adult content, or age-restricted goods
• Verify identity for financial services (KYC/AML), account creation, or legal contracts
• Verify professional credentials for hiring, licensing, or professional services
• Verify educational credentials for admissions, employment, or certification
• Verify address for shipping, legal jurisdiction, or service eligibility
• Authenticate users for secure system access or privileged operations

Basically: If you ask EU citizens to prove something about their identity using the EUDI Wallet, you're a Relying Party.

Article 5b: The Legal Framework

Article 5b of Regulation (EU) 2024/1183 establishes the entire Relying Party framework. Let's break down what it requires.

Core Registration Requirements (Article 5b, Paragraph 1)

Every Relying Party must register with the supervisory body of their home member state and provide:

1. Identification information:

   • Legal name and establishment details
   • Registered address and jurisdiction
   • Legal entity identifier (if applicable)
   • Contact information for compliance purposes

2. Intended use declaration:

   • Specific attributes you will request (e.g., "age over 18", "full name", "address", "professional qualifications")
   • Purpose and legal basis for requesting each attribute
   • Use cases and application scenarios
   • Expected transaction volume (may be required)

3. Technical capabilities:

   • Confirmation of ability to validate EUDI Wallet credentials
   • Description of technical implementation (direct integration vs intermediary)
   • Security measures and data handling procedures

Cost-Effective and Proportionate Principle

Article 5b explicitly states that registration must be "cost-effective and proportionate to the risk involved."

What this means:

• Authorities cannot impose excessive fees or create unreasonable barriers to entry
• Small businesses should not face the same regulatory burden as large financial institutions
• Registration requirements should scale with the risk profile of your use case

Expected registration fees: €100-1,000 annually, varying by member state (exact amounts TBD as infrastructure rolls out).

Passporting: One Registration, 27 Countries

This is crucial: A registration in one EU member state is valid across all 27 member states.

Example: A French company registers as a Relying Party in France. That registration automatically allows them to verify German, Italian, Spanish, Dutch (etc.) citizens via their national EUDI Wallets—no separate registration required in each country.

This is the passporting principle, and it's what makes the EUDI ecosystem truly pan-European from day one.

Ongoing Obligations After Registration

Registration isn't a one-time event. Article 5b imposes continuing responsibilities:

1. Report Changes Without Delay

If any of the following change, you must notify your national supervisory body:

• Intended use cases — Adding new attributes or purposes
• Legal status — Company name changes, mergers, acquisitions
• Technical implementation — Switching from direct integration to intermediary (or vice versa)
• Contact information — Ensuring regulators can reach you

Timeline: "Without delay" means you can't wait for annual renewal. Changes must be reported as they occur.

2. Identify Yourself to Users

When a user's wallet displays your verification request, it must clearly show:

• Who is requesting the data — Your business name as registered
• What attributes are being requested — Exactly which data points
• Purpose of the request — Why you need the data (if required by national law)

This is about transparency and user control. Users must understand who's asking for their data and why before they authorize.

3. Accept Pseudonyms Where Identification Not Required

If your use case doesn't legally require full identification, you must accept pseudonymous attributes.

Example: An online age verification for alcohol doesn't legally require you to know the user's name or full identity—only that they're over 18. In this case, you must accept a pseudonymous "age over 18" attribute without demanding full identity disclosure.

Why this matters: Privacy by design. The regulation forces Relying Parties to minimize data collection to what's strictly necessary.

Step-by-Step Registration Process

Here's what the registration journey will look like (infrastructure expected mid-2026):

Step 1: Determine Your Home Member State

You register in the country where your business is legally established—not where your customers are located.

• Headquartered in Germany? Register with German national authority.
• Incorporated in Ireland? Register with Irish supervisory body.
• Established in Luxembourg? Register with Luxembourg's ILNAS or designated authority.

Cross-border passporting handles the rest—your registration is automatically valid EU-wide.

Step 2: Prepare Documentation

Gather the required information and documents:

• Legal entity documentation:

  • Business registration certificate
  • Articles of incorporation
  • Tax identification number
  • Proof of legal establishment in home member state

• Use case documentation:

  • List of attributes you will request
  • Legal basis for each attribute (GDPR compliance)
  • Description of verification scenarios
  • Data handling and retention policies

• Technical implementation plan:

  • Direct integration vs intermediary model
  • Security measures and encryption protocols
  • Compliance with GDPR and data protection rules

Pro tip: If this sounds daunting, consulting services (like eIDAS Pro's advisory packages) provide pre-built documentation templates tailored to your use case and country, dramatically simplifying this step.

Step 3: Access Your National Registration Portal

Each member state will operate its own registration portal. These are not yet live as of February 2026, but expected to launch mid-2026.

Expected features:

• Online application submission
• Document upload functionality
• Status tracking and notifications
• Payment processing for registration fees

Variation by country: Each member state designs its own portal, so the user experience and specific requirements may differ slightly. The underlying Article 5b requirements, however, are harmonized across the EU.

Step 4: Submit Application and Pay Fees

Complete the online application, upload required documents, and pay registration fees.

Processing times: Unknown as of February 2026. Early adopters may face longer processing as authorities work through initial application volumes.

Approval criteria: Authorities will verify:

• Legal establishment in the member state
• Completeness of application
• Technical capability to validate credentials
• Compliance with GDPR and data protection requirements

Step 5: Receive Registration Certificate

Upon approval, you'll receive a Registration Certificate—the official document proving you're a registered Relying Party.

What this certificate contains:

• Your unique Relying Party identifier
• Registered business details
• Approved use cases and attributes
• Validity period (typically annual renewal)

Public registry: Your registration will be listed in a public registry maintained by your national authority, ensuring transparency for users and regulators.

Step 6: Obtain WRPAC Access Certificate

Now that you're registered, you can approach a Qualified Trust Service Provider (QTSP) to obtain your WRPAC Access Certificate.

Requirements for QTSP:

• Provide your Registration Certificate as proof of eligibility
• Complete QTSP's identity verification and onboarding
• Pay certificate issuance fees (pricing not yet public, estimated €500-5,000/year)
• Agree to certificate terms and renewal schedule

QTSPs expected to issue WRPAC:

• LuxTrust (Luxembourg)
• D-Trust (Germany)
• InfoCert (Italy)
• And other qualified trust service providers across the EU

Certificate validity: Typically 1 year, requiring annual renewal.

Technical Requirements for Relying Parties

Getting registered is only half the battle. You also need to implement the technical protocols to communicate with EUDI Wallets.

1. OpenID4VP Protocol Support

OpenID for Verifiable Presentations (OpenID4VP) is the protocol that EUDI Wallets use to present credentials to Relying Parties.

What you need to implement:

• Presentation request generation: Creating a signed request for specific attributes
• QR code or deep link delivery: Presenting the request to users via QR code (desktop) or deep link (mobile)
• Response handling: Receiving and validating the verifiable presentation from the wallet
• Signature verification: Cryptographically validating the response

Complexity: High. This requires expertise in cryptographic protocols, JWTs, and verifiable credentials standards.

2. Credential Format Handling

EUDI Wallets support two credential formats:

SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential)

• Based on JSON Web Token (JWT) standard
• Allows selective disclosure of attributes via hashed claims
• Users disclose only requested attributes, not entire credential

Example use case: User has a credential with name, birthdate, address, and age_over_18. You request only "age_over_18", and only that attribute is disclosed.

mdoc (ISO/IEC 18013-5)

• Based on mobile driving license standard
• Uses CBOR encoding instead of JSON
• Mandatory for certain credential types (e.g., mobile driving license, health credentials)

Your implementation must support both formats. Different member states and credential types may use different formats.

3. Trust List Integration

Here's where it gets complex: You need to integrate with trust lists from all 27 EU member states.

What are trust lists?

• Authoritative lists of trusted credential issuers
• Published by national authorities
• Contain issuer certificates and public keys for signature verification

Why you need them:

• To verify that a credential was issued by a legitimate national ID provider
• To validate the cryptographic signatures on credentials
• To check revocation status of issuer certificates

The challenge:

• 27+ national trust lists (some member states may have multiple lists)
• Different formats and update frequencies
• Ongoing monitoring for certificate additions, updates, and revocations

Estimated development effort: 3-6 months of engineering work to build robust trust list integration and maintain compatibility as standards evolve.

4. Security and Data Handling

Article 5b requires Relying Parties to:

• Use strong encryption for credential transmission
• Validate signatures cryptographically using trust list certificates
• Minimize data retention to what's strictly necessary
• Implement GDPR compliance for data subject rights
• Log verification events for audit purposes (without storing PII)

Best practice: Process credentials statelessly—validate, extract required attributes, return result to your application, and immediately delete the full credential. Retain only audit metadata (timestamp, attribute types requested, success/failure), not personal data.

Common Misconceptions: HSM and QSCD Requirements

One of the most persistent myths about Relying Parties is the HSM requirement. Let's clarify:

Myth: "Relying Parties Need Hardware Security Modules (HSMs)"

Reality: No. HSMs and Qualified Signature Creation Devices (QSCD) are required for:

• Wallet providers (entities issuing EUDI Wallets to citizens)
• Credential issuers (national ID providers signing credentials)
• QTSPs (trust service providers issuing certificates)

Relying Parties do NOT need HSMs or QSCD. Your WRPAC Access Certificate is issued by a QTSP (who uses HSMs). You, as the Relying Party, simply use that certificate to authenticate your requests—no specialized hardware required.

Why the confusion? Early draft documents referenced QSCD requirements in the context of the broader ecosystem, leading some to misinterpret the scope. The final ETSI TS 119 475 standard clarifies that RPs do not require HSMs.

Current Status: Where Member States Stand (February 2026)

As of February 2026, here's the deployment status:

No Operational Registration Infrastructure Yet

None of the 27 EU member states have deployed live RP registration portals. This isn't a delay—the December 2026 deadline for EUDI Wallet availability is on track. RP registration infrastructure is expected to open mid-2026, giving businesses approximately 6 months to register before production launch.

Standards Are Finalized

• ETSI TS 119 475 v1.1.1 (WRPAC technical standard) published October 2025
• Article 5b implementing acts under discussion (Batch 2 implementing acts still in draft)
• OpenID4VP specifications finalized and published

QTSPs Are Preparing

Qualified Trust Service Providers like LuxTrust, D-Trust, and others are preparing to issue WRPAC certificates once RP registration infrastructure opens. They cannot issue certificates until Relying Parties hold Registration Certificates—it's a prerequisite.

Two Paths Forward: DIY Registration vs Aggregator

So you've read this far. You understand the requirements. Now the question: Should you actually do this?

Path 1: DIY Registration (For Enterprises)

Choose this path if:

• You're a large enterprise with dedicated compliance and legal teams
• You have 6-12 months and €150K+ to invest in Year 1
• You require complete control over the technical stack
• Your verification volume is multi-million transactions annually

What you're committing to:

• Step-by-step registration process outlined above
• WRPAC certificate procurement and renewal
• OpenID4VP protocol implementation
• Trust list integration with 27+ member states
• Ongoing compliance reporting and maintenance

---

Path 2: Use an Aggregator (For Most Businesses)

Choose this path if:

• You want to get to market quickly (days, not months)
• You prefer operational simplicity over control
• You're integrating one or a few straightforward use cases
• You'd rather focus engineering resources on your core product

What you get:

• API integration in 1-2 days
• Zero registration burden (aggregator handles it)
• Production-ready in December 2026 with no scrambling
• EU-wide compliance via aggregator's passporting registration

Services like eIDAS Pro offer this model under Article 5b(10).

---

Path 3: Consulting Services (Middle Ground)

Choose this path if:

• You want your own WRPAC but need guidance
• You have in-house resources but lack eIDAS 2.0 expertise
• You need documentation packages for national registration
• You want technical specs support (OpenID4VP, trust lists, etc.)

What you get:

• Pre-built documentation templates for your country
• Technical guidance on protocol implementation
• Ongoing compliance advisory as regulations evolve
• You register in your own country using our documentation

eIDAS Pro offers consulting packages for enterprises pursuing DIY registration.

Timeline to December 2026

If you're pursuing DIY registration, here's your critical timeline:

Mid-2026 (Expected):

• RP registration infrastructure opens
• Submit registration application immediately to avoid backlog
• Processing time: Unknown (could be days or weeks)

Late 2026:

• Receive Registration Certificate
• Approach QTSP for WRPAC Access Certificate
• Certificate issuance: 2-4 weeks
• Complete technical integration (should already be underway)

December 2026:

• EUDI Wallets go live
• Production verifications begin
• You must be ready

The risk: If infrastructure opens in June and you start in November, you're cutting it dangerously close. Registration delays, QTSP onboarding delays, or technical integration issues could leave you scrambling past the deadline.

The smart approach: Start preparing documentation now. Begin technical integration in DEMO/MOCK mode. Be ready to submit registration the moment infrastructure opens.

Conclusion: Know What You're Getting Into

Becoming a Relying Party under eIDAS 2.0 is absolutely feasible—but it's not trivial. The registration requirements under Article 5b are clear, the technical standards are published, and the infrastructure is coming online mid-2026.

But clarity doesn't mean simplicity. DIY WRPAC registration is a significant commitment of time, money, and ongoing operational overhead. For large enterprises with dedicated resources, it may be the right strategic choice. For most businesses, the aggregator model (Article 5b(10)) offers a faster, simpler, more cost-effective path to compliance.

Before committing to DIY registration, ask yourself:

• Do we have 6-12 months and €150K+ to invest in Year 1?
• Do we have in-house compliance and legal expertise?
• Is complete control over the technical stack strategically important?
• Are we prepared for ongoing maintenance and compliance overhead?

If the answer to any of these is "no" or "maybe," seriously consider the aggregator path. If the answer to all is "yes," you have the roadmap above—and consulting services are available if you need expert guidance.

The deadline is December 2026. Choose your path wisely.

---

Need help navigating RP registration? eIDAS Pro offers consulting packages with complete documentation for your national authority, technical specifications guidance, and ongoing compliance advisory. Or skip registration entirely—use eIDAS Pro as your aggregator and be production-ready in days, not months.

Get Consulting Support | Use eIDAS Pro as Aggregator