Electronic Seals Under eIDAS: What They Are and When Your Business Needs One

An electronic seal is the organizational counterpart to a signature: it proves a document came from a specific company or public body, and that nobody has altered it since. Regulation (EU) 910/2014, better 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(24) carries the part that matters most: the creator of a seal is "a legal person." Not a human being. A company, an association, a ministry.

That single distinction drives everything else on this page.

The name is unhelpful, honestly. Nothing about an electronic seal, or e-seal as most providers shorten it, resembles wax or a rubber stamp, and it isn't a picture of your company logo dropped onto a PDF. Underneath, a seal runs on the same cryptography as a digital signature: a private key, a certificate binding 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 is meant to claim.

A signature says a person agreed to something. A seal says an organization issued something. You can put both on the same file, and plenty of regulated workflows do: a compliance officer signs a report, then the company seals it before it goes out.

Ask a compliance team where seals fit and you'll usually get a shrug, because most e-signature vendors never bring them up. Here's the practical split.

A signature carries intent. Somebody read the thing and agreed to be bound by it, and the law cares about that consent. A seal carries provenance. It says this file left our systems in this exact state, and it says nothing at all about anyone agreeing to anything.

Which is why the certificates look different. A signing certificate names a person, with a given name and surname and often a national identifier. A seal certificate names an entity: legal name, country, and an organization identifier such as a VAT or business-register number. There's no human in the subject field, and that's the point rather than an oversight.

Where the difference becomes useful is volume. No individual can meaningfully sign forty thousand payslips, and pretending otherwise builds a fiction that falls apart the moment someone examines it. A seal handles that honestly. The organization issued these documents, the organization stands behind them, and nobody's personal intent is being claimed.

One more difference catches teams out. A seal survives staff turnover. When the person holding a signing certificate leaves, that certificate goes with them and every future document needs a new signer. An organizational seal keeps working, because the identity it certifies is the company.

If you're weighing which signature tier a contract needs, that's a separate question with its own answer. Our guide to qualified electronic signatures walks through the SES, AdES and QES ladder in detail, and this page won't repeat it. Seals climb a parallel ladder using the same vocabulary.

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

An advanced electronic seal has to satisfy four conditions under Article 36. It's uniquely linked to the organization that created it, it can identify that organization, it's created using seal creation data the organization keeps under its own control with a high level of confidence, and it's bound to the data so any later change shows up.

A qualified electronic seal is an advanced seal plus two things: the private key lives in a qualified electronic seal creation device, and the certificate is a qualified certificate for electronic seals issued by a qualified trust service provider on the EU Trusted List. Same architecture as a QES, different subject in the certificate.

What you buy with the qualified grade is Article 35(2), and it rewards slow reading. A qualified electronic seal "shall enjoy the presumption of integrity of the data and of correctness of the origin of that data." A presumption shifts who has to prove what. With an advanced seal, if a counterparty claims your invoice was altered, you're the one assembling evidence that it wasn't. With a qualified seal, they're assembling evidence that it was. In a dispute running over months, that reversal is the entire product.

Two further clauses round it out. Article 35(1) stops anyone dismissing a seal purely for being electronic, or for not being qualified, so an advanced seal is still real evidence. Article 35(3) makes a qualified seal issued in one member state automatically recognized in all the others, with no bilateral arrangement needed.

Most companies don't need one, and that's worth saying plainly before the rest of this section talks you into something.

If your document flow is contracts going out for human approval, signatures cover you and a seal adds cost without adding much. Seals earn their place in four situations. It's worth checking whether any of them describe you.

Documents nobody signs. Certificates, transcripts, account statements, policy documents, payslips, registry extracts. An organization issues these on the strength of its records, not because a named human agreed to anything. A seal is the honest way to stand behind them.

Output at volume. Once you're generating thousands of documents a month from a system rather than from a desk, personal certificates stop making operational sense. Seals were designed for this exact shape of problem.

Public-sector work is the third case, and it has the clearest law behind it. Article 37 covers seals in public services, and several member states built explicit national regimes on top. Spain is the sharpest example: Law 40/2015 lets a public body identify itself with a sello electrónico for automated administrative action, meaning decisions produced by a system with no official touching them. There's no person to sign, so the entity seals instead.

The fourth case is archival. If a document has to stay provable for a decade, whoever sealed it will have changed jobs long before then. Entity-level identity ages better than personal identity does.

Notice what isn't on that list: ordinary B2B contracts. Those want signatures.

Invoicing comes up in almost every seal conversation, usually with a misconception attached.

Article 233 of the EU VAT Directive requires you to guarantee the authenticity of origin and the integrity of an invoice's content, from issue until the end of the storage period. How you do that is your call. The directive names an advanced electronic signature and EDI as examples, and it puts business controls creating a reliable audit trail on exactly the same footing. So no, EU law doesn't require you to seal your invoices. Plenty of compliant businesses never have.

What a seal buys you is a shorter argument. Business controls are perfectly defensible, but they're a process you have to describe and evidence during an audit. A qualified seal is a property of the file that an auditor checks in about ten seconds, and it carries the Article 35(2) presumption along with it.

National practice varies more than the directive suggests. Italy's exchange system has long expected qualified signatures or seals on certain invoice flows, while Germany's B2B e-invoicing rollout doesn't mandate them at all. Check the country, not the continent.

The timetable is moving, though. Under the VAT in the Digital Age package, e-invoicing to the EN 16931 standard becomes mandatory for intra-Community transactions from 1 July 2030. That standard is structured XML, which puts the relevant seal format in XAdES territory rather than PAdES. If you're planning that far ahead, XAdES verification is the check you'll end up running.

Sealing is a trust service you buy, not software you install. The sequence runs roughly like this.

1. 1
   Pick a provider from the Trusted List. For a qualified seal it has to be a QTSP on the EU Trusted List. Anyone else can issue you a certificate, and it may be technically sound, but it won't be qualified and the Article 35(2) presumption won't apply to it.
2. 2
   Prove the organization exists and that you can act for it. Seal issuance genuinely differs from personal certificates here. The provider verifies the entity against a company register, then separately verifies that whoever requested the certificate is entitled to bind that entity. Expect registry extracts and evidence of signing authority, and budget more calendar time than a personal certificate would take.
3. 3
   Decide where the private key lives. Either in hardware you operate, meaning an HSM certified as a qualified seal creation device, or in a remote device operated by the provider. Remote is what most teams pick, because sealing usually happens inside an automated process at three in the morning rather than at somebody's desk.
4. 4
   Wire it into whatever generates the documents. Providers expose sealing over an API so your billing or document system can call it per file, which makes this an integration task rather than a desk procedure.

Pricing works differently from personal certificates. Seal certificates are typically sold per organization with some volume allowance attached, so cost scales with how much you seal rather than with headcount. Providers set their own rates and change them, so collect quotes from a couple of QTSPs instead of budgeting off a figure you read somewhere.

Here's the part that surprises people: there is no separate procedure for seals. Article 40 says Articles 32, 33 and 34 apply mutatis mutandis to the validation and preservation of qualified electronic seals. In plain terms, the law points at the qualified-signature validation rules and says do that. The technical procedure underneath is ETSI EN 319 102-1, the same one any serious validator implements for signatures.

So a validation report on a sealed file answers the same questions:

• Does the cryptographic hash still match the bytes in front of you, or has the document changed since sealing?
• Does the certificate chain reach a root the validator recognizes?
• Was the certificate live at the moment of sealing, not merely valid today? Revocation data over OCSP or a CRL settles that.
• Is there a trusted timestamp, and does it agree with the claimed sealing time?
• Is the issuer a QTSP on the EU Trusted List, and was the certificate issued as a qualified certificate for seals?

That last check separates a valid seal from a qualified seal, and the two verdicts aren't interchangeable. A seal from a reputable commercial CA that isn't on the Trusted List will validate cleanly and still not be qualified.

The file type decides which tool you reach for, not the fact that it's a seal. A sealed PDF is a PAdES file, so it goes through PDF signature verification. Structured invoices and public-sector filings are usually XAdES. Italian .p7m files are CAdES, and .asice containers are ASiC. Chaindoc's signature verification covers all four formats and checks signer certificates against the EU Trusted List. Validating at volume rather than one file at a time? That's what the API is for.

One practical warning about seals you intend to keep. A B-level seal carries no timestamp, so years later nothing proves when it was applied, and an expired certificate turns into a genuine problem instead of a non-issue. Anything headed for an archive should be sealed at LT or LTA, where the validation data travels inside the file itself.

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

An electronic seal certificate names an entity, not a person

A signing certificate carries a given name and a surname, often alongside a national personal identifier. A seal certificate carries none of that. What you'll find instead is the organization's legal name, its country, and an organization identifier.

The organization identifier has structure

That identifier isn't a free-text field. ETSI EN 319 412-1 defines a three-letter semantics prefix, then a country code, then the registered value. Three show up constantly in practice: VAT for a VAT number, NTR for a national trade register entry, and LEI for a Legal Entity Identifier. A German company's seal certificate might therefore carry VATDE-123456789, while a Dutch registry entry reads NTRNL- followed by the chamber of commerce number.

Check that value against the entity you actually expect to have issued the document. A cryptographically flawless seal from the wrong company is still the wrong company.

A seal and a signature can sit side by side

Nothing stops a document carrying both, and in regulated flows it's common: a named officer signs, then the issuing body seals the finished file. A validation report lists them separately, each with its own certificate and verdict, so read every entry rather than the headline. Two valid entries mean two different claims are being made, one about a person's agreement and one about an organization's issuance.

The failure patterns repeat, and almost none of them are technical.

Sealing things that needed a signature

The expensive one. A seal proves your organization issued a document. It says nothing about anybody consenting to its terms. If a regulator or a court needs evidence that a named person agreed, a seal won't supply it, and you tend to discover that at the worst possible moment.

Buying qualified when advanced would have done

Qualified costs more and takes longer to set up, and the Article 35(2) presumption only earns its keep where documents actually get challenged. Internal records and low-stakes issuance rarely justify it. Advanced seals remain real evidence under Article 35(1).

Two smaller ones are worth naming. Teams seal at B level, archive the result, then find years later that nothing proves when the seal was applied. And organizations treat the seal certificate as ordinary infrastructure, leaving its private key reachable by anyone with production access, which quietly undoes the point of a device the regulation insists stays under the entity's control.

If you take one thing away, match the instrument to the claim. An electronic seal is a narrow tool that does one job well: proving your organization issued this exact file, unaltered. Sign what a person agrees to, seal what your organization issues, and verify both before relying on either. Got a sealed file in front of you right now? Run it through the verifier and read the detailed report rather than the headline verdict.