WorkflowEU eIDAS

eIDAS signature legal effect selector workflow

Compare an electronic signature, often called SES, with AES, AES based on a qualified certificate, and QES under eIDAS.

Use the selector when a contract, public-service form, onboarding flow, approval record, or regulated transaction needs a defensible signature level and reusable validation evidence.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 24, 2026

Overview

Start with the transaction's governing law and required form, then choose the lowest signature level that satisfies that requirement and the evidence risk. eIDAS defines electronic signature, , and ; simple electronic signature, or SES, is common shorthand for an electronic signature that is not claimed as advanced or qualified. This workflow cannot decide whether national or sector law requires a signature, notarisation, witnessing, or another formality.

Section 1

Start with the legal effect you need

Under eIDAS, an electronic signature cannot be denied legal effect or admissibility as evidence solely because it is electronic or not qualified. That rule prevents automatic rejection; it does not guarantee that any electronic signature proves identity, intent, integrity, or compliance with a national form requirement.

Choose QES when the process needs the eIDAS rule that a has the equivalent legal effect of a handwritten signature. Choose AES or AES based on a when the applicable rule and risk accept that level. A qualified certificate adds certificate and QTSP evidence, but is not QES unless a was also used and all QES conditions are met.

Consider SES for approvals where the governing rules do not require AES or QES and the retained authentication, intent, content, and integrity evidence is proportionate to the dispute risk.
Use AES when the risk requires a signature uniquely linked to and capable of identifying the signatory, under the signatory's sole control, with later changes to the signed data detectable.
Use AES based on a when the public-service or relying-party requirement asks for an advanced signature with a qualified certificate, but not necessarily QES.
Use QES when handwritten-signature equivalence is required and the transaction can satisfy any additional national or sector-specific form rules. For cross-border public services, apply Article 27's recognition rules to the level the service requires.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Articles 25 to 27 support the legal-effect distinction, the AES requirements, and the recognition rules for signatures used in online public services.

European Commission Digital Building Blocks - eSignature

Supports practical use of eSignature standards, tools, DSS, trusted-list browser resources, and validation tests for EU electronic signature creation and verification.

Section 2

Selector criteria for SES, AES, AES-QC, and QES

Run the selector before choosing a vendor or signature widget. Record the governing law, transaction type, any statutory or contractual form requirement, the relying party's acceptance rule, and the evidence needed if the signature is challenged.

Then record the selected level and the evidence that supports it. Do not call an outcome QES from the product label alone; the validation record must support the advanced-signature requirements, , issuing QTSP, certificate validity at signing time, QSCD use, and signed-data integrity.

SES selection: retain the signed content, signer identifier used in the journey, consent or approval event, authentication context, timestamp, IP or device evidence where collected, and integrity controls around the stored record.
AES selection: add evidence that the signature is uniquely linked to the signatory, identifies the signatory, uses signature creation data under the signatory's sole control, and detects later changes to the signed data.
selection: add proof that the supporting certificate was a for electronic signature, issued by a qualified trust service provider, valid at signing time, and not suspended or revoked for the relevant period.
QES selection: add proof that the signature is advanced, uses a , and was created by a , including remote QSCD evidence where a QTSP manages the device.
Cross-border public service check: if a Member State requires advanced signatures for an online public-sector service, check whether eIDAS Article 27 recognition rules require accepting AES, , and QES formats or methods.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports the selector criteria for AES, AES based on a qualified certificate, QES, qualified certificates, QSCDs, validation, and public-service recognition.

ETSI EN 319 412-2 certificate profile for natural persons

Defines certificate-profile requirements for qualified certificates issued to natural persons; use it with the applicable QCStatements profile and trusted-list evidence.

ETSI TS 119 431-1 remote QSCD policy requirements

Sets policy and security requirements for TSP services operating a remote QSCD or signature creation device, including signature activation and sole-control controls.

Section 3

Validation evidence to keep with the signed record

For and QES, validation evidence should show more than a cryptographic pass or fail. It should show whether the certificate was qualified at signing time, whether the QTSP and service had qualified status, whether the certificate was valid for the relevant moment, and whether the signature was created with a QSCD where QES is claimed.

Use trusted lists as part of the evidence chain. eIDAS requires Member States to establish, maintain, and publish trusted lists with information about qualified trust service providers and their qualified services; ETSI TS 119 612 defines trusted-list status fields used by validation systems.

Store the validation report, validation policy, signature format, signed document digest, signing time or best-signature-time basis, certificate chain, and revocation evidence.
For qualified-certificate claims, store the certificate identity, issuer QTSP, indication, certificate validity period, revocation or suspension status source, and the trusted-list entry used.
For QES claims, store the QSCD indication or qualification determination and the evidence that the certificate and device status were valid at signing time.
For remote signing, store the QTSP service identity, remote QSCD service status, signature activation evidence, and the source showing the QTSP was qualified for the relevant service.
For rejected or downgraded signatures, keep the failed validation reason separately from the business decision to accept, re-sign, escalate, or reject the transaction.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports the validation checks for QES and AES based on qualified certificates, including certificate status, QTSP issuance, signatory data, integrity, and QSCD use.

ETSI TS 119 612 trusted lists

Supports using EU Member State trusted lists, the List Of Trusted Lists, service current status, and service history as evidence for QTSP and qualified-service status.

European Commission Digital Building Blocks - eSignature

Supports practical validation tooling references such as the eIDAS dashboard, trusted-list browser, DSS resources, and validation tests.

Section 4

Escalation rules for high-risk or cross-border signatures

Escalate the selector when the transaction is cross-border, public-sector facing, high value, subject to a statutory form, or likely to be disputed. Legal review should determine the governing form rule and whether electronic execution is permitted. Technical and procurement review should then determine whether QES is required, whether is enough, whether a non-EU trust service can be recognised, and whether the relying party can validate the evidence.

Do not label a signature as QES unless the record supports all three parts: advanced-signature requirements, status, and QSCD creation. A qualified certificate alone is not enough for QES if the device evidence is missing.

Escalate to legal when the relying party asks for handwritten-signature equivalence or when national law may require a particular signature level.
Escalate to identity architecture when the chosen journey cannot preserve sole-control evidence, certificate qualification evidence, or signed-data integrity evidence.
Escalate to procurement when a vendor claims QTSP, QES, or remote QSCD support but cannot identify the qualified service on an EU trusted list.
Escalate to operations when validation depends on live trusted-list, OCSP, CRL, timestamp, or preservation services that are not monitored or retained.
Escalate to compliance when accepting third-country trust services, because eIDAS recognition of third-country qualified-equivalent services depends on implementing acts or an EU agreement.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports escalation points for QES requirements, cross-border recognition within Member States, qualified trust services, and third-country trust-service recognition.

ETSI TS 119 612 trusted lists

Supports checking whether the QTSP service status was granted, withdrawn, ceased, or historically valid at the relevant signing or validation time.

ETSI TS 119 431-1 remote QSCD policy requirements

Supports escalation when a remote signing service claims remote QSCD support, server signing, or signature activation under sole-control requirements.

Recommended next step

Turn the SES, AES, AES-QC, or QES choice into reusable evidence

Sorena can help convert this selector into a signature-level record, vendor evidence checklist, trusted-list validation pack, and acceptance criteria for EU eIDAS workflows.

Research workflow

Open Research Copilot for eIDAS signatures

Ask questions tied to cited sources about eIDAS signature levels, qualified certificates, QTSP evidence, QSCD support, and validation records using the cited sources on this page.

Explore next step

Talk to Sorena

Review an eIDAS signature workflow

Check whether a signing journey is aiming for SES, AES, AES-QC, or QES and whether the retained evidence supports that claim.

Explore next step

Primary sources

References and citations

ETSI EN 319 412-2 certificate profile for natural persons

etsi.org

Referenced sections

Defines certificate-profile requirements for qualified certificates issued to natural persons; use it with the applicable QCStatements profile and trusted-list evidence.

ETSI TS 119 431-1 remote QSCD policy requirements

etsi.org

Referenced sections

Supports escalation when a remote signing service claims remote QSCD support, server signing, or signature activation under sole-control requirements.

"signature activation data submission under sole control"

ETSI TS 119 612 trusted lists

etsi.org

Referenced sections

Supports checking whether the QTSP service status was granted, withdrawn, ceased, or historically valid at the relevant signing or validation time.

"trusted lists of all Member States"

European Commission Digital Building Blocks - eSignature

ec.europa.eu

Referenced sections

Supports practical validation tooling references such as the eIDAS dashboard, trusted-list browser, DSS resources, and validation tests.

"Trusted List Browser"

Regulation (EU) No 910/2014 (eIDAS)

eur-lex.europa.eu

Referenced sections

Supports escalation points for QES requirements, cross-border recognition within Member States, qualified trust services, and third-country trust-service recognition.