This page helps distinguish simple, advanced, and qualified electronic signatures under eIDAS and decide what proof a relying party should keep.
The focus is legal effect under Articles 25 to 28, qualified status in trusted lists, qualified-trust-service-provider checks, validation outputs, cross-border public-service recognition, and evidence that can be reviewed later.
Structured answer sets in this page tree.
Cited legal and guidance references.
eIDAS does not make every electronic signature legally equivalent to a handwritten signature. It protects electronic signatures from being rejected only because they are electronic, defines requirements, and gives qualified electronic signatures the equivalent legal effect of handwritten signatures. For relying parties, the practical question is therefore not only whether a document was signed electronically, but which signature level was used and what validation evidence proves it.
A simple electronic signature can still have legal effect and can be admissible as evidence; eIDAS Article 25 says it cannot be denied legal effect solely because it is electronic or because it is not qualified. That is a floor, not a guarantee that the signature will satisfy every contract, sector rule, public-service requirement, or evidentiary dispute.
An must be uniquely linked to the signatory, identify the signatory, be created with signature creation data the signatory can use under their sole control with a high level of confidence, and be linked to the signed data so later changes are detectable.
A is an created by a qualified electronic signature creation device and based on a qualified certificate for electronic signature. eIDAS gives QES the equivalent legal effect of a handwritten signature.
Signature validation answers whether the signature and its supporting certificate meet the selected validation criteria. It does not by itself prove that the signatory had corporate authority, that the document satisfies a separate statutory formality, or that the underlying contract is valid.
The qualified part of QES depends on more than a certificate file being present. The certificate must be a qualified certificate for electronic signature, issued by a qualified trust service provider, and valid at the time of signing.
eIDAS Annex I lists the information a qualified certificate must contain, including an indication suitable for automated processing that it was issued as a qualified certificate for electronic signature, data identifying the qualified trust service provider and its Member State, the signatory name or clearly marked pseudonym, certificate validity dates, a unique certificate identity code, status-service information, and an indication when the related creation data is located in a creation device.
Qualified status is operationally checked through Member State . eIDAS requires Member States to establish, maintain, and publish trusted lists with qualified trust service providers and qualified trust services, and ETSI explains that users benefit from the legal effect associated with a qualified trust service only when the service is listed as qualified.
For QES, eIDAS Article 32 describes what validation must confirm: the supporting certificate was qualified and valid at signing, the QTSP issued it, validation data corresponds to the relying-party data, the signatory data is correctly provided, any pseudonym is clear, the signature was created by a creation device, signed-data integrity is intact, and Article 26 advanced-signature requirements were met at signing.
For advanced electronic signatures based on qualified certificates, Article 32a follows a similar validation pattern but does not include the QSCD condition used for QES. That distinction matters when a workflow accepts AdES/QC but does not require full QES handwritten-signature equivalence.
Commission Implementing Regulation (EU) 2025/1945 has applied since 20 October 2025. It identifies reference standards for QES, qualified-seal, AdES/QC, and advanced-seal-on-qualified-certificate validation and for validation reports. Conformance gives the validation process a presumption of compliance; it does not turn an AdES/QC into a QES or replace the Article 32 checks.
A useful evidence pack should preserve the signed document or hash, signature format, validation policy, validation time, result, certificate chain, OCSP or CRL status data, trusted-list version or retrieval evidence, signatory identifier shown to the relying party, pseudonym indication if used, and any long-term validation or preservation material.
Article 27 addresses public-sector online services. If a Member State requires an for an online service offered by or on behalf of a public sector body, it must recognise advanced electronic signatures, advanced electronic signatures based on a qualified certificate, and qualified electronic signatures in the formats or methods defined by implementing acts.
If the public service requires an based on a qualified certificate, the Member State must recognise both that level and QES. For cross-border use of such public services, Member States may not request a higher security level than a .
For private contracts, eIDAS legal-effect rules still matter, but contract law, sector rules, formality requirements, and evidence practice may add separate questions. The page should therefore be used as an eIDAS signature-level and evidence guide, not as a substitute for transaction-specific legal review.
This checklist is relevant when approving a signing workflow, onboarding a signature provider, or reviewing a disputed signed record. The aim is to preserve enough evidence to explain why the organization treated a signature as SES, AES, AdES/QC, or QES at the time it relied on it.
The checklist is intentionally evidence-oriented because the legal value of an electronic signature is usually tested after the transaction, when teams must reconstruct signer identity, document integrity, certificate status, provider status, and validation results.
No. eIDAS protects electronic signatures from being rejected solely because they are electronic, but only a has the equivalent legal effect of a handwritten signature under Article 25.
An must be uniquely linked to the signatory, identify the signatory, be created using signature creation data under the signatory's sole control with a high level of confidence, and be linked to the signed data so later changes are detectable.
Keep the signed data, validation report, qualified certificate evidence, QTSP and qualified-service status from , revocation or suspension status, signatory information, QSCD or remote-QSCD evidence, and the time basis used for validation.
Sorena can help turn SES, AES, AdES/QC, and QES determinations into cited provider checks, validation evidence, escalation rules, and records that product, legal, procurement, security, and compliance teams can review.
Ask questions tied to cited sources about eIDAS signature levels, qualified certificates, QTSP status, trusted lists, and validation evidence.
Review your signature workflow, provider evidence, validation outputs, and cross-border recognition questions with Sorena.
"provider/service will be qualified only if it appears in the trusted lists"
"checked regularly for changes to the service status"
"secure cross-border transactions"
"Requirements for advanced electronic signatures"