---
title: "EUDI Wallet Relying Party Onboarding Workflow under eIDAS"
canonical_url: "https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation/wallet-onboarding-workflow"
source_url: "https://www.sorena.io/artifacts/eu/eidas/wallet-onboarding-workflow"
author: "Sorena AI"
description: "A grounded onboarding workflow for organisations that want to request data from European Digital Identity Wallet users as eIDAS wallet relying parties."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "eIDAS wallet relying party"
  - "EUDI Wallet onboarding"
  - "Article 5b"
  - "wallet attribute request"
  - "ARF"
  - "relying party registration"
  - "EU eIDAS Regulation"
  - "eIDAS"
  - "EUDI Wallet"
  - "wallet relying party"
  - "attribute requests"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# EUDI Wallet Relying Party Onboarding Workflow under eIDAS

A grounded onboarding workflow for organisations that want to request data from European Digital Identity Wallet users as eIDAS wallet relying parties.

*EU eIDAS wallet guide* *Relying party onboarding*

## EUDI Wallet Relying Party Onboarding Workflow

Use this workflow before a public or private service requests person identification data or electronic attestations of attributes from European Digital Identity Wallet users.

It focuses on the grounded onboarding record: relying-party role, registration information, intended use, requested data, presentation checks, user approval, validation evidence, and privacy controls.

Under eIDAS Article 5b, an organisation that intends to rely on European Digital Identity Wallets for public or private digital services must onboard as a wallet relying party before requesting data from users. This page turns that requirement into a practical workflow for service providers and intermediaries without adding unsupported penalty, deadline, or certification claims.

## 1. Confirm the relying-party role and service boundary

Start by documenting whether the organisation is the service provider that will request wallet attributes, or an intermediary acting for another relying party. eIDAS treats intermediaries acting on behalf of relying parties as relying parties, and the ARF describes a Relying Party Instance as the software and hardware used to interact with Wallet Units.

Keep the onboarding record at service level. A single organisation may have more than one intended use, and the ARF explains that separate intended uses may require separate presentation requests and registration information.

- Actor record: legal name, Member State of establishment, registration number if applicable, contact details, and whether an intermediary is involved.
- Service record: public or private service, user journey, online or proximity presentation, and the Relying Party Instance that will send requests to Wallet Units.
- Boundary check: distinguish the relying-party service from wallet provider, PID provider, QEAA provider, Pub-EAA provider, and non-qualified EAA provider roles.
- Intermediary check: if an intermediary requests attributes on behalf of a service provider, record the principal relying party and prohibit storage of transaction-content data by the intermediary.

Sources for this answer:

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/2024-10-18?ref=sorena.io) - Article 5b sets the registration and responsibility baseline for European Digital Identity Wallet relying parties, including intermediaries acting on their behalf.
- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - The ARF defines the service-provider-focused Relying Party role, Relying Party Instances, and the wallet presentation trust relationships.

## 2. Prepare the registration and intended-use evidence

Before requesting wallet data, prepare the Article 5b registration package for the Member State where the relying party is established. The grounded minimum record is not a generic vendor questionnaire: it is the data needed to authenticate to wallets, contact the relying party, and explain the intended wallet use and requested data.

Use one intended-use entry for each materially different service purpose. The ARF states that a Wallet Unit can compare the requested attributes with the attributes registered for the relying party and warn the user if the request exceeds the registered set or if registration information cannot be retrieved.

- Authentication information: Member State of establishment, relying-party name, and official registration number or official-record identifier where applicable.
- Contact information: operational and compliance contacts that can handle registration changes, user complaints, data-erasure requests, and suspicious-request reports.
- Intended use: concise service purpose, user journey, legal or business reason for wallet use, and whether identification is required or a pseudonym is sufficient.
- Requested data: each PID or attestation attribute, source attestation type, whether selective disclosure is possible, and why the service needs that attribute.
- Change control: owner and trigger for notifying the Member State without delay when registration information, intended use, contact details, or requested data changes.

Sources for this answer:

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/2024-10-18?ref=sorena.io) - Article 5b lists the minimum relying-party registration information and bars requests for data outside the registered indication.
- [Commission Implementing Regulation (EU) 2025/848](https://data.europa.eu/eli/reg%5Fimpl/2025/848/oj?ref=sorena.io) - The ARF cites this implementing regulation for registration of wallet-relying parties; use it as the implementing-act anchor for registration work where the local Member State process points to it.
- [European Commission - Wallet for service providers](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/881984674/Wallet+for+service+providers?ref=sorena.io) - Commission service-provider guidance summarises the registration, intended-use, requested-data, identification, validation, pseudonym, and change-notification expectations for organisations requesting wallet data.

## 3. Design the wallet data request before building the integration

Translate each intended use into a wallet presentation request that a user can understand. The service should request only the attributes recorded for that intended use, use selective disclosure where available, and avoid identity disclosure when a pseudonym or narrower proof is sufficient under the applicable service rules.

The request design should also account for embedded disclosure policies. The ARF describes disclosure policies that may tell the Wallet Unit whether an authenticated relying party is allowed to receive an attestation, and the Wallet Unit presents the outcome to the user.

- Attribute request matrix: intended-use identifier, requested attribute, attestation type such as PID, QEAA, Pub-EAA, or EAA, and the service decision the attribute supports.
- Minimisation check: remove attributes that are not required for the service decision, and record why a pseudonym is or is not sufficient.
- User-facing request text: relying-party identity, purpose, requested attributes, consequences of approval, and any disclosure-policy warning returned by the Wallet Unit.
- Protocol evidence: whether the request uses a wallet-supported protocol or interface for requesting and validating PID or electronic attestations of attributes.
- Exception handling: what the service does if the user rejects the request, if the wallet cannot retrieve registration information, or if an attestation policy warns against disclosure.

Sources for this answer:

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/2024-10-18?ref=sorena.io) - Article 5a requires wallet support for selective disclosure, user control, relying-party authentication, erasure requests, suspicious-request reporting, and privacy-preserving techniques.
- [Commission Implementing Regulation (EU) 2024/2979](https://eur-lex.europa.eu/eli/reg_impl/2024/2979/oj/eng?ref=sorena.io) - The ARF ties embedded disclosure-policy support for electronic attestations of attributes to the wallet integrity and core-functionality implementing rules.
- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - The ARF describes the registration-attribute comparison, disclosure-policy evaluation, and user approval steps for PID or attestation presentation to a relying party.

## 4. Implement relying-party authentication, validation, and logging controls

The onboarding gate should not close until the technical team can prove the Relying Party Instance authenticates to Wallet Units and validates wallet evidence after the user approves the presentation. The ARF presentation flow includes access certificates, trust anchors, request signatures, certificate-chain validation, revocation checking, issuer signature validation, attestation revocation checks, and device-binding checks where relevant.

Keep evidence that explains both sides of the interaction: what the wallet can verify about the relying party before asking the user, and what the relying party verifies about the received PID or attestation before relying on it.

- Access-certificate evidence: issuing authority, certificate chain, relying-party identity fields, intended-use linkage, expiry and revocation-check method.
- Request-signing evidence: signed request payload, requested attributes, intended-use reference, nonce or replay-protection mechanism where applicable, and protocol version.
- Wallet-side evidence: test showing that the Wallet Unit can authenticate the relying party and warn when requested attributes exceed registered attributes.
- Relying-party validation evidence: issuer signature validation, attestation or PID revocation status check, wallet authenticity check, and device-binding or user-binding check where the use case requires it.
- Operational logs: user approval result, attributes actually received, validation result, rejection reason, erasure-request handling path, and suspicious-request escalation path.

Sources for this answer:

- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - The ARF presentation lifecycle defines relying-party authentication, registered-attribute verification, user approval, issuer-signature validation, revocation checks, and binding checks.
- [Commission Implementing Regulation (EU) 2024/2982](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L%5F202402982&ref=sorena.io) - Commission implementing rules identify protocols and interfaces for wallet solutions, including relying-party request and validation interfaces referenced by the Commission implementing-regulation page.
- [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission overview page links the five wallet implementing regulations, including core functionality, protocol/interface, PID/EAA, certification, and ecosystem-notification measures.

## 5. Add privacy, security, and review gates before launch

The final onboarding review should be a privacy and security gate, not a marketing launch checklist. eIDAS requires wallet users to have control over wallet data and Article 5b limits relying parties to the registered data indication; the ARF identifies over-collection, impersonation, message interception, message tampering, and linkability as risks to address in the wallet ecosystem.

Close the workflow only when the service can show that it requests no more than registered attributes, identifies itself to the user, validates received evidence, accepts pseudonyms where identification is not legally required, and has a change process for registration updates.

- Data minimisation: the production request exactly matches the registered intended use and requested attributes.
- User control: the wallet interaction supports user approval or rejection and does not treat wallet approval as a standalone GDPR lawful basis.
- Pseudonym handling: the service accepts pseudonyms where user identification is not required by Union or national law, and records any reason identity is required.
- Security controls: mutual authentication, encrypted communication, signed requests or responses, certificate-chain validation, revocation checks, and replay-protection evidence are tested.
- Linkability controls: discard unique fixed attestation elements when no longer needed, avoid cross-service correlation, and limit logs to the service evidence needed for audit, fraud, support, erasure, and dispute handling.
- Reopen triggers: new intended use, new requested attribute, new Relying Party Instance, intermediary change, registration-data change, protocol or certificate change, suspicious-request report, or failed validation control.

Sources for this answer:

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/2024-10-18?ref=sorena.io) - Article 5a and Article 5b ground the wallet user-control, privacy, registration, data-request, pseudonym, validation, and change-notification controls used in this launch gate.
- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - The ARF risk discussion supports the security and privacy controls for relying-party requests, including selective disclosure, registered requested attributes, disclosure policies, and linkability mitigation.
- [European Commission - Wallet for service providers](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/881984674/Wallet+for+service+providers?ref=sorena.io) - Commission service-provider guidance lists operational obligations such as not requesting extra data, identifying to users, validating PID and EAA data, accepting pseudonyms where appropriate, and notifying Member States about registration changes.

*EU eIDAS wallet next step*

*Placement: before sources*

## Use this workflow to prepare wallet data requests and evidence

Sorena can help convert your intended wallet use, requested attributes, registration evidence, validation controls, and privacy gates into a practical onboarding record for eIDAS wallet relying-party work.

- [Open Research Copilot for EU eIDAS](/solutions/research-copilot.md): Ask source-linked questions about EUDI Wallet relying-party registration, attribute requests, ARF controls, and onboarding evidence using the cited sources on this page.
- [Review a wallet onboarding plan](/contact.md): Check your relying-party role, requested data, registration evidence, validation controls, and privacy gates before launching wallet requests.

## Primary sources

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/2024-10-18?ref=sorena.io) - Primary legal source for Article 5a wallet controls and Article 5b wallet relying-party registration, data-request, pseudonym, validation, and intermediary rules.
  - Quote: "European Digital Identity Wallet-Relying Parties"
- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main.pdf?ref=sorena.io) - Technical architecture source for relying-party role definitions, Relying Party Instances, registration certificates, access certificates, presentation flow, validation checks, disclosure policies, and risk controls.
  - Quote: "Architecture and Reference Framework"
- [European Commission - Wallet for service providers](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/881984674/Wallet+for+service+providers?ref=sorena.io) - Commission-facing guidance for service providers that request data from wallet users, including examples, requested data types, registration requirements, operational requirements, and change obligations.
  - Quote: "Learn how organisations can request data from wallet users"
- [European Commission - Implementing regulation for European Digital Identity Wallets](https://digital-strategy.ec.europa.eu/en/library/implementing-regulation-european-digital-identity-wallets?ref=sorena.io) - Commission overview of the adopted EUDI Wallet implementing regulations covering core functionality, protocols and interfaces, PID and EAA, certification, and ecosystem notifications.
  - Quote: "five implementing regulations"
- [Commission Implementing Regulation (EU) 2024/2979](https://eur-lex.europa.eu/eli/reg_impl/2024/2979/oj/eng?ref=sorena.io) - Wallet integrity and core-functionality implementing regulation referenced for wallet controls that affect relying-party presentation requests and disclosure-policy handling.
  - Quote: "integrity and core functionalities"
- [Commission Implementing Regulation (EU) 2024/2982](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L%5F202402982&ref=sorena.io) - Wallet protocols and interfaces implementing regulation referenced for relying-party request and validation integrations.
  - Quote: "protocols and interfaces"
- [Commission Implementing Regulation (EU) 2025/848](https://data.europa.eu/eli/reg%5Fimpl/2025/848/oj?ref=sorena.io) - Implementing-regulation anchor cited by the ARF for registration of wallet-relying parties.
  - Quote: "registration of wallet-relying parties"

## Related Topic Guides

- [eIDAS 2 deadlines and compliance calendar for EUDI Wallet and trust services](/artifacts/eu/eidas/deadlines-and-compliance-calendar.md): Calendar of grounded eIDAS and eIDAS 2 milestones for EUDI Wallet delivery, implementing acts, annual supervision reports, QTSP transitions, pilots, and ARF evidence.
- [eIDAS 2.0 vs eIDAS: EUDI Wallet and trust-service changes](/artifacts/eu/eidas/eidas2-vs-eidas.md): Compare the original eIDAS electronic identification and trust-service framework with the eIDAS 2.0 amendments for EUDI Wallets, relying parties, attestations, QWACs, and supervision.
- [eIDAS Certificates and Authentication: qualified certificates, QWACs, and validation checks](/artifacts/eu/eidas/certificates-and-authentication.md): Grounded guide to eIDAS qualified certificates, website authentication certificates, trusted lists, relying-party checks, and validation evidence.
- [eIDAS checklist and evidence pack for trust services, signatures, and EUDI Wallet relying parties](/artifacts/eu/eidas/checklist-and-evidence.md): Build an eIDAS evidence pack for qualified trust services, electronic signatures, trusted-list checks, certificate validation, supervisory records, and EUDI Wallet relying-party controls.
- [eIDAS compliance guide for trust services, QTSPs, signatures, and EUDI Wallet relying parties](/artifacts/eu/eidas/compliance.md): Grounded eIDAS compliance guide for trust-service classification, QTSP supervision evidence, qualified signatures, seals, time stamps, certificates, trusted-list validation, and EUDI Wallet relying-party records.
- [eIDAS electronic signatures: SES, AES, QES legal effect and evidence](/artifacts/eu/eidas/electronic-signatures-and-legal-effect.md): A grounded guide to eIDAS electronic-signature legal effect: SES, AES, QES, qualified certificates, QTSP trusted-list checks, validation, recognition, and evidence records.
- [eIDAS penalties and fines for trust service providers](/artifacts/eu/eidas/penalties-and-fines.md): Grounded guide to eIDAS Article 16 penalties, administrative fine mechanics, supervisory bodies, qualified-status withdrawal, and trusted-list evidence.
- [eIDAS QES validation checks for relying parties](/artifacts/eu/eidas/qes-validation.md): How to validate a qualified electronic signature under eIDAS: certificate, QTSP, trusted-list, QSCD, integrity, validation result, and evidence records.
- [eIDAS Qualified Trust Services: QTSP Selection](/artifacts/eu/eidas/qualified-trust-services-and-qtsp-selection.md): How to select an EU eIDAS qualified trust service provider: identify the qualified service type, verify trusted-list status, review supervision evidence, and retain certificate-policy records.
- [eIDAS remote signature and cloud HSM controls for QTSPs](/artifacts/eu/eidas/remote-signature-and-cloud-hsm-controls.md): Grounded guide to eIDAS remote signature controls: remote QSCD scope, server-side signing, QTSP evidence, signer authentication, certificate validation, and trusted-list checks.
- [eIDAS signature legal effect selector: SES, AES, AES-QC, or QES](/artifacts/eu/eidas/signature-legal-effect-selector-workflow.md): Select the right eIDAS signature level by legal effect, risk, qualified certificate status, QTSP evidence, QSCD use, validation result, and cross-border recognition.
- [eIDAS trust service role scoping workflow: TSP, QTSP, validator, relying party, or QTSP customer](/artifacts/eu/eidas/trust-service-role-scoping-workflow.md): Classify an eIDAS role by evidence: trust service provider, qualified trust service provider, signature or seal validator, EUDI Wallet relying party, relying party, or customer of a QTSP.
- [eIDAS trusted list validation: LOTL, QTSP status, and evidence](/artifacts/eu/eidas/trust-list-validation.md): How to validate EU eIDAS trusted-list evidence: start from the Commission LOTL, confirm QTSP and qualified-service status, check certificate path and revocation data, and retain validation reports.
- [eIDAS vs ESIGN and UETA: EU qualified signatures vs U.S. e-signature laws](/artifacts/eu/eidas/eidas-vs-esign-and-ueta.md): Compare eIDAS with ESIGN and UETA for electronic signatures, qualified certificates, trust services, cross-border recognition, validation evidence, and source gaps.
- [eIDAS vs ETSI EN 319 401: legal supervision and TSP policy requirements](/artifacts/eu/eidas/eidas-vs-etsi-en-319-401.md): Compare eIDAS and ETSI EN 319 401 for trust services: legal scope, QTSP supervision, conformity assessment, audits, incident evidence, and operational controls.
- [eIDAS vs GDPR for identity data: wallet, trust-service, and privacy obligations](/artifacts/eu/eidas/eidas-vs-gdpr-identity-data.md): Compare eIDAS identity, trust-service, and EUDI Wallet rules with GDPR duties for personal-data processing, minimisation, lawful basis, evidence, security, and user rights.
- [eIDAS vs NIS2 for trust service providers: QTSP and cybersecurity obligations](/artifacts/eu/eidas/eidas-vs-nis2-trust-services.md): Compare eIDAS trust-service and QTSP duties with NIS2 cybersecurity risk-management, incident reporting, supervision, and evidence duties for trust service providers.
- [Electronic Attestations of Attributes under EU eIDAS: EAA, QEAA, issuers, wallets, and validation](/artifacts/eu/eidas/electronic-attestations-of-attributes.md): Grounded guide to electronic attestations of attributes under amended EU eIDAS: EAA, QEAA, public-sector authentic-source attestations, wallet use, issuer checks, relying-party validation, revocation, and legal effect.
- [EU eIDAS Applicability Test for Trust Services, Wallets, and Certificates](/artifacts/eu/eidas/applicability-test.md): A grounded eIDAS scope test for QTSPs, trust services, electronic signatures, seals, timestamps, QWACs, EUDI Wallet relying parties, and cross-border recognition evidence.
- [EU eIDAS attribute attestations: EAA, QEAA, wallet, and relying party checks](/artifacts/eu/eidas/faq/attribute-attestations.md): What electronic attestations of attributes mean under eIDAS, how QEAAs differ from public-sector and non-qualified attestations, and what issuers, wallets, and relying parties should verify.
- [EU eIDAS checklist for signatures, trust services, and wallets](/artifacts/eu/eidas/checklist.md): Checklist for eIDAS trust-service and EUDI Wallet controls: qualified status, trusted lists, certificates, signatures, seals, timestamps, validation evidence, and relying-party records.
- [EU eIDAS FAQ: signatures, QTSPs, trusted lists, QWACs, wallets, and validation](/artifacts/eu/eidas/faq.md): FAQ on eIDAS trust services and the European Digital Identity framework, covering advanced and qualified electronic signatures, QTSP status, trusted lists, QWACs, EUDI Wallet relying parties, attestations of attributes, and validation evidence.
- [EU eIDAS QTSP authorization and supervision guide](/artifacts/eu/eidas/qtsp-authorization-and-supervision.md): How qualified trust service providers obtain and keep qualified status under eIDAS, including conformity assessment reports, supervision, trusted lists, incidents, and evidence.
- [EU eIDAS QTSP Due Diligence Workflow for Trusted Lists, Certificates, and Evidence](/artifacts/eu/eidas/qtsp-due-diligence-workflow.md): Check a qualified trust service provider under eIDAS by validating trusted-list status, qualified service scope, certificates, policies, supervision, audits, and retained evidence.
- [EU eIDAS Requirements for Trust Services, Signatures, Seals, Wallets, and Evidence](/artifacts/eu/eidas/requirements.md): Grounded guide to core eIDAS requirements for trust service providers, qualified trust services, electronic signatures, seals, time stamps, trusted lists, and EUDI Wallet relying parties.
- [EU eIDAS Trusted Lists FAQ: LOTL, QTSP status, and validation evidence](/artifacts/eu/eidas/faq/trusted-lists.md): How EU eIDAS Trusted Lists and the Commission LOTL support QTSP and qualified trust-service validation, with practical evidence checks for relying parties.
- [EUDI Wallet readiness for service providers under eIDAS](/artifacts/eu/eidas/eudi-wallet-readiness.md): Readiness guide for organisations preparing to request or verify data from European Digital Identity Wallets: roles, registration, ARF alignment, selective disclosure, implementing acts, and evidence.
- [EUDI Wallet Relying Parties under eIDAS](/artifacts/eu/eidas/faq/eudi-wallet-relying-party.md): What EUDI Wallet relying parties must do under eIDAS: register, declare intended wallet use and requested data, identify themselves to users, and keep request evidence.
- [EUDI Wallet Relying Party Registration Under eIDAS](/artifacts/eu/eidas/eudi-wallet-relying-party-registration.md): What eIDAS Article 5b and the EUDI Wallet ARF say about wallet relying party registration, intended uses, attribute requests, certificates, evidence, and Member State gaps.
- [EUDI Wallet Technical Architecture Guide under eIDAS](/artifacts/eu/eidas/eudi-wallet-technical-architecture-guide.md): Technical guide to the EUDI Wallet architecture: ARF roles, wallet units, PID and attestations, relying parties, trust model, certificates, protocols, privacy, and security controls.
- [QES vs AdES under EU eIDAS: legal effect, certificates, QTSPs, and validation evidence](/artifacts/eu/eidas/faq/qes-vs-ades.md): Compare qualified electronic signatures (QES) and advanced electronic signatures (AdES) under EU eIDAS, including legal effect, qualified certificates, QTSP status, QSCDs, and validation evidence.
- [QWACs under eIDAS: website authentication certificates](/artifacts/eu/eidas/qwacs.md): A grounded guide to qualified website authentication certificates under eIDAS, covering Annex IV data, trusted lists, browser recognition, validation evidence, and QTSP checks.
- [What eIDAS Covers: eID, Trust Services, EUDI Wallet, and QWACs](/artifacts/eu/eidas/what-eidas-covers.md): A grounded guide to the systems and services covered by EU eIDAS: notified electronic identification, trust services, signatures, seals, time stamps, registered delivery, website authentication, trusted lists, the EUDI Wallet, and attribute attestations.
- [What is a qualified trust service provider under eIDAS?](/artifacts/eu/eidas/faq/qualified-trust-service-provider.md): How to verify QTSP status under eIDAS using the qualified service, supervisory body decision, trusted list entry, conformity assessment evidence, and service-specific records.
- [What is a QWAC under the EU eIDAS Regulation?](/artifacts/eu/eidas/faq/qwac.md): Plain-language FAQ on qualified website authentication certificates under eIDAS, including website identity, QTSP trusted-list checks, browser recognition, and validation evidence.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/eidas/wallet-onboarding-workflow