WorkflowEU eIDAS

eIDAS signature legal effect selector workflow

Choose between simple electronic signature, advanced electronic signature, advanced signature based on a qualified certificate, and qualified electronic signature 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

May 9, 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 May 9, 2026

Overview

This workflow helps product, legal, procurement, and identity teams select the eIDAS signature level that matches the legal effect they need. It separates the evidential baseline for any electronic signature from the stricter requirements for an advanced electronic signature, an advanced electronic signature based on a qualified certificate, and a qualified electronic signature.

Section 1

Start with the legal effect you need

Under eIDAS, an electronic signature cannot be rejected in legal proceedings only because it is electronic or because it is not qualified. That makes a simple electronic signature useful for lower-risk evidence of intent, but it does not give the signature the same legal effect as handwriting.

Choose QES when the process needs the eIDAS rule that a qualified electronic signature has the equivalent legal effect of a handwritten signature. Choose AES or AES based on a qualified certificate when you need stronger identity, integrity, and validation evidence but do not need, or cannot support, the full QES chain.

Use SES for low-risk approvals where the main need is evidence that a person accepted or approved data electronically.
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 qualified certificate 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, cross-border public-sector recognition at the highest eIDAS signature level, or a high-assurance signing ceremony is required.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports the legal-effect split between ordinary electronic signatures and qualified electronic signatures, and the Article 26 requirements for advanced electronic signatures.

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. The decisive question is not whether a signature looks formal; it is whether the signing process can prove the required legal effect, identity assurance, certificate status, device status, and validation outcome at the time of signing.

Record the selected level, the reason lower levels are insufficient or sufficient, and the evidence source that proves the selected level.

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.
AES-QC selection: add proof that the supporting certificate was a qualified certificate 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 qualified certificate, and was created by a qualified electronic signature creation device, 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, AES-QC, and QES formats or methods.

Sources for this answer

Regulation (EU) No 910/2014 (eIDAS)

Supports the selector criteria for AES requirements, qualified certificates, qualified signature creation devices, validation, and public-service recognition.

ETSI EN 319 412-2 certificate profile for natural persons

Supports using certificate-profile evidence for EU qualified certificates, including QCStatements and interoperability of qualified certificate implementations.

ETSI TS 119 431-1 remote QSCD policy requirements

Supports remote QSCD evidence for server signing services, including policies for TSP services operating remote QSCD or signature creation devices.

Section 3

Validation evidence to keep with the signed record

For AES-QC 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, qualified certificate 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, statutory-form sensitive, or likely to be disputed. The escalation should decide whether QES is required, whether AES-QC is enough, whether a non-EU trust service can be accepted, and whether the relying party can validate the evidence without manual reconstruction.

Do not label a signature as QES unless the record supports all three parts: advanced-signature requirements, qualified certificate 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 source-linked questions 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

Supports using certificate-profile evidence for EU qualified certificates, including QCStatements and interoperability of qualified certificate implementations.

"EU Qualified Certificate requirements"

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.