Electronic seal (eSeal): what it proves, the three levels and how to verify one

An electronic seal is a company's cryptographic mark on a file. It shows which organization issued the document and that nobody has changed it since. Regulation (EU) No 910/2014, known as eIDAS, defines it as "data in electronic form, which is attached to or logically associated with other data in electronic form to ensure the latter's origin and integrity" (Article 3(25)). One point earlier, Article 3(24) settles who makes it: the creator of a seal is "a legal person". A company, an association, a ministry. Never a human being.

That one word drives everything else in this guide.

Vendors shorten the term to eSeal. In the US the same words usually mean a notary's or an engineer's stamp image dropped onto a PDF. The eIDAS seal isn't a picture of anything. It runs on the same public-key cryptography as a digital signature: a private key, a certificate tying that key to an identity, and a hash of the document that breaks if a single byte changes. What differs is whose identity sits in the certificate, and what the act claims.

A signature says a person agreed. A seal says an organization issued. Plenty of regulated files carry both: an officer signs the report, then the company seals the finished file before it goes out.

Most e-signature tools never mention seals, so the split is worth spelling out.

A signature carries intent. Someone read the document and agreed to be bound, and the law cares about that consent. A seal carries provenance: this file left our systems in exactly this state. It says nothing about anyone agreeing to anything.

The certificates show it. A signing certificate names a person. A seal certificate, under Annex III of eIDAS, carries at least the organization's name and, where one exists, its registration number from the official records. There's no human in the subject field, and that's by design.

Volume is where a seal earns its place. No employee can honestly sign 40,000 payslips; pretending otherwise invents a consent that never happened. A seal makes the honest claim instead: the company issued these, and the company stands behind them.

It also survives staff turnover. When the person holding a signing certificate leaves, every future document needs a new signer, while the company's seal keeps working. Which signature level a contract needs is a separate question, and our guide to QES and the signature levels answers it.

Seals come in the same three grades as signatures, and the words mean the same things.

Electronic seal. Anything that meets the Article 3(25) definition. Article 35(1) still protects it: a court can't refuse it as evidence just because it's electronic or isn't qualified.

Advanced electronic seal. Article 36 adds four conditions. The seal is uniquely linked to the organization, it can identify that organization, it's created with seal creation data the organization can use "with a high level of confidence under its control", and it's bound to the data so any later change is detectable.

Qualified electronic seal. An advanced seal created on a qualified seal creation device and based on a qualified certificate for electronic seals (Article 3(27)). A qualified trust service provider (QTSP) issues the certificate to the Annex III requirements. The device meets the Annex II requirements written for signature devices, applied to seals by Article 39, and since the 2024 amendment a QTSP may run it remotely on the company's behalf (Article 39a).

What does the qualified grade buy? Article 35(2): a qualified electronic seal "shall enjoy the presumption of integrity of the data and of correctness of the origin of that data". The burden of proof moves. If a customer claims your sealed statement was altered, they have to show it; with an advanced seal, you'd be the one proving it wasn't.

Cross-border recognition used to sit in Article 35(3). Regulation (EU) 2024/1183 deleted that paragraph and moved the rule into the new Article 24a: a qualified seal from one Member State counts as qualified in all the others. Everything else the 2024 amendment changed is a longer story.

Public bodies also use a level in between, the advanced seal based on a qualified certificate. Article 37 names it and Article 40a gives it its own validation rule.

Most companies don't need one. Better to say that before the list talks you into anything: if your documents are contracts going out for a person's approval, signatures cover you and a seal adds cost without adding much.

Seals fit four situations:

• Documents nobody signs. Certificates, transcripts, account statements, payslips, registry extracts. The organization issues them from its records; no named person agrees to anything.
• Output from a system, at volume. Thousands of files a month generated by software, often overnight. A seal fits that shape and a personal certificate doesn't.
• Public bodies and automated decisions. Spain's Ley 40/2015 lets an administration identify itself with an electronic seal (article 40) and use one for automated administrative action, where no official touches the decision (article 42). In Germany, § 371a(3) ZPO presumes a public authority's electronic document genuine when the authority has added a qualified signature or a qualified seal.
• Records that must stay provable for years. People change jobs; the company's identity outlives them.

Invoices sit in a grey zone. Article 233 of the EU VAT Directive asks you to guarantee the authenticity of origin and the integrity of every invoice, then leaves the method to you: "any business controls which create a reliable audit trail" will do, and the directive's own technology example is an advanced electronic signature, not a seal. So no EU rule forces a seal onto invoices. A seal just shortens the argument in an audit, because it's a property of the file rather than a process you have to describe. How sealed and signed e-invoices get validated covers the formats.

There's also an escape hatch. Where a rule demands a qualified seal, the Commission's eSignature FAQ says a qualified signature from the company's authorized representative is equally acceptable.

Ordinary B2B contracts aren't on this list. They want signatures.

eIDAS is a regulation, so its seal rules apply directly in every EU Member State. National laws mostly add who supervises the providers and how courts weigh the result. Outside the EU the picture changes: the UK kept the seal articles in its retained version of eIDAS, and the US never created a seal at all. The table sums up the texts cited in this guide. It isn't legal advice for a specific deal.

Sealing is a trust service you buy, not software you install. The usual sequence:

1. 1.
   Pick a provider that's qualified for seals. For a qualified electronic seal, the provider has to appear on the EU Trusted List with a service for qualified certificates for electronic seals. A signature entry isn't enough, so check the service type. Our explainer shows how to read a Trusted List entry.
2. 2.
   Prove the company exists and that you can act for it. Here seals really do differ from personal certificates. Spain's Ley 6/2020 spells it out in article 7.4: the provider checks the company's incorporation and legal personality, plus the applicant's powers of representation, against public documents or the commercial register. Article 9.3(a) then makes it record which person received the certificate. Budget extra calendar time.
3. 3.
   Decide where the private key lives. Either on a certified device you run, usually a hardware security module, or on a remote device the provider operates for you under Article 39a. Remote suits most automated setups, because sealing happens inside a job at 3 a.m., not at someone's desk.
4. 4.
   Wire it into whatever produces the documents. Providers usually expose sealing over an API, so your billing or records system calls it once per file.

Behind every qualified electronic seal certificate sit ETSI standards, named by Implementing Regulation (EU) 2025/1943: EN 319 411-2 for the provider's policy, the EN 319 412 family for the certificate profile. You won't read them, honestly, but your provider's certificate policy should cite them.

Price is the part nobody can answer for you. QTSPs set their own rates and there's no EU-wide list, so ask two or three for quotes.

There's no separate procedure for seals. Article 40 of eIDAS applies the signature rules, Articles 32 to 34, to qualified electronic seals "mutatis mutandis", and Implementing Regulation (EU) 2025/1945 names one set of standards for both: ETSI TS 119 172-4 for the validation policy, TS 119 102-2 for the report.

What an electronic seal validation checks

Read with seals in mind, Article 32(1) is your checklist. A validator confirms that:

• the certificate was a qualified certificate for electronic seals, meeting Annex III, when the seal was applied;
• a QTSP issued it and it was valid at that moment, not merely today;
• the validation data matches what you were given, and the organization's identity is presented correctly;
• the seal was made on a qualified seal creation device;
• the sealed data hasn't changed since;
• the advanced-seal requirements of Article 36 were met at the time.

Drop the device check and you have the test for an advanced seal based on a qualified certificate (Articles 32a and 40a).

Expect three verdicts, not two. "Indeterminate" means the evidence was incomplete, for example missing revocation data, and that isn't the same as invalid. A seal from a reputable commercial CA that isn't on the Trusted List can validate cleanly and still not be qualified.

Which checker reads which file

• A sealed PDF is a PAdES file, which PDF signature verification reads.
• Structured invoices and public filings are usually XAdES. Use XAdES verification for those.
• CAdES files (.p7m, .p7s) and ASiC containers (.asice) go through the same service as the rest.

Not sure what you've got? Chaindoc's signature verification reads all four formats, seals included, and checks the certificate against the EU Trusted List. You confirm your email with a one-time code before the first check.

Once a validation report is open, telling a seal from a signature takes seconds if you know where to look.

The subject is an organization

A signing certificate carries a given name and a surname. A seal certificate carries the organization's legal name, its country and an organization identifier. Annex III asks for at least the name and, where applicable, the registration number from the official records, and Implementing Regulation 2025/1943 adds that the organizationIdentifier field must carry that registration number whenever one exists.

The identifier has a fixed structure

ETSI EN 319 412-1 defines it in clause 5.1.4: a three-letter type, a two-letter country code, a hyphen, then the number. VAT stands for a VAT number, NTR for a national trade register entry, PSD for a payment institution's authorization number, and LEI for a Legal Entity Identifier, which takes the country code XG. The standard's own example is VATBE-0876866142.

Check that value against the company you expected. A flawless seal from the wrong company is still the wrong company.

Qualified status is written into the certificate

Annex III wants a machine-readable statement that the certificate was issued as a qualified certificate for electronic seals, and a second one when the key sits on a qualified device. Validators read those flags together with the Trusted List. If either is missing, the seal can still be valid without being qualified.

Straight answer: Chaindoc doesn't issue electronic seals. It isn't a qualified trust service provider, and nothing here should read as if it were. If your company needs its own seal, the certificate and the sealing device come from a QTSP on the Trusted List.

DocuSign is ahead on this one. Its French site says it offers simple, advanced and qualified electronic seals and describes DocuSign as a qualified trust service provider. If a DocuSign eSeal is what your workflow needs, that's a fair reason to look there.

Chaindoc covers the other half of the job. People sign in Chaindoc's signing flow: the server hashes each file on upload, the version hash goes on chain when you publish, and each signer's proof is recorded when signing completes. The PDF signature itself is PAdES-BES, without a timestamp from a timestamp authority. When a sealed file lands in your inbox, the verification service checks it against the EU Trusted List and shows each check.

So the split stays simple. Sign what a person agrees to, seal what your organization issues, and verify an electronic seal before you rely on it.