A practical guide to the eIDAS requirements that matter most for trust services, qualified certificates, electronic signatures, seals, time stamps, trusted lists, and EUDI Wallet integrations.
Use it to separate provider duties, relying-party checks, validation evidence, and wallet data-request obligations without treating every electronic signature or identity flow as qualified.
Structured answer sets in this page tree.
Cited legal and guidance references.
requirements start with the actor and the exact electronic-identification or trust-service function, not with a supplier's product label. Regulation (EU) No 910/2014, as amended by Regulation (EU) 2024/1183, controls signing, sealing, timestamping, certificate, wallet, attestation, archiving, ledger, and validation workflows. A has regulatory and supervision duties; a customer, relying party, or verifier usually needs evidence of the provider-service status, certificate status, wallet registration, and transaction-level validation result it relied on.
covers electronic identification, trust services, electronic signatures, electronic seals, electronic time stamps, electronic registered delivery, website authentication certificates, electronic attestations of attributes, electronic archiving, electronic ledgers, and the European Digital Identity Wallet. A requirements review should start by naming the service and the actor: trust service provider, , wallet provider, relying party, issuer, signatory, seal creator, browser provider, or customer relying on a certificate or validation result.
Do not label a workflow as qualified only because it is electronic or cryptographic. Qualified status depends on the legal category, the provider's status, the certificate or device requirements, and trusted-list evidence. ETSI and other referenced standards specify technical controls or support a presumption of compliance where an applicable EU act says so; a standards claim alone does not grant qualified status.
A must be treated as a regulated provider, not only as a technology supplier. Before starting a qualified trust service, the provider must notify the supervisory body and submit a conformity assessment report. Qualified providers are audited at their own expense at least every 24 months by a conformity assessment body, and they must submit the resulting report to the supervisory body within three working days of receipt.
The operational requirements include identity or attribute verification before issuing qualified certificates or qualified electronic attestations of attributes, clear terms and limitations before contracting, trustworthy systems, reliable stored data, risk-management policies, security-breach and disruption notification, measures against forgery or misappropriation, accessible records for evidence and continuity, termination planning, and certificate databases where qualified certificates are issued.
Non-qualified trust service providers do not follow the qualified-status initiation and recurring conformity-assessment process merely because they provide a trust service. They still need a separate requirements record for duties that apply to trust service providers generally, including security risk management, significant-incident notification, liability exposure, and any service-specific implementing rules.
gives electronic signatures and electronic seals legal-effect rules, but qualified status still requires specific supporting evidence. A qualified electronic signature has the equivalent legal effect of a handwritten signature; a qualified electronic seal carries presumptions about data integrity and origin; and a qualified electronic time stamp carries presumptions about the accuracy of date and time and integrity of the bound data.
For validation, the evidence record should prove the certificate status at signing, the provider's qualified status, the integrity of the signed or sealed data, the signatory or seal-creator information made available to the relying party, the qualified signature or seal creation device where required, and any pseudonym indication. A validation result alone is weak if it cannot be tied back to the trusted list, certificate status, signed object, and time of validation.
A relying party that intends to rely on European Digital Identity Wallets for public or private digital services must register in the Member State where it is established. The registration must include information needed to authenticate to wallets, contact details, and the intended wallet use, including the data the relying party will request from users.
After registration, the relying party must not ask wallet users for data beyond the registered purpose, must identify itself to the user, must authenticate and validate person identification data and electronic attestations of attributes requested from wallets, must inform the Member State without delay about registration-information changes, and must not refuse pseudonyms where user identification is not required by Union or national law. Intermediaries acting on behalf of relying parties are treated as relying parties and must not store data about the content of the transaction.
are central evidence under . Each Member State must establish, maintain, and publish trusted lists containing information on qualified trust service providers and their qualified trust services. A may begin providing a qualified trust service only after qualified status has been indicated in the trusted list.
A relying party should therefore preserve the trusted-list result used for each material decision: whether a provider was qualified, whether the specific service was qualified, whether a certificate or attestation was valid or revoked, and whether the trusted-list data was current when checked.
The minimum useful evidence package is a role-and-service classification, a source citation, status proof, and transaction-level validation evidence. It should be possible for a reviewer to reconstruct why a signature, seal, timestamp, wallet request, certificate, attestation, or provider status was accepted at the time of use.
The checklist below is intentionally evidence-first. It avoids broad compliance claims and focuses on records that prove the actual requirement that applied.
First classify the actor and service: trust service provider, , relying party, wallet provider, issuer, signatory, seal creator, or customer relying on a validation result. Then verify whether the specific service is qualified and whether trusted-list or wallet-registration evidence is required.
Keep the signed object, the validation result, the qualified certificate status at signing, the QTSP and service status from the trusted list, evidence that the qualified signature creation device requirement was met, and proof that the signed data integrity was not compromised.
For a defensible record, keep the Member State registration record, relying-party identity and contact details, intended wallet use, requested data categories, user-facing request evidence, PID or EAA validation records, pseudonym handling rationale, and updates sent to the Member State.
Sorena can help convert these eIDAS requirements into role classification, trusted-list checks, validation evidence, wallet relying-party records, and review-ready source citations.
Ask questions tied to cited sources about eIDAS trust services, wallet roles, validation records, and qualified-status evidence using the cited sources on this page.
Review your eIDAS service classification, trusted-list checks, and evidence plan with Sorena.
"Collection of evidence"
"Trusted Lists"
"Architecture and Reference Framework"
"Register in the Member State"
"intended use of European Digital Identity Wallets"
"for the purpose of providing evidence"