SES, AES and QES at a glance: three levels, three evidence logics
The eIDAS Regulation knows three levels of electronic signatures, and each fulfils a different job. A product manager or architect building signing into a SaaS product need not recite these levels but should understand their evidence logic. The level determines identification effort, user experience, cost and liability. In this guide we stay with the terms SES (simple signature), AES (advanced signature) and QES (qualified signature).
The simple signature (SES) is the lowest level. It covers practically any electronic consent assigned to a document, such as tapping a drawn mark or ticking a box with logging. Legally it is not denied effect, but its evidentiary weight depends strongly on circumstances: who consented when, and how do you prove it? SES suits transactions where the law requires no particular form and dispute risk is low.
The advanced signature (AES) sets higher requirements. It must be uniquely linked to the signer, capable of identifying them, created using means the signer can keep under their sole control with a high level of confidence, and linked to the data so that later changes are detectable. That is more than a tick box: it needs a technical procedure securing identity and integrity, and logs that prove it.
The qualified signature (QES) is the highest level. It rests on a qualified certificate and a qualified signature creation device and is provided by a qualified trust service provider. Its legal peculiarity: it equals a handwritten signature. Where the law requires written form and permits electronic form, QES is the way. Its evidence logic is strongest because a presumption of authenticity applies and the provider is audited by supervision.
The one hard distinction of this guide: AES and QES differ not in the technique of clicking but in the chain of responsibility. With AES, you as product provider together with your signing service answer for assignment and integrity. With QES, a qualified trust service provider answers for identification, certificate and signature creation under supervision. That shift of responsibility explains why QES means more effort and why it should be used only where needed.
One misunderstanding persists: that a higher level is always the better choice. It is not. QES raises hurdles for users, causes cost per transaction and lengthens processes. Forcing it on every transaction loses completions without gaining legal certainty the law does not require. Conversely AES is simply insufficient where form rules demand QES. The craft lies in assignment: the right level for the right transaction. A general overview is in SES, AES and QES in SaaS.
When AES suffices: the pragmatic normal case
In practice AES is the right level for the large majority of business transactions in SaaS products. These include framework agreements between companies, order confirmations, data protection agreements, data processing contracts, internal policies with acknowledgement, consent declarations and many contracts for which neither law nor agreement prescribes written form. What counts is that in a dispute you can prove who agreed and that the document was not altered. AES is built for exactly that.
The gain is in user experience. An AES flow gets by with lean identification, such as confirmation through a verified access, one-time authentication or an extra check fitting the risk. That reduces effort and drop-offs, and it can be embedded fully in your interface. How that works without a media break is described in white-label signature API without context switching.
When choosing AES a sober risk assessment pays off. How high is the amount in dispute? How likely is a challenge to the signature? Who are the parties and how well do they know each other? What evidence do you have anyway, such as contract relationship, email traffic or customer account? In contracts between business partners with an ongoing relationship dispute risk is usually low, higher in first contacts with high value. Document this weighing, because it later serves as justification for the level you chose.
Logging is especially important. AES lives on your ability to prove what happened: who was invited, when was the document opened, which identification took place, when was it signed, and has the document been unchanged since? This information comes as events from the signing flow and belongs in your own data store. How to process it cleanly is shown in webhook state management for e-signature events.
Know one limit: AES does not replace a legally prescribed written form. If a transaction requires written form by law or agreement and permits electronic form, AES is not enough, then QES is needed. For transactions where the law even excludes electronic form, QES does not help either. Check these questions with your legal counsel instead of guessing in the product team.
A pragmatic tip for product teams: build the level as configuration per template or transaction type, not as a global setting. That way you can run contracts with AES and employment documents with QES in one tenant without maintaining two products. The level is then a property of the document type set by your legal department, not a technical decision of the development team.
When QES becomes mandatory: form, risk and market requirement
QES becomes relevant in three constellations. The first is statutory form: where the law requires written form and allows electronic form, QES replaces the handwritten signature. Examples exist in civil law at several points, and there are areas where electronic form is excluded, such as certain employment declarations. Details depend on the case and current law. Check each document type legally before digitising it.
The second constellation is contractual or regulatory requirement. Some industries, authorities or large customers demand QES even where the law does not strictly require it, for reasons of evidentiary certainty or internal policy. In finance and real estate you meet this often. QES is then a market requirement you must map in your product if you want to sell there. For AML-flavoured scenarios see AML, identification and QTSP for e-signature.
The third is the risk decision: the transaction is valuable or dispute-prone enough that you want maximum evidentiary weight even without compulsion. That is legitimate, but should be a conscious decision pricing in cost and friction. A proven practice is the staged flow: AES as default and QES as an option for transactions above a certain value or for certain counterparties. That allows spending friction where it pays.
For architecture this means: plan for several levels from the start, even if you initially need only AES. The level belongs in your data model, in transaction creation and in your events. Your interface should have room for extra steps, such as identification with QES. And your texts should explain at the right place what the user is doing. Retrofitting means reworking data model and interface, which is much more expensive.
The time aspect counts too. QES transactions take longer because identification and certificate creation are added. Your processes should tolerate waiting states, through reminders, deadlines and clean status displays. A contract waiting two days for a signer's identification must not hang in a state your system does not understand. The state model from webhook state management helps.
Payload and identification: what your API request defines
In integration the level is reflected in the request with which you create a signing transaction. Conceptually you specify: which document is to be signed? Who are the signers, in which role and order? Which signature level applies? Which identification procedure is required? Which references from your system should travel along? Where should events go? Take exact field names and values from the documentation in the developer hub; here we describe the logic.
The document side is usually uncritical: you hand over a document, often a PDF, and where relevant positions for signature fields. Finalise the document before handover. Changes after a signing flow has started are a frequent error because they cause version conflicts. Compute a checksum before starting and keep it in your data store. That lets you later prove that the signed document matches the one handed over.
The signer side holds name, contact route and role. With AES and QES, data needed for identification is added. A principle of data economy: hand over only what the chosen level needs. The more you transmit up front, the more you must justify, protect and delete later. The GDPR demands purpose limitation and minimisation, and that applies to signature data too.
Identification is the area with the most decisions for AES and QES. Depending on the procedure it can run through existing authentication, identity documents, eID or bank-based methods. Which procedures are available in which level depends on vendors and partners. For your product three properties count: what is the drop-off rate, how long does it take, and which evidence remains? Orient on your users, not on technology. A procedure your target group dislikes is not a good procedure.
With events you define which state changes should reach your system. For AES and QES identification events are particularly important because they prove the check took place and with which result. Store these events unchanged in your history. In audits, such as in the context of DORA or NIS-2, exactly this data is the material to evidence processes. More in DORA Article 30 and the signature audit trail.
A last architecture hint: encapsulate level logic in one component. Instead of checking at ten places whether QES applies, your modules ask a central point what requirements a document type has. That point knows level, identification procedure, texts and follow-ups. When law or a customer changes something, you change it in one place. It sounds obvious and is still rarely implemented in grown systems.
Partner QTSP for QES: who carries what
Sign2x is not a qualified trust service provider. We are the API layer bringing SES, AES and QES into your product. For QES we work with partner QTSPs such as Sign8. The partner takes on the parts the legislator reserves for qualified providers: identification under applicable requirements, issuing the qualified certificate and creating the qualified signature. We orchestrate the flow, deliver you the events and take care of operations and integration.
This split has practical consequences. First: with QES several parties are involved, and your contracts should clarify who is responsible for what. Second: availability and quality of the QES path also depend on the partner, and you should reflect that in communication with customers. Third: data flows to the partner, and your data processing and supply chain documentation must map that. QTSP partners for ISVs deepens this.
On sovereignty: Sign2x runs on the Open Sovereign Cloud (OSC) from T-Systems, a European operation under European law. That refers to our platform. With QES the partner QTSP is added, whose location and legal framework you should check as well. Ask about processing location, ownership and subcontractors, as with any provider in your chain. A general classification is in Cloud Act vs data sovereignty.
Whether a QTSP currently counts as qualified can be checked publicly: Member States keep trusted lists, and in Germany the Federal Network Agency is responsible as supervisory body for trust services. For your diligence documentation it pays to record your partner's status and check it regularly. In doubt that is evidence you proceeded carefully in selection.
In practice we recommend a simple decision matrix per document type: does statutory form apply? Does the customer demand QES? How high is the amount in dispute? How many transactions do we expect? How much friction do users accept? The answers give the level, and the matrix serves as documentation. If you are unsure anyway, start with the Sign2x quiz and clarify open questions in the help centre. Use cases are on the use cases page, more articles in the Sign2x blog.
Finally: when extending a flow from AES to QES, plan a test with real users. QES flows contain steps users do not know, and small ambiguities in texts cause drop-offs. A short test with ten people from your target group reveals the biggest problems. In from sandbox to your first QES path we describe the technical way to the first working transaction.
Try AES and QES in the sandbox
Further reading: AML-ready signature API for ISVs and eIDAS 2.0 and the EUDI wallet for SaaS relying parties. Guidance on information security at the BSI.
Frequently asked questions
What is the difference between AES and QES?
AES links the signature uniquely to the signer and makes changes detectable. QES additionally rests on a qualified certificate from a qualified trust service provider and equals a handwritten signature.
When is AES enough?
For most business transactions without statutory written form, such as framework agreements, order confirmations or consent declarations. Check form rules legally each time.
When do I need QES?
When the law requires written form and permits electronic form, when customers or regulation demand QES, or when you deliberately choose maximum evidentiary weight.
Is Sign2x a qualified trust service provider?
No. Sign2x is the API layer for SES, AES and QES. For QES the qualification runs through a partner QTSP such as Sign8.
Can I use several levels in the same product?
Yes. Set the level per document type or template and encapsulate the logic in one component so AES and QES run side by side.
