Qualified Electronic Signatures Under eIDAS for EU Contracts

A typed name at the bottom of an email and a cryptographically sealed signature issued through a regulated trust provider both count as "electronic signatures" under EU law, and that single fact is the source of most compliance confusion in contract operations today. Organizations often ask one question: does a signature from a standard e-signature platform qualify as a Qualified Electronic Signature (QES)? It almost certainly does not, and the distinction matters because QES carries a legal status the other two tiers cannot claim: an automatic presumption, in every EU member state, that the signature is equivalent to one made by hand.

The European Commission's eIDAS framework sets out three levels, each building on the one before it. A Simple Electronic Signature (SES) is any data in electronic form attached to or logically associated with other data and used by the signatory to sign. A typed name under an email satisfies this definition. An Advanced Electronic Signature (AES) goes further: it must be uniquely linked to the signatory and capable of identifying that person, created using signature creation data that the signatory can, with a high level of confidence, use under their sole control, and linked to the signed document so that any later change is detectable. AES is most commonly built on public-key infrastructure, where certificates and cryptographic keys do the work. A Qualified Electronic Signature is an AES with two additional requirements layered on top: it must be created using a Qualified Signature Creation Device (QSCD), and it must rest on a qualified certificate issued by a Qualified Trust Service Provider (QTSP). Both elements are required at once. Neither substitutes for the other.

Part of the confusion organizations run into stems from conflating two terms that sound interchangeable but are not. The European Commission's eSignature FAQ treats "electronic signature" as a legal concept, defined under Article 3.10 of eIDAS, and "digital signature" as a mathematical and cryptographic concept describing how a signature is technically constructed. A platform can produce a digital signature in the cryptographic sense, but that signature might not meet any of the three legal tiers eIDAS defines. Treating the two as synonyms is how legal teams end up believing a signing tool has delivered more legal protection than it has.

The same three-tier structure applies to electronic seals, but these serve legal persons, businesses and organizations, not natural persons. A qualified electronic seal issued to a company and a QES issued to that company's authorized representative are equally acceptable under EU law wherever a qualified seal is required, so you can use this to decide whether a document needs a human signatory or a corporate seal.

What makes QES legally distinct comes down to Article 25 of eIDAS. A QES has legal effect equivalent to a handwritten signature, and if it is based on a qualified certificate issued in one member state, every other member state must recognize it as such. That recognition is paired with a reversal of the burden of proof: if a QES is challenged in court, the party contesting it has to prove it is invalid. With an AES or an SES, the burden runs the other way. The party relying on the signature has to prove it is authentic if the signature is disputed. AES carries a presumption of reliability, but it is a rebuttable one. SES carries the weakest evidentiary standing of the three, and public administrations generally refuse to accept it.

That three-way structure, and the specific combination of QSCD and QTSP that defines QES, is the vocabulary the rest of this discussion depends on.

QES legal requirements and the risk of mandating it everywhere

QES is a legal requirement only in the specific cases where EU or national law demands a handwritten signature or its direct equivalent. For most commercial contracts, an Advanced Electronic Signature satisfies the law entirely, so insisting on QES where it is not required just adds cost and friction without adding legal protection.

The categories where QES is genuinely mandatory are narrow and identifiable. They include certain employment termination agreements in specific EU countries, notarial acts and land registry filings, consumer credit agreements in jurisdictions that regulate them specifically, and government or public-sector submissions that carry statutory formality requirements. Public procurement offers a useful illustration of how this plays out in practice: France's PLACE platform requires an advanced electronic signature based on a qualified certificate, or a qualified signature outright, to sign public procurement documents when the contracting authority specifically mandates it. Electronic submission of bids through PLACE became mandatory in October 2018, but the signature requirement stayed optional unless the contracting authority imposed it, and that distinction is easy to blur, so you need to get it right.

National law adds further texture on top of the EU baseline. In that jurisdiction, many commercial contracts default instead to a lighter text-based form, where an AES is enough. Getting that distinction wrong in either direction has consequences: treat a contract under the lighter form as though it needs QES, and the organization pays for identity verification and credential issuance it did not need to pay for; treat an agreement under the stricter form as though AES will do, and the agreement may not hold up as a matter of form.

Article 25 of eIDAS reinforces this from the other direction. Electronic signatures cannot be denied legal effect solely because they are electronic, so AES and SES stay fully valid if the underlying evidence of signer intent, identity, and document integrity is enough to satisfy a court. Article 27 then sets a ceiling as much as a floor: public authorities cannot demand a signature level higher than QES. So if the transaction involves an EU public body, QES satisfies the requirement, and there is nothing further to prove.

The practical cost of QES sits in the identity verification onboarding it requires, friction that a streamlined SES or AES signing flow simply avoids. The right operational response is not to default to the highest tier out of caution, but to build a documented, contract-type-level decision matrix: which categories of document require QES, which can run on AES, and the specific legal basis for each determination. That matrix is what makes the choice defensible in an audit or in court, rather than a decision made ad hoc by whoever happened to be running the signing workflow that week.

Beyond France's procurement platform, a handful of other sectors carry their own named, concrete QES obligations. Notaries have used electronic authentic acts since 2005, and since 2020 they can also use a remote-appearance variant. Financial services face a double layer of obligation: cross-border banking rules under PSD2 today, and starting July 10, 2027, the Anti-Money Laundering Regulation will introduce a verification hierarchy from the new Anti-Money Laundering Authority that favors eIDAS-compliant methods, effectively making QES the preferred mechanism for executing legally binding contracts in banking.

None of this answers the harder operational question underneath the legal one: if an organization picks the wrong tier, or if a qualified signature is later challenged, someone has to absorb the cost of being wrong.

How QTSP liability shifts risk structurally

Choosing QES over AES is a decision about where legal liability sits if the signature is ever challenged, not solely a matter of satisfying a formality. Under Article 13 of eIDAS, a QTSP is directly liable for damages caused to any natural or legal person as a result of its failure to meet regulatory obligations. Article 24(2)(c) requires every QTSP to maintain sufficient financial resources, or obtain appropriate liability insurance, or both, so that exposure is covered. With an AES or SES arrangement, no equivalent backstop exists. Liability for a failure in identity assurance or document integrity falls on the organization that deployed the signing tool, not on the platform vendor.

That structural difference is one of the most underappreciated arguments for using QES in high-value or high-dispute-risk transactions. A QTSP's regulated status, and the mandatory insurance attached to it, creates a liability backstop that no AES deployment can replicate on its own. The cost asymmetry is visible at the point of comparison: the per-document cost difference between running a transaction through an AES platform versus issuing a QES credential is minimal at the time of signing. The cost of remediation, if that signature is later challenged and found wanting, runs to a multiple of that original difference.

The operational lesson that follows is not purely legal. Organizations need to confirm, at the point of procurement, that a signing platform either is, or routes through, a genuine QTSP listed on the EU Trusted List, rather than simply accepting a vendor's claim of "eIDAS compliance" at face value. The EU Trusted List is the authoritative verification mechanism here: QTSPs are listed by supervisory bodies in each member state, and a qualified certificate is only valid if the entity that issued it appears on that list. A platform can describe itself as eIDAS-compliant in marketing language while delivering signatures that never touch a genuine QTSP. That distinction only becomes visible when a signature is challenged and the liability has to be answered for real.

eIDAS 2.0 tightens this enforcement mechanism further. It introduces financial penalties, calculated as a percentage of global turnover, for national authorities that wrongly refuse to recognize a qualified signature issued in another member state. That provision reinforces something the original regulation already stated but did not always enforce with teeth: cross-border recognition of a qualified signature is a legal obligation on the receiving authority, not a courtesy it can extend or withhold at discretion.

None of that liability architecture functions, though, unless a signer can actually obtain a qualified certificate and produce a qualified signature in the first place, which is where the operational mechanics come in.

QES identity verification and certificate issuance in practice

The legal force behind a QES comes from three technical requirements operating together: identity proofing, qualified certificate issuance, and a device that meets the standard for qualified signature creation. Until recently, these three requirements also made QES considerably harder to use than either AES or SES, which is the central reason adoption lagged behind the legal advantages QES offers.

Identity proofing requires the QTSP to formally verify the signer's identity before issuing a qualified certificate, historically through in-person verification, video identification, or biometric verification. The qualified certificate itself is issued by a QTSP on the EU Trusted List and cryptographically binds the signer's verified identity to their public key. The Qualified Signature Creation Device, the QSCD, ensures that the signing key is generated and stored securely, cannot be derived or forged, and that signed data cannot be altered after the fact. Historically, a QSCD meant a physical object: a smart card, a USB token, a hardware security module the signer had to hold or insert. The European Commission's own FAQ confirms both requirements apply simultaneously: a QES is an advanced electronic signature additionally created by a QSCD and additionally based on a qualified certificate.

Remote QES has already turned that physical-device requirement into established practice, not just a future promise. Instead of requiring the signer to hold a physical token, platforms route the signing operation through a hardware security module held by the QTSP itself, with the signer authenticating through a separate channel, a PIN, a one-time password, or a biometric check.

Several platforms operating in 2026 illustrate the range of verification approaches and jurisdictional coverage now available. Skribble issues QES under both eIDAS and the Swiss ZertES framework from a single account, with jurisdiction selectable per document; its certificates are issued through Swisscom, a QTSP recognized under both frameworks, and its data is hosted in Switzerland across ISO 27001-certified, FINMA-compliant Tier IV data centers. Identity verification on Skribble is a one-time cost per signer that remains valid for two to five years depending on the identification method used, up to a maximum of five years. Pricing runs at €/CHF 23 per user per month for the Team tier and €/CHF 36 for Pro, alongside a pay-per-use Starter tier billed per signature. inSign, built by a vendor based in Bavaria, offers German data residency and issues QES through partner trust services including D-Trust, Swisscom, Evrotrust, and A-Trust, supporting both eIDAS and Swiss ZertES, and is positioned for organizations that need German hosting alongside confidentiality obligations set out in national criminal law, relevant to doctors, lawyers, and insurers. Docusign occupies a distinct position in this landscape as well: Docusign France SAS is itself a registered EU Qualified Trust Service Provider, and the company also integrates with additional EU QTSPs to deliver eIDAS-compliant QES within its Intelligent Agreement Management platform, letting organizations manage drafting, negotiation, QES signing, and post-execution contract management inside one environment, with API access for embedding QES into custom workflows.

What these platforms share is a response to the same underlying friction: identity proofing has been the main barrier standing between QES and wider adoption, because verifying a human being's identity to the standard a QTSP requires has historically taken more time, more steps, and more hardware than most signing workflows could tolerate. The next phase of the regulation is built to dismantle that friction.

eIDAS 2.0 (Regulation EU 2024/1183) changes to QES in 2025 and 2026

eIDAS 2.0 does not alter the legal effect of QES, and it does not touch the three-tier signature hierarchy described above. What it changes is infrastructural: it makes smartphone-based remote QES the default mechanism rather than an alternative path, and it obligates the broader digital identity ecosystem to support that shift at scale.

That distinction matters because the core limitation on QES adoption was never legal uncertainty about what a qualified signature meant in court. The limitation was practical: identity proofing and QSCD access required friction that organizations and individual signers were reluctant to repeat for every new relationship or every new platform. eIDAS 2.0 addresses that friction directly by mandating the infrastructure, principally a digital identity wallet, that lets a person prove their identity once and reuse that proof across qualified trust services without repeating full in-person or video verification each time.

The regulation also strengthens the enforcement side of the cross-border recognition promise that Article 25 of the original regulation already made. The financial penalties, tied to a percentage of global turnover and levied against national authorities that wrongly refuse to recognize a qualified signature issued elsewhere in the EU, make that cross-border guarantee operationally real, not just theoretical. An organization operating across several member states no longer has to treat cross-border recognition as a risk to be managed; it is a right backed by a financial penalty if a national authority violates it.

For organizations signing contracts across the EU, the real issue is no longer whether QES is available, but whether a given signing platform and its underlying QTSP relationships can take advantage of the infrastructure eIDAS 2.0 is building out through 2025 and 2026. The legal hierarchy, SES, AES, and QES, remains exactly as it was. What changes is how much friction stands between an organization and the qualified tier, and that friction is the entire story of eIDAS 2.0's rollout.