Organisations that run automated document pipelines often sign invoices, statements and certificates with an employee's signing certificate, when the law already provides a separate instrument, the electronic seal, built for exactly that job. Under eIDAS, a signature is created by a natural person and a seal is created by a legal person, and that single difference changes the certificate profile, the control requirement on the private key, the legal presumption you get and who is accountable when the key is misused. This guide compares qualified and advanced electronic seals with qualified and advanced electronic signatures, with most attention on seals used by machines: batch jobs, integration platforms and AI agents that issue documents on an organisation's behalf. It is for security architects, PKI owners, finance and legal operations teams and anyone designing a signing service. For the legal versus cryptographic meaning of "signature", see the Digital Signature vs Electronic Signature, and for the choice between signature levels, see the Advanced vs Qualified Electronic Signature.
Status line (checked 14 November 2026): based on Regulation (EU) No 910/2014 as amended by Regulation (EU) 2024/1183, using the EUR-Lex consolidated text dated 18 October 2024, ETSI EN 319 412-3 V1.4.1 (2026-07) and ETSI EN 319 412-1 V1.5.1 (2023-09). eIDAS 2.0 implementing acts are still being adopted, so confirm the current text before relying on a date.
Key takeaways
- Who creates it decides the instrument. Article 3(9) defines a signatory as a natural person; Article 3(24) defines the creator of a seal as a legal person. A company cannot sign in the eIDAS sense, and a person cannot seal.
- Seals prove origin, signatures carry intent. Article 3(25) says a seal ensures the origin and integrity of data. A qualified seal is presumed to show integrity and correct origin (Article 35(2)); only a qualified signature has the equivalent legal effect of a handwritten signature (Article 25(2)).
- Control differs: sole versus organisational. An advanced signature needs signature creation data under the signatory's sole control (Article 26); an advanced seal needs seal creation data the creator can use under its control (Article 36). That wording is what lets a server, HSM or remote service use a seal key without a person present.
- A seal key is a privileged machine credential. Anything that can call the sealing key can produce documents the law presumes came from your organisation. Govern it like a production signing key, with owners, scoped callers, logging and rotation.
- Qualified status is a list entry, not a label. A provider and its services are qualified only if they appear in a national trusted list (Article 21(3) and the EU trusted list system), and the certificate itself must say it is a qualified certificate for electronic seal (Annex III(a)).
The short answer
Use an electronic signature when a human being must express agreement, approval or intent: a director accepting a contract, an employee authorising a payment, a doctor signing a prescription. Use an electronic seal when the organisation itself vouches for a document and no individual's intent is being recorded: invoices, bank statements, certificates of insurance, diplomas, API responses and logs that third parties must be able to attribute to you. Choose the qualified level of either when the counterparty, a public body or a sector rule needs the statutory presumption or cross-border recognition under Article 24a; choose the advanced level where you control the relationship and can prove reliability another way. Never put a named employee's signing key inside an automated pipeline to stand in for a seal: it breaks the sole control requirement, misattributes intent and creates a joiner, mover and leaver problem the moment that person changes role.
Side by side
| Dimension | Electronic signature | Electronic seal |
|---|---|---|
| Creator | Natural person, the signatory (Art. 3(9)) | Legal person, the creator of a seal (Art. 3(24)) |
| Purpose in the definition | Data the signatory uses to sign (Art. 3(10)) | Data that ensures origin and integrity of other data (Art. 3(25)) |
| Advanced level | Art. 26: uniquely linked to and identifies the signatory, data under the signatory's sole control, changes detectable | Art. 36: uniquely linked to and identifies the creator, data the creator can use under its control with a high level of confidence, changes detectable |
| Qualified level | Art. 3(12): advanced signature from a qualified signature creation device (QSCD) with a qualified certificate | Art. 3(27): advanced seal from a qualified seal creation device with a qualified certificate for electronic seal |
| Legal effect of qualified level | Equivalent legal effect of a handwritten signature (Art. 25(2)) | Presumption of integrity of the data and correctness of its origin (Art. 35(2)) |
| Qualified certificate content | Annex I: signatory's name or pseudonym | Annex III(c): at least the seal creator's name and, where applicable, registration number |
| Typical subject fields | Natural person profile (ETSI EN 319 412-2) | countryName, organizationName, organizationIdentifier, commonName (ETSI EN 319 412-3, LEG-4.2.1-2) |
| Remote creation device | Managed only by a qualified trust service provider (Art. 29a) | Art. 29a applied to seals by Art. 39a |
Both instruments usually rest on the same cryptography: a private key, an X.509 certificate and an AdES format such as PAdES, XAdES, CAdES, JAdES or ASiC. A validator cannot tell a seal from a signature by the mathematics. It tells them apart by the certificate: the subject identifies a legal person, and a qualified certificate carries a machine-readable statement of its type (the ETSI QcType values distinguish e-signature, e-seal and website certificates).
Signatures in depth: threat model, architecture and failure modes
Threat model: impersonation of the signatory, a signer tricked into signing something other than what they saw, and repudiation. The qualified level answers repudiation with a statutory presumption, so disputes focus on how the signer was identified and whether they really controlled the key.
Architecture in words: the provider verifies the person (Article 24(1a) lists the European Digital Identity Wallet or a notified eID at assurance level high, an existing qualified certificate, other methods confirmed by a conformity assessment body, or physical presence). The key lives on a card, token or a remote QSCD run by a qualified provider, and each signing event needs the signer's own authentication.
Failure modes and controls: shared tokens or PINs, keys copied to a server so a script can sign "as" a manager, and leavers whose certificates stay valid. Issue one certificate per person, tie activation to strong authentication and revoke on HR leaver events. Revocation of a qualified certificate is immediate and cannot be reversed (Article 38(4) states this for seal certificates and the signature rules mirror it), so plan reissue rather than reinstatement.
Seals in depth: threat model, architecture and failure modes
Threat model: the seal key is valuable precisely because nobody has to approve each use. An attacker who can reach the sealing service, or steal its key, can mint invoices with altered bank details, fake certificates or forged statements that relying parties are entitled to presume came from you.
Architecture in words: the organisation obtains a certificate for electronic seal naming the legal person. Under ETSI EN 319 412-3 the subject must carry countryName, organizationName (the full registered name), organizationIdentifier and commonName, each once. Under ETSI EN 319 412-1 clause 5.1.4, organizationIdentifier follows a set pattern: a three-letter type (VAT, NTR for a national trade register, PSD for payment service providers, LEI for a Legal Entity Identifier), a country code, a hyphen and the identifier, as in VATBE-0876866142, with LEI using the code XG. The private key sits in an HSM or qualified seal creation device, on premises or as a remote service run by a qualified provider under Articles 29a and 39a. Business applications never hold the key: they call a sealing API that authenticates the caller, checks the document type against policy, applies the seal, adds a timestamp and writes an audit record.
Failure modes: one seal certificate shared across every application, so a low-value integration can seal high-value documents; long-lived static API keys guarding the sealing endpoint; seal keys exported as software files for convenience; no inventory of which certificates exist for which legal entities; and sealing performed by a vendor platform with its own key, which proves the platform's origin rather than yours.
Seals for machine-issued documents: the non-human identity angle
A seal is the eIDAS instrument that fits non-human actors. A batch job, an ERP integration or an AI agent has no legal intent of its own; what the law cares about is that the organisation stands behind the output. That means the seal key is a shared organisational credential operated by machines, and it should be governed with the same discipline as any other high-impact non-human identity. See the Cryptographic Key Management Guide for key lifecycle controls.
| Design question | Weak pattern | Stronger pattern |
|---|---|---|
| Who may call the seal key? | Any service holding a shared API key | Named workloads with their own identity, allow-listed per document type |
| Where is the key? | PKCS#12 file on an application server | Non-exportable key in an HSM or qualified seal creation device, local or remote |
| How many certificates? | One for the whole group | One per legal entity, split further where document classes differ in risk |
| AI agent output | Agent holds the seal credential directly | Agent submits to a sealing service that applies policy, human approval for high-value classes and full logging |
| Evidence | Application logs only | Seal log with caller identity, document hash, policy decision and timestamp token |
For AI agents, treat sealing as a tool with an explicit authorisation boundary. The agent should never possess the key or a long-lived credential to it; it should request a seal through an interface that checks the request against the agent's permitted document types and volume, and that records which agent, model version and upstream user triggered the request. See the AI Agent Identity vs Service Account for how to give agents their own identities rather than borrowing a service account.
Legal effect, evidence and e-invoicing
Article 35(1) says a seal cannot be denied legal effect or admissibility as evidence solely because it is electronic or not qualified, mirroring Article 25(1) for signatures. The difference lies in the presumption. A qualified seal shifts the burden: the party disputing the document must rebut integrity and origin. An advanced seal is evidence too, but you may have to prove its reliability, which is where your key custody records, logs and timestamps earn their keep.
Electronic invoicing is the commonest reason organisations meet seals. Article 233 of the VAT Directive, as replaced by Directive 2010/45/EU, requires the authenticity of origin, integrity of content and legibility of an invoice from issue to the end of the storage period, and lets each taxable person choose how, including business controls that create a reliable audit trail. It names an advanced electronic signature based on a qualified certificate and created by a secure device, and EDI with suitable procedures, as examples. Check the current national rule for each country you invoice into, as digital reporting rules are changing.
| Document or event | Instrument | Suggested level | Reason |
|---|---|---|---|
| Outgoing e-invoices issued by ERP | Seal | Advanced or qualified, per national and buyer rules | Origin and integrity of a document from the company, no personal intent |
| Bank or insurance statements in bulk | Seal | Qualified | Third parties rely on origin; presumption reduces disputes |
| Diplomas, licences, official certificates | Seal | Qualified | Cross-border recognition under Art. 24a(1) |
| Contract accepted by a director | Signature | QES where written form is required, otherwise AdES | Records a person's intent |
| Contract countersigned by the company platform | Seal plus personal signature | Seal for the platform evidence, signature for the person | The seal proves the final file came from you; it does not replace the signer |
| API responses or agent outputs needing provenance | Seal | Advanced; qualified where outsiders must rely on origin | Machine output attributed to the organisation |
eIDAS 2.0 changes that touch seals
- Remote seal creation devices: Article 3(23b) defines a remote qualified seal creation device, and Article 39a applies the Article 29a rules, so only a qualified trust service provider may manage one on the creator's behalf.
- Cross-border recognition: Article 24a(1) to (3) recognises qualified seals, certified qualified seal creation devices, qualified seal certificates and remote device management from one Member State in all others.
- Identity verification: Article 24(1a) sets the routes a provider may use before issuing a qualified certificate, including the European Digital Identity Wallet and an existing qualified signature or seal certificate. For a seal, the provider verifies the organisation and the authority of the person requesting on its behalf.
- Certificate rules: Article 38 now states that a revoked qualified seal certificate cannot return to valid status, allows national rules on temporary suspension that must show in status services, and called for reference standards by 21 May 2025.
- Validation of advanced seals on qualified certificates: Article 40a applies the Article 32a validation rules to advanced seals based on qualified certificates, closing a gap between the advanced and qualified levels.
For the wallet and wider framework, see the eIDAS 2.0 and the European Digital Identity Framework Guide; for provider obligations and supervision, see the eIDAS Qualified Trust Services Guide.
Decision guidance and trade-offs
- Seal or signature: ask whose intent the document records. If it is one person's, sign. If it is the organisation's, or no one's because a system produced it, seal. Where both apply, use both.
- Qualified or advanced seal: qualified costs more and ties you to a listed provider and certified device, but gives the Article 35(2) presumption and Article 24a recognition. Advanced suits internal provenance, B2B flows with agreed terms and high-volume machine output where the counterparty accepts it.
- Local HSM or remote qualified service: a local HSM gives you full control and low latency,. A remote service run by a qualified provider moves device certification and much of the key protection to them, and you must secure the API path, the caller credentials and the activation method.
- Small organisations: one qualified seal certificate from a remote service, called only by the invoicing system through a dedicated workload credential, is usually enough.
- Large groups: issue one seal per legal entity, split by document class where values differ, run a central sealing service with policy enforcement, and feed seal events into the SOC.
Worked scenario: a group issuing invoices and certificates through an agent
A logistics group with three EU subsidiaries uses an AI agent to assemble customs certificates and an ERP to issue invoices. Today, all PDFs are signed with the finance director's QES through a token left in a server. The redesign: each subsidiary obtains a qualified certificate for electronic seal, with organizationIdentifier based on its VAT number. Keys are held by a remote qualified seal creation device service. A central sealing API accepts requests from two workload identities, "erp-invoicing" (invoices only) and "customs-agent" (customs certificates only, maximum 500 per day, values above a threshold queued for human approval). Each request is logged with caller, document hash, document type and timestamp token. The director's QES is kept for contracts only and the server token is revoked.
How to implement
- Inventory: list every certificate used for document signing or sealing, the subject type (person or organisation), key location, calling systems and owner.
- Classify documents: for each document type record whose intent it carries, who relies on it, any national or sector rule, and the level required.
- Choose providers: confirm on the Commission's trusted list browser that the provider and the specific service (seal certificates, remote seal device management, timestamps) are listed as qualified for the relevant country.
- Design key custody: HSM or qualified seal creation device, non-exportable keys, separate certificates per entity and risk class, and a sealing service in front of the key.
- Authenticate callers: give each calling system and agent its own workload identity, scope it to document types and volumes, and remove shared secrets.
- Pilot: seal a test set, validate it with the EU DSS library or the provider's validator, and confirm recipients and tax authorities accept the format (PAdES for PDF, XAdES for XML invoices).
- Cut over and roll back: run old and new paths in parallel for a cycle, then revoke personal certificates misused for sealing; keep the previous configuration documented until acceptance is confirmed.
- Operate: renew before expiry, review caller permissions quarterly, and rehearse key compromise: revoke, reissue, notify relying parties.
Detection and measurement
- Log: every seal operation with caller identity, document type, hash and time; failed authorisation attempts at the sealing API; certificate issuance and revocation events from the provider.
- Alert: sealing volume spikes by caller, a caller sealing a document type outside its policy, sealing outside business windows for human-triggered classes, and any use of a personal signing certificate by a service account.
- Metric 1: share of machine-issued documents sealed with an organisational certificate rather than a personal one (target 100%).
- Metric 2: number of seal certificates with a named owner and review date, against the total inventory.
- Metric 3: percentage of sealing callers using workload identity rather than static secrets.
- Metric 4: days of notice before seal certificate expiry, with no expiry-caused outages per quarter.
Common failure patterns
- Personal QES in a robot: a director's or finance officer's signing token used by a server breaks sole control and attributes every invoice to one person's intent.
- One seal for everything: a single certificate shared across subsidiaries and applications means any compromised integration can produce any document class.
- Trusting the badge, not the list: buying "qualified" seals without checking the trusted list entry for that exact service, or receiving a certificate without the qualified statement Annex III(a) requires.
- Platform seal mistaken for your seal: a vendor sealing the final file with its own certificate proves the file left the vendor unchanged, not that it came from your organisation.
- Stale entity data: after a merger the certificate still names a dissolved company or an old VAT number in organizationIdentifier, so validators and counterparties reject or question documents.
- Agent with direct key access: an AI agent handed a sealing credential can be steered by prompt injection into sealing attacker-supplied content as genuine.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AU-10 Non-repudiation | Signatures for personal actions, seals for organisational origin, with logs proving who triggered each |
| NIST SP 800-53 Rev. 5 | SC-12, SC-13, SC-17 | Key management, approved cryptography and PKI certificate issuance for seal and signature keys |
| NIST SP 800-53 Rev. 5 | IA-5, AC-6 | Authenticator management and least privilege for systems calling the seal key |
| NIST CSF 2.0 | PR.AA-01, PR.DS-01 | Identities for services managed; integrity of stored documents protected |
| ISO/IEC 27001:2022 Annex A | A.8.24 Use of cryptography | Rules for key custody, certificate profiles and lifecycle |
| eIDAS | Art. 25, 26, 35, 36, 38, 39a, Annex III | Legal effect, control requirements, certificates and remote devices |
Practitioner checklist
- Inventory every signing and sealing certificate with subject type, key location, callers and owner.
- Replace any personal signing certificate used by a system with an organisational seal.
- Issue separate seal certificates per legal entity and per high-risk document class.
- Keep seal keys non-exportable in an HSM or qualified seal creation device.
- Put a sealing service with caller authorisation, document-type policy and logging in front of the key.
- Give AI agents and integrations their own workload identities; never hand them the key.
- Check the provider and service on the EU trusted lists before buying "qualified".
- Confirm organizationIdentifier values after mergers, renames and VAT changes.
- Rehearse seal key compromise: revocation, reissue and notifying relying parties.
Standards and references
- EUR-Lex: Regulation (EU) No 910/2014 (eIDAS), consolidated text
- ETSI: EN 319 412-3 Certificate profile for certificates issued to legal persons
- ETSI: EN 319 412-1 Certificate profiles, overview and common data structures
- EUR-Lex: Council Directive 2010/45/EU on invoicing rules
- European Commission: EU Trusted Lists
- European Commission: Digital Signature Service (DSS)
Related NHI Mgmt Group resources: Digital Signatures Guide · Advanced vs Qualified Electronic Signature · eIDAS Qualified Trust Services Guide · E-Signature Platform Security · Cryptographic Key Management Guide