Choosing between an advanced electronic signature (AdES) and a qualified electronic signature (QES) under eIDAS decides who carries the burden of proof in a dispute, which devices and providers you depend on, and whether a signature will be accepted in another Member State. Both levels rely on certificates and cryptography, and from the outside a PAdES file signed at either level can look identical. The differences sit in the certificate, the signature creation device, the provider's supervision status and the legal presumption that follows. This guide is for security architects, legal operations and product teams who must pick a level for people, organisations and automated systems, including electronic seals used by machines. It builds on the Digital Signature vs Electronic Signature page, which covers the legal versus cryptographic distinction, and goes deeper on the AdES and QES decision.
Status line (checked 14 November 2026): this page is based on Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183, using the EUR-Lex consolidated text dated 18 October 2024, and on Commission Implementing Regulation (EU) 2026/248 on signature and seal formats. Implementing acts under eIDAS 2.0 are still being adopted and applied in stages, so confirm the current text before relying on any date.
Key takeaways
- Only QES has statutory handwritten equivalence. Article 25(2) gives a QES the equivalent legal effect of a handwritten signature; an AdES is admissible under Article 25(1) but its reliability must be shown if challenged.
- QES is AdES plus two things. Article 3(12) defines a QES as an AdES created by a qualified signature creation device (QSCD) and based on a qualified certificate; take either away and it is an AdES.
- Remote QES is now explicit. Articles 29a and 3(23a) let only a qualified trust service provider manage a remote QSCD on the signatory's behalf, with backup copies limited and protected to the same level.
- Cross-border recognition moved to Article 24a. Qualified signatures, seals, certified QSCDs and remote QSCD management from one Member State are recognised in all others; public bodies must also accept AdES formats set by implementing act.
- Machines seal, people sign. Organisations and their automated systems use electronic seals (Articles 35 to 40); a qualified seal carries a presumption of integrity and correct origin, not of a person's intent.
The short answer
Use an AdES when you need a signature cryptographically linked to an identified signer and to the data, but no law or counterparty demands handwritten equivalence: internal approvals, B2B contracts with moderate value, and workflows where you control onboarding. Use a QES when national or sector law requires a handwritten signature or written form that only QES satisfies, when a contracting authority asks for it, when the counterparty is likely to dispute the signature, or when you need automatic recognition across Member States without arguing reliability. Use a seal (advanced or qualified) when the signer is an organisation or a system rather than a person. eIDAS itself does not list which documents need QES; that requirement comes from other EU, national or contractual rules.
Side by side
| Dimension | Advanced electronic signature (AdES) | Qualified electronic signature (QES) |
|---|---|---|
| Definition | Art. 3(11): meets Art. 26 | Art. 3(12): AdES created by a QSCD and based on a qualified certificate |
| Technical requirements | Art. 26: uniquely linked to and capable of identifying the signatory, created with data under the signatory's sole control with a high level of confidence, later changes detectable | All of Art. 26, plus a QSCD meeting Annex II and a qualified certificate meeting Annex I |
| Certificate | Any certificate, including an internal CA or a non-qualified public CA | Qualified certificate issued by a qualified trust service provider (QTSP) on a national trusted list |
| Identity proofing | Set by the issuer and your policy | Art. 24(1a): EU Digital Identity Wallet or notified eID at level high, an existing qualified certificate, another method confirmed by a conformity assessment body, or physical presence |
| Signature device | Any, provided sole control holds (software keystore, token, HSM) | Certified QSCD (smart card, token or remote QSCD managed by a QTSP) |
| Legal effect | Art. 25(1): not denied effect or admissibility for being electronic or non-qualified | Art. 25(2): equivalent legal effect of a handwritten signature |
| Cross-border | Depends on the relying party; public bodies must accept listed formats under Art. 27 | Art. 24a(1): recognised as QES in all Member States |
| Validation | Against your policy and trust anchors | Art. 32 conditions, optionally by a qualified validation service |
| Cost and friction | Lower; reuses existing PKI and identity checks | Higher; high-level identity proofing, QSCD and QTSP fees |
Between the two sits a level the Regulation names explicitly in Articles 27 and 37: an advanced signature based on a qualified certificate (often written AdES/QC). The certificate is qualified but the key is not on a certified QSCD, so it is not a QES. It gives strong identity evidence without handwritten equivalence, and public bodies that require an advanced signature must accept it.
Legal effect and burden of proof
The practical difference shows up in a dispute. With a QES, the party disputing the signature faces the same position as someone disputing a handwritten signature: the law already treats the signature as equivalent. With an AdES, the relying party must show that the Article 26 properties were met in this case: how the signer was identified, how sole control of the key was ensured, and that the document is unchanged. Good evidence makes that straightforward, but it is evidence you must keep and present.
| Evidence item | AdES: needed to prove reliability | QES: role |
|---|---|---|
| Identity proofing record | Essential: who checked identity, how, when | Held by the QTSP under its supervised practice |
| Key custody evidence | Essential: device type, authentication, admin access | Covered by QSCD certification and QTSP audit |
| Signed document and signature | Essential | Essential |
| Timestamp and revocation data (B-T, B-LT, B-LTA) | Essential for long-lived records | Essential for long-lived records |
| Validation report | Recommended, against a documented policy | Recommended, showing Art. 32 checks against trusted lists |
National procedural law decides how courts weigh evidence for non-qualified signatures, so the same AdES can be treated differently in different Member States. That uncertainty, not the cryptography, is often the real reason to choose QES.
QSCDs and trust service providers
What makes a device qualified
Annex II requires that signature creation data is reasonably assured to be confidential, practically occurs only once, cannot with reasonable assurance be derived, and can be reliably protected by the legitimate signatory against use by others. The device must not alter the data to be signed or prevent the signatory seeing it before signing. Article 30 requires certification by designated public or private bodies, based on a security evaluation against listed standards or an alternative process of comparable security notified to the Commission. Certification lasts no more than five years, provided vulnerability assessments are carried out every two years, and is cancelled if vulnerabilities are not remedied. Under Article 31, Member States notify certifications and cancellations within one month and the Commission publishes the list of certified devices.
For local devices such as smart cards and tokens, evaluation is against the SSCD Protection Profile (the EN 419 211 series). ENISA published a state-of-the-art document on applying that profile under the EUCC scheme, final version 16 December 2025. Remote signing services use server-side standards for server signing and cryptographic modules (the EN 419 241 and EN 419 221-5 families).
Remote QES
eIDAS 2.0 made remote qualified signing explicit. Article 3(23a) defines a remote QSCD as one managed by a QTSP on the signatory's behalf. Article 29a allows only a QTSP to provide that management service; it may generate or manage signature creation data for the signatory, duplicate it only for backup, keep duplicates at the same security level as originals, limit them to the minimum needed for continuity, and comply with the device's certification report. Article 29(1a) adds that generation, management or duplication on the signatory's behalf happens only at the signatory's request.
- What the signatory controls: authentication to the remote service (typically two factors) that releases each signature; sole control rests on that authentication, not on holding hardware.
- What you must check: that the provider and its remote QSCD management service appear on the relevant national trusted list as qualified, and that the device appears on the Commission's certified list.
- Why it matters: remote QES removes card readers and drivers, which was the main barrier to QES at scale, but makes the provider's authentication flow the critical control.
Trusted lists
Under Article 22, each Member State establishes, maintains and publishes a trusted list of the QTSPs it supervises and their qualified services, signed or sealed and machine-readable; a provider or service is qualified only if it appears there. The Commission publishes the lists centrally with a Trusted Lists browser. Validation software should consume the machine-readable lists, not a static trust store. See the eIDAS Qualified Trust Services Guide for supervision and provider obligations.
Electronic seals for organisations and machines
A signature belongs to a natural person; a seal belongs to a legal person. eIDAS mirrors the signature tiers for seals: Article 3(26) defines an advanced electronic seal as one meeting Article 36, and Article 3(27) a qualified electronic seal as an advanced seal created by a qualified seal creation device and based on a qualified certificate for electronic seals. Article 36 requires the advanced seal to be uniquely linked to and capable of identifying its creator, created using seal creation data the creator can use under its control, and linked to the data so later changes are detectable. Article 35(2) gives a qualified seal a presumption of the integrity of the data and the correctness of its origin.
| Use case | Signature or seal | Suggested level |
|---|---|---|
| Director signs a board resolution | Signature | QES where handwriting or written form is required; otherwise AdES |
| Automated e-invoice issuance | Seal | Advanced or qualified seal, per the recipient's or tax authority's rules |
| Bank statements or certificates issued in bulk | Seal | Qualified seal for presumption of origin and integrity |
| API responses or AI agent outputs needing provenance | Seal | Advanced seal; qualified where third parties must rely on origin |
| Employee approves an internal purchase order | Signature | Simple or AdES with SSO evidence |
Seals are the right instrument for non-human signers. A batch job, integration or AI agent has no intent of its own, so using a person's QES certificate inside an automated pipeline breaks sole control and misattributes intent. Give each sealing system its own seal certificate, keep the key in an HSM or a remote qualified seal creation device (Article 39a applies the remote management rules to seals), and treat access to that key as a privileged machine identity. See the E-Signature Platform Security page and the Digital Signatures Guide.
Cross-border use and public services
The 2024 amendment deleted Article 25(3) and gathered recognition rules into Article 24a. Article 24a(1) recognises a QES or qualified seal based on a qualified certificate from one Member State as qualified in all others; Article 24a(2) recognises certified QSCDs; Article 24a(3) recognises qualified certificates and remote QSCD management services; further paragraphs cover qualified validation and preservation services.
For public services, Article 27 says that where a Member State requires an advanced signature for an online public service, it must recognise AdES, AdES based on a qualified certificate and QES, at least in the formats set by implementing act, and Article 27(3) prevents it requiring a higher security level than QES for cross-border use. Article 37 does the same for seals. Implementing Regulation (EU) 2026/248, adopted 2 February 2026, sets those formats and repeals Implementing Decision (EU) 2015/1506. From 23 February 2027 its Annex I applies:
| Format | Standard in Annex I | Typical content |
|---|---|---|
| XAdES baseline | ETSI EN 319 132-1 V1.3.1 | XML, e-invoicing |
| CAdES baseline | ETSI EN 319 122-1 V1.3.1 | Any binary file (CMS) |
| PAdES baseline | ETSI EN 319 142-1 V1.2.1 | |
| JAdES baseline | ETSI TS 119 182-1 V1.2.1 (clause 5.1.8 adjusted for x5c) | JSON and JWS, APIs |
| ASiC containers | ETSI EN 319 162-1 and 162-2 V1.1.1 | Bundled files and signatures |
Annex II keeps the older ETSI TS 103 171 to 174 profiles recognised for signatures and seals created before 23 February 2028. Producers of signed documents for public bodies should move to the Annex I baselines now; JAdES matters for API and machine-to-machine signing.
eIDAS 2.0 and the wallet
Article 5a(5)(g) requires European Digital Identity Wallets to offer all natural persons the ability to sign with QES by default and free of charge, and lets Member States limit free use to non-professional purposes. Wallets will therefore put QES in the hands of citizens who never held a qualified certificate, while professional and high-volume use stays with commercial QTSPs. The wallet is also one of the Article 24(1a) routes for proving identity when a qualified certificate is issued. Wallet rollout dates and implementing acts are covered in the eIDAS 2.0 and the European Digital Identity Framework Guide; plan for QES becoming cheaper and more common for consumers, which lowers the friction argument against it.
Decision guidance and trade-offs
| Question | If yes |
|---|---|
| Does national or sector law require handwritten signature or written form for this document? | QES (or wet ink where electronic form is excluded) |
| Does a public body or contracting authority specify the level? | Follow it; for cross-border, it cannot ask for more than QES |
| Is the signer an organisation or system? | Seal, not signature |
| Is the counterparty likely to dispute, or is the value high? | QES, or AdES/QC with strong evidence |
| Do you control onboarding of all signers (employees, contractors)? | AdES with your own identity proofing is usually enough |
| Will the record be kept beyond certificate validity? | Either level at B-LT or B-LTA, or a qualified preservation service |
- Small organisations: use a signing platform that offers AdES and on-demand remote QES from a QTSP, and choose QES per document rather than running PKI.
- Large organisations: maintain a signature policy mapping document classes to simple, AdES, AdES/QC or QES and seal levels, integrate one or more QTSPs, and validate inbound signatures against trusted lists.
- Cost versus certainty: QES costs more per signer and adds onboarding time; AdES shifts cost to evidence retention and possible litigation effort.
Worked scenarios
Scenario 1, a cross-border employment contract. A company in one Member State hires staff in three others. Local rules in one country require written form for a clause. HR uses AdES for the standard contract and switches that country's contracts to remote QES through a QTSP, relying on Article 24a(1) for recognition elsewhere.
Scenario 2, e-invoices from an ERP. The finance platform seals outgoing invoices in XAdES with an advanced seal held in an HSM. One customer, a public body, requires a qualified seal, so the team obtains a qualified seal certificate and moves the key to a certified remote qualified seal creation device, keeping access restricted to the invoicing service identity.
Scenario 3, a disputed AdES. A supplier denies signing a variation signed with an AdES from an internal CA. The company produces the identity proofing record, SSO logs showing two-factor authentication at signing, the B-LT signature and a validation report. Because it kept that evidence, it can show the Article 26 properties; without it, the signature would carry little weight.
How to implement
- Classify documents: list document types, governing law, form requirements, counterparties and retention periods.
- Map levels: assign simple, AdES, AdES/QC, QES, advanced seal or qualified seal per class; record the legal basis for each QES requirement.
- Select providers: confirm each QTSP and service on the national trusted list, and each QSCD on the Commission's certified list.
- Set identity proofing: for AdES, define your own proofing standard; for QES, use the QTSP's Article 24(1a) method, wallet based where available.
- Choose formats: produce Annex I baselines (PAdES, XAdES, CAdES, JAdES, ASiC) at B-LT or B-LTA for long-lived records.
- Pilot: run one class end to end, validate outputs with an independent validator against trusted lists, and test acceptance by a real counterparty.
- Roll back: keep an alternative route (another QTSP, or wet ink) for signers who cannot complete QES onboarding, and record exceptions.
Detection and measurement
Log signing events with level, certificate issuer and qualified status, remote QSCD authentication events, seal key use by service identity, and validation results for inbound documents. Re-validate archived samples on a schedule so INDETERMINATE results appear before a dispute.
- Policy coverage: percentage of document classes with an assigned level and recorded legal basis.
- Level accuracy: share of sampled signatures matching the level required for their class.
- Trusted list currency: share of validations performed against current trusted lists rather than static stores.
- Seal key hygiene: number of seal keys outside HSMs or qualified devices (target zero).
- Long-term readiness: share of long-retention records at B-LT or B-LTA.
Common failure patterns
- Calling AdES/QC a QES: a qualified certificate in a software keystore is not a QES; check the QSCD.
- Using a person's QES for automation: breaks sole control and misattributes intent; use a seal.
- Trusting a provider's marketing label: qualified status exists only on the national trusted list.
- Ignoring the new format rules: public bodies will apply Implementing Regulation (EU) 2026/248 formats from 23 February 2027.
- Weak remote signing authentication: the remote QSCD release step is the control that proves sole control; single-factor release undermines it.
- Short-lived evidence: B-B signatures on records kept for a decade become hard to validate.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| eIDAS | Arts. 3, 24, 24a, 25, 26, 27, 29, 29a, 30, 31, 32, 35, 36, 37, 39a; Annex II | Levels, legal effect, devices, recognition, seals |
| NIST SP 800-53 Rev 5 | AU-10 Non-repudiation | Binding signers and systems to signed actions |
| NIST SP 800-53 Rev 5 | SC-17 Public Key Infrastructure Certificates; SC-12 Cryptographic Key Establishment and Management | Certificate issuance and signing key custody |
| NIST SP 800-53 Rev 5 | IA-5(2) Public Key-based Authentication | Certificate validation and key protection |
| NIST CSF 2.0 | GV.OC-03 | Legal and regulatory signature requirements understood and managed |
| ISO/IEC 27001:2022 | Annex A 5.31 Legal, statutory, regulatory and contractual requirements; 8.24 Use of cryptography | Signature policy and key management |
Practitioner checklist
- Record the legal basis for every document class that requires QES.
- Distinguish AdES, AdES/QC and QES in policy and in validation reports.
- Use seals, not personal signatures, for organisations, systems and AI agents.
- Check QTSPs and remote QSCD services on national trusted lists before contracting.
- Require two-factor release for remote QES and remote seals.
- Keep seal keys in HSMs or qualified seal creation devices tied to one service identity.
- Produce Implementing Regulation (EU) 2026/248 Annex I formats for public bodies.
- Store long-lived records at B-LT or B-LTA and re-validate samples yearly.
- Keep identity proofing and key custody evidence for every AdES.
Standards and references
- EUR-Lex: Regulation (EU) No 910/2014 (eIDAS), consolidated text
- EUR-Lex: Commission Implementing Regulation (EU) 2026/248 on advanced signature and seal formats
- European Commission: EU Trusted Lists
- ENISA: Security Evaluation and Certification of Qualified Electronic Signature/Seal Creation Devices
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Digital Signature vs Electronic Signature · eIDAS Qualified Trust Services Guide · eIDAS 2.0 and the European Digital Identity Framework Guide · E-Signature Platform Security. This guide summarises the EU eIDAS Regulation and its implementing acts and is not legal advice.