What a Qualified Electronic Signature Proves

Content authorToomas PihlPublished onReading time13 min read
Title:
What a Qualified Electronic Signature Proves

Meta description:
Learn how eIDAS and Trust Services let you verify QES status and document integrity before you rely on a signature.

Article:
# W

A qualified electronic signature (QES) proves three things when it validates: the signer's verified identity, that the document hasn't changed since signing, and that the signature meets eIDAS requirements for qualified status.

What makes a signature qualified?

A QES is an advanced electronic signature created with a qualified signature-creation device and based on a qualified certificate issued by a qualified trust service provider. All three conditions must hold at once. Miss one and you have an advanced signature.

The reason this matters legally is spelled out in the eIDAS Regulation. A qualified electronic signature has the equivalent legal effect of a handwritten signature across all EU Member States, according to the European Commission's eSignature FAQ. That equivalence is granted explicitly, which is what separates QES from every other signature level.

Here's where procurement decisions go wrong. A QES requirement is triggered by the applicable law or a formality written into a statute. A €10 million supply agreement between two commercial parties under English law needs no QES at all.

QES requirements form one verification chain

QES status depends on four linked conditions, and each one has a different party responsible for it and a different piece of evidence you can check. Treat them as a chain rather than a checklist, because a break anywhere downgrades the whole signature.

RequirementWho is responsibleEvidence to verify
Meets Article 26 AdES criteriaSigning serviceValidation report showing signer linkage and integrity
Qualified certificate under Annex IQualified trust service providerCertificate QcStatements
Signature creation on a QSCDQTSP or device certifierQSCD indication in the validation output
Qualified status at issuanceNational supervisory bodyEntry on the EU Trusted List

These rules come from Regulation (EU) No 910/2014 as consolidated, with technical determination handled by ETSI TS 119 615, the standard the Commission's own Digital Signature Service uses to decide whether a certificate is qualified. The rules themselves are verified. What isn't verified, and what you have to reason about yourself, is whether your counterparty will actually run a validation before relying on the document.

The signature must satisfy AdES rules

Before anything qualifies, it has to be an advanced electronic signature. Article 26 of eIDAS requires that the signature is uniquely linked to the signatory and capable of identifying them. It must be created with signature-creation data the signatory can use under his sole control with a high level of confidence, and linked to the signed data so any later change is detectable.

ENISA's 2019 standards overview notes that eIDAS didn't introduce new format requirements for AdES compared with the old 1999 Directive, which is why pre-eIDAS technical specifications stayed usable. That continuity has a practical consequence worth naming: a vendor telling you their signature is "eIDAS compliant" is describing Article 26 conformance only. Compliance with Article 26 is the floor, which leaves the certificate and the device sitting behind it unaddressed.

A qualified certificate identifies the signer

The qualified certificate is what binds a verified human identity to the signature-validation data. It has to satisfy Annex I of eIDAS, which requires the signatory's name and the issuing provider's own advanced signature or seal. The annex also requires the location of the service where you can check the certificate's validity status.

Identity verification happens before issuance. Article 24(1) requires the provider to confirm identity by physical presence or by an electronic identification means for which physical presence was confirmed at some stage. According to ENISA's guidance for qualified providers, another nationally recognised method giving equivalent assurance to physical presence is also accepted.

So the identity assurance you're buying was established weeks or months before your document existed. That's the strength and the limitation. The certificate tells you who was enrolled without identifying who was sitting at the keyboard on signing day, which is why authentication at the moment of signing deserves separate scrutiny.

Cut contract signing time by 60%

See how Agrello can automate your contract workflows from creation to e-signature in one free consultation.

A QSCD protects signature creation

A qualified signature-creation device is hardware or a certified server environment that protects the private key used to sign. Annex II requires the device to keep the signature-creation data confidential and ensure it occurs practically only once. The device must also prevent the data from being derived and protect it against use by others.

Remote signing is fully permitted here. The European Commission confirms that a QSCD can be remotely managed by a QTSP, and these remote QSCDs keep the same legal certainty while removing the smartcard and reader from the signer's desk. CEN EN 419 241 covers the server-signing side.

Which means the old assumption that QES requires physical tokens is out of date, and a provider who still requires physical tokens is describing their own product limits. Ask instead which certification the remote QSCD holds and who audited it.

A QTSP anchors qualified status

The final link is the provider's own status. Under Article 22, national trusted lists have what the European Commission calls a constitutive effect, so a trust service provider and its services are qualified only if they appear on a list. There's no informal route to qualified status.

Timing is the part that gets missed. The service must have held qualified status at the moment the certificate was issued, not merely when you check later. A provider can gain or lose listing, and the Trusted List Browser shows current entries alongside historical service status changes.

Anyone signing agreements meant to survive a decade of disputes should capture the validation evidence now, while the listing is live and current. Reconstructing the qualified status of a service five years after a provider exits the market is possible but slow, and slow evidence is expensive evidence in litigation.

What does QES prove?

Successful validation of a QES proves signer identity as recorded in the certificate and integrity of the signed document. It also confirms the qualified status of the signature itself. That's the full extent of it.

Article 32 sets what validation confirms: that the certificate was qualified and complying with Annex I at the time of signing, and that it was issued by a qualified provider and valid then. Validation also confirms that the integrity of the signed data hasn't been compromised and that Article 26 requirements were met at signing.

Notice what's absent from that list. Validation says nothing about whether the person who signed was authorised to bind their company. It says nothing about whether they read the document or understood it. It doesn't establish that the contract is enforceable or that a notarial formality required under Italian or Spanish law was satisfied.

That gap is where disputes actually live. Corporate authority comes from board resolutions and commercial registers. So a QES workflow that skips authority checks has produced perfect cryptographic evidence for a signature that fails to bind anyone.

How does QES differ from AdES?

Monochrome split-layout office scene featuring legal document icons, judges, and checklists, set against a softly blurred workplace background.

AdES meets Article 26 and nothing more. QES adds a qualified certificate and a QSCD to Article 26, and only QES receives the explicit handwritten-signature equivalence written into Article 25(2).

The differences show up in practice across several dimensions:

  • Identity assurance: AdES identity checks are set by the provider's own policy. QES identity is verified under Article 24 by an audited qualified provider.

  • Creation control: AdES requires sole control with high confidence. QES requires that control to happen inside a certified device.

  • Verification: QES status is machine-determinable against national Trusted Lists. AdES has no equivalent public register.

  • Cost and friction: QES adds enrolment steps and per-signature or per-certificate charges, with a dependency on the signer completing identity proofing.

AdES is still real evidence. The European Commission is clear that an electronic signature keeps its legal effect and admissibility when challenged solely on the grounds that it's electronic or that it falls short of QES requirements. A judge weighs it like any other evidence.

The distinction that matters for procurement is between automatic equivalence and evidential weight. QES gives you the first. AdES gives you the second, and for most commercial contracts the second is what you actually needed.

Cut contract signing time by 60%

See how Agrello can automate your contract workflows from creation to e-signature in one free consultation.

When is QES the best fit?

QES fits where a statute demands written form or where a public authority mandates it.

German law is the clearest example in the EU. Under Section 126a of the Bürgerliches Gesetzbuch, electronic form replaces statutory written form only when the document carries a qualified electronic signature, and German courts treat this as constitutive rather than evidential. Section 623 BGB goes further and excludes electronic form entirely for employment terminations, as the Mecklenburg-Vorpommern Regional Labour Court confirmed in its 9 May 2023 ruling.

Member States also set their own rules for public services. The Commission confirms they remain free to require QES for a given online public service, such as filing a request that initiates court proceedings.

Which leads somewhere procurement teams rarely go early enough. Before choosing a signature level, check the governing law clause and ask the receiving registry or authority what they accept. Their answer is more specific than any general guidance, and it binds you in a way that a vendor's compliance page doesn't.

When is QES not ideal?

QES is the wrong choice when no law and no counterparty requires it, and the agreement carries low dispute risk. Non-disclosure agreements and routine purchase orders rarely justify it.

The costs are real and mostly land on the signer. Every signer needs identity proofing before they can sign at all, and enrolment methods that meet Article 24(1) still vary by country. ENISA's remote identity proofing research found that Article 24(1)(a)'s "physical presence" requirement is read differently across Member States, with some treating remote identity proofing as legitimate physical presence and others not.

That fragmentation has a direct commercial consequence. A QES requirement imposed uniformly across a supplier base spanning several countries will produce uneven completion rates, and the suppliers who stall are the ones whose national enrolment route is slower.

When AdES already gives you a signer-linked, tamper-evident record with a full event history, adding QES buys legal equivalence you weren't going to invoke.

Is QES recognized across borders?

Yes, within the EU. Article 25(3) requires that a qualified electronic signature based on a qualified certificate issued in one Member State be recognised as a qualified electronic signature in all other Member States, and the same recognition extends to EEA states through Trusted List participation.

Separate the signature from everything around it. Cross-border recognition means another Member State can't refuse your signature on the grounds that the certificate came from elsewhere. It doesn't harmonise contract formalities, and it doesn't touch national rules on notarisation or land registration. Sector regulation in financial services and healthcare adds its own layer.

Under the amended framework, Article 25(3) has been moved into a new Article 24a on recognition of qualified trust services, which also covers recognition of certified QSCDs and remote signature management services across Member States.

The reading that follows is straightforward. Your signature travels. Your compliance with a Portuguese or Polish formality doesn't. For any specific cross-border transaction, put the formality question to local counsel or the competent authority rather than inferring it from recognition rules.

How should a QES be verified?

Run the document through a standards-based validator and read the report. What you're checking is certificate status at signing time and the QSCD indication. Document integrity and the signing time itself also matter, as does the provider's Trusted List entry.

The Commission's Digital Signature Service implements a published QES validation algorithm that resolves whether the certificate is qualified and what type of certificate it is. It also resolves whether the private key is protected by a QSCD. Reports follow ETSI TS 119 102-2, which produces a standardised output that contains the validation input data and the policy applied.

One trap deserves naming. PAdES is a signature format, as are XAdES and CAdES. A file being a valid PAdES document tells you the container is well-formed. Qualification is determined from the certificate's QcStatements checked against the Trusted List entry.

So archive the validation report alongside the document. The report is what you'll produce in a dispute, and regenerating it years later depends on revocation data that won't always still be available.

What should buyers ask providers?

Ask questions that force the provider to name the entity and the listing. Vague answers here predict vague evidence later.

The list worth working through in a procurement call:

  1. Who is the QTSP behind the signature, and under which Member State's Trusted List is the specific service listed?

  2. Is the signing key protected by a QSCD, and is it a local device or a certified remote QSCD?

  3. How is the signer identified before certificate issuance, and does that method vary by country?

  4. Which countries can your signers actually complete QES enrolment in today?

  5. Does the platform produce a standards-based validation report, and can it be exported?

  6. What long-term evidence is applied, such as timestamps and revocation data for archival formats?

  7. Which signature formats are supported, and is QES available on every pricing plan or only some?

  8. What are the integration options, and which signing methods does each depend on?

Every provider claiming QES must ultimately point at a Trusted List entry, since the Commission states that users benefit from the legal effect of a qualified trust service only if it is listed as qualified. A provider who can't name that entry in one sentence has answered your question.

Could Agrello support the chosen workflow?

Agrello is a document management and e-signing platform for preparing and sending signed documents, with secure shared spaces where counterparties review and sign. Documents are collected and stored digitally with the associated signing record.

On signing methods, Agrello's published description covers signing with a national e-ID or with Agrello's own international advanced electronic signature, as listed on the e-Estonia DigiExpo profile. Those are two different evidence levels, and they are not interchangeable for a document with a statutory written-form requirement.

That distinction is the thing to settle before you buy. National e-ID signing in some Member States produces QES, while an international AdES does not, and which one your workflow ends up using depends on the signer's country and the method they choose.

Before selecting a plan, confirm with Agrello in writing the exact signing method each signer will use and the plan that includes it. Also confirm the jurisdictions where it's available and whether the resulting signature carries qualified status. Then validate one signed test document and keep the report.

Cut contract signing time by 60%

See how Agrello can automate your contract workflows from creation to e-signature in one free consultation.

Expiry after a valid signing event doesn't invalidate the QES by itself. Validation must show that the certificate was valid when the signature was created. Keep the original document, validation report, and reliable signing-time evidence, because later checks need proof of the certificate's status at that time.

Don't rely on the document as a qualified signature until the failure is resolved. Save the original file and the validation report, then determine whether the file changed or the certificate and service failed qualified-status checks at signing time. Ask the signer or provider to correct the issue before using the document.

A qualified electronic seal identifies a legal person, such as a company or public body, and protects a document's integrity. It doesn't replace a person's QES where a law requires an individual's signature or expression of intent. Use a seal for documents that an organisation issues in its own name.

You can sign offline only with a local qualified signature-creation device, such as a smart card, whose software supports offline signing. A remote QES service needs an internet connection for signer authentication and access to the provider's server. Signature validation needs trust-list and certificate-status data for the signing time.

Don't assume a signing link produces QES because it mentions eIDAS or displays an e-ID option. Ask for the QTSP's name and confirmation that the method uses a qualified certificate and QSCD. The completed document's validation report must then confirm its qualified status.

Schedule a Meeting

Book a time that works best for you and let's discuss your project needs.

You Might Also Like

Discover more insights and articles

Title:
How to Choose Contract Repository Software

Meta description:
Learn how to select a contract repository that fits your operational needs and avoids costly software traps.

Article:
# How to Cho

How to Choose Contract Repository Software

Choose contract repository software by testing findability and export against your own signed agreements. Storage capacity is the least useful comparison point. Run a pilot with real contracts from your shared drive and confirm you can leave with your data intact.

Title:
Contract Repository Software: What to Evaluate Before You Buy

Meta description:
Learn how to score contract repository software options so you pick the right tool for your signed agreements.

Contract Repository Software: What to Evaluate Before You Buy

This article is a buyer's guide for teams that want their signed agreements out of shared drives and into one searchable digital contract repository. It covers what to test during demos and how to score shortlisted products against your current setup.

Title:
Document Automation Software for Growing Workflow Teams

Meta description:
Learn how document automation software simplifies your workflow and cuts turnaround time from template to signed file.

Document Automation Software for Growing Workflow Teams

This article explains how document workflow automation software works end to end, from an approved template to storage. It walks through the capabilities worth checking before you buy and a template-to-sign workflow you can copy.

Title:
How Signing Order Works in an Electronic-Signature Workflow

Meta description:
Learn how to structure signing workflows to reduce contract delays and prevent costly routing errors in your busin

How Signing Order Works in an Electronic-Signature Workflow

Signing order is the rule that decides when each recipient gets invited to sign. Use sequential routing when one signature depends on another and parallel routing when signatures are independent. A delay pauses only dependent steps. A decline triggers whatever exception path you configured before sending.