eIDAS trust service role scoping workflow

Classify the role by the activity performed and the legal person responsible for it. Under eIDAS, a trust service is an electronic service normally provided for remuneration and includes issuing certificates, creating or validating electronic signatures or seals, preserving signatures, seals, or related certificates, managing remote creation devices, issuing or validating electronic attestations of attributes, creating or validating timestamps, registered delivery and related validation, electronic archiving, and recording data in an electronic ledger.

A relying party is a natural or legal person that relies on electronic identification, an EUDI Wallet, another electronic identification means, or a trust service. A bank, platform, employer, public body, or marketplace can be the relying party; an internal team may operate the process, but the role belongs to the relevant natural or legal person.

A trust service provider is the actor that provides one or more trust services. A qualified trust service provider is narrower: it provides one or more qualified trust services and has been granted qualified status by the supervisory body.

Do not treat marketing language, a procurement checklist, or use of a QTSP supplier as proof of qualified status. eIDAS ties qualified status to supervisory verification and trusted-list indication. A provider may begin providing the qualified trust service only after qualified status is indicated in the trusted lists.

Signature or seal validation can describe different activities. The organization may provide a qualified validation service, provide a non-qualified validation service, supply software that a customer operates under its own responsibility, or validate a signature or seal only for its own reliance. Classify the service provider from who performs and is responsible for the validation, not from whose software library is present.

For qualified electronic signatures, eIDAS validation checks include whether the supporting certificate was qualified and issued by a QTSP, whether it was valid at signing time, whether signature validation data corresponds to the relying-party data, whether the signatory data and any pseudonym indication are correctly provided, whether the signature was created by a qualified creation device, and whether signed-data integrity is intact.

A wallet relying party is a relying party that intends to use wallet units to provide public or private services by digital interaction. Article 5b requires registration in the Member State of establishment and disclosure of authentication information, contact details, and intended wallet use, including the data to be requested.

Commission Implementing Regulation (EU) 2025/848 adds the harmonised national-register, entitlement, access-certificate, registration-certificate, suspension, and cancellation rules. It is in force but applies from 24 December 2026. Commission Implementing Regulation (EU) 2026/1730, adopted on 15 July 2026 and entering into force on 11 August 2026, amends those rules to require Member States to authorise at least one registration-certificate authority and require automated issuance without undue delay after registration. Until 24 December 2026, distinguish preparation under Article 5b from completion of a registration under the applicable national process.

This role is separate from QTSP status. A wallet relying party requests or verifies wallet-presented data; it is not automatically a QTSP, a wallet provider, a PID provider, or an attestation provider.

The workflow output should be a role-scoping record that separates each transaction role before assigning controls, contracts, or regulatory owners. One legal entity can have more than one row if it performs different activities in different products or countries.

Keep the record specific enough that a reviewer can see why the organization is a provider, qualified provider, relying party, wallet relying party, validator, or QTSP customer without reading internal project history.