Qualified Electronic Seal: Requirements & Lab Use

Technical disclaimer: This article provides technical information, not legal advice. Whether a qualified electronic seal satisfies your specific regulatory obligations should be assessed by a qualified legal adviser.

A qualified electronic seal (QSeal) sits at the top of the electronic seal hierarchy defined in eIDAS Regulation (EU) No 910/2014. It carries a legal presumption of integrity and origin under Article 35, must be issued under a qualified certificate by a Qualified Trust Service Provider (QTSP), and must be created using a Qualified Seal Creation Device (QSCD). It binds to a legal entity - not an individual.

That last point matters more than it might seem. A seal belongs to the organisation, not to the person operating the system. If you need clarity on how that plays out legally, the seal versus signature page covers that boundary in full.

The eIDAS seal hierarchy: simple, advanced, and qualified

eIDAS defines three tiers of electronic seal. The basic (simple) seal carries no specific technical requirements and no automatic legal presumption. The advanced electronic seal must meet four criteria under Article 26: it must be uniquely linked to the creator, capable of identifying the creator, created using data the creator controls, and linked to the sealed data so that any subsequent change is detectable. For a grounding in what an electronic seal is at all, the eIDAS electronic seal basics page is the right starting point.

Comparison table showing that the qualified electronic seal adds a legal presumption of integrity and origin under Article 35, requires a qualified certificate and QSCD, and provides automatic…

The qualified electronic seal builds on all of that. It satisfies every advanced seal requirement, adds a qualified certificate, mandates a certified QSCD, and triggers a specific legal effect that the lower tiers do not reach.

The Article 35 presumption - what it actually means: Any data bearing a valid qualified seal is presumed to be intact and to originate from the identified legal entity, unless proven otherwise. No court or counterparty has to accept your word for it; the legal presumption does that work automatically across all EU member states.

Advanced vs qualified electronic seal

Attribute	Advanced electronic seal	Qualified electronic seal
Legal presumption	None automatic	Integrity + origin presumed (Art. 35)
Certificate type	Advanced certificate	Qualified certificate (Annex III)
Creation device	Any secure device	QSCD (Annex II)
Issuer	Any Certificate Authority	Qualified TSP on EU Trusted List
Cross-border recognition	Contractual	Automatic across all EU member states
Suitable for lab reports?	Often sufficient	Required when regulation mandates it

Legal and technical requirements under eIDAS

What Article 36 requires

Article 36 sets out three conditions that must all be met simultaneously:

The seal must be based on a qualified certificate for electronic seals (Annex III).
It must be created using a Qualified Seal Creation Device (Annex II).
It must be linked to the legal entity that created it.

These are cumulative. A seal produced with a qualified certificate but on a non-certified device is not a qualified electronic seal, regardless of how secure that device might otherwise be.

The qualified certificate for electronic seals (Annex III)

Annex III of eIDAS Regulation (EU) No 910/2014 specifies what the qualified certificate must contain: the legal entity's name, its registration number from an official register, the public key, and the identity of the issuing QTSP.

To confirm that a QTSP is authorised to issue these certificates, check the EU Trusted List. Each EU member state maintains a national Trusted List; the European Commission aggregates these into a List of Trusted Lists (LOTL). A QTSP offering qualified electronic seal services must appear there with the correct service type. For guidance on evaluating and selecting a QTSP, see qualified trust service providers.

Conformity assessment and supervision

QTSPs operate under the supervisory regime established by eIDAS Article 17: national supervisory bodies audit them and can suspend or revoke their qualified status. The QSCD itself must be assessed for conformity against the EN 419 221 series of standards, published by ETSI and CEN. Conformity is not self-declared - an accredited third-party conformity assessment body must certify the device. That certification is the technical backstop that gives the qualified seal its legal weight.

A note on eIDAS 2.0: Regulation (EU) 2024/1183 entered into force and is shaping national implementation in 2026. The core requirements of Article 36 remain intact for qualified seals; the main 2026 changes relate to the European Digital Identity Wallet and expanded QTSP obligations, not to the seal definition itself.

What a QSCD must provide

Annex II requirements in plain terms

A Qualified Seal Creation Device is a hardware environment that meets eIDAS Annex II. In practice, that means:

The sealing key pair is generated inside the device.
The private signing key is stored inside the device and cannot be exported.
The private key cannot be derived or forged by any technically feasible means.
All signing operations are confined to the device - the private key never leaves it.
The device is tamper-resistant and detects or prevents physical interference.

These properties separate a QSCD from a standard HSM used for general cryptographic operations. A standard Hardware Security Module can be configured in many ways, and some configurations allow key export or backup. A QSCD-certified HSM must meet Annex II's specific constraints, verified through EN 419 221 conformity assessment.

On-premises HSM vs remote QSCD

A QSCD takes two practical forms in lab environments:

On-premises HSM: A physical appliance installed in your own infrastructure, certified to Annex II, and operated by your IT or security team.
Remote QSCD: The QTSP hosts and manages the certified hardware on your behalf and exposes the sealing capability through an API.

Both satisfy eIDAS Annex II, provided the underlying device is certified. Neither is self-declared.

HSM-based sealing in automated lab report pipelines

How an on-premises HSM fits into a lab sealing pipeline

Five-step diagram of an on-premises HSM sealing pipeline: the LIMS produces a PDF, a hash is sent to the HSM, the HSM signs it, the signature is wrapped into a PAdES PDF, and the sealed PDF is…

When a lab runs its own certified HSM as a QSCD, the sealing process follows a clear sequence:

The lab's LIMS or report generator produces a finished PDF.
The sealing service computes a hash of that document and sends it to the HSM.
The HSM signs the hash using the private sealing key, which never leaves the device.
The sealing service wraps the signature into a PAdES structure and returns the signed PDF.
The sealed PDF moves to the delivery portal for recipient access.

The signing key stays inside the HSM at every step. Non-repudiation is enforced by design: because the private key cannot be exported, only the device could have produced that signature, and only the lab controls the device.

For labs building this architecture into a broader certificate portal, the eIDAS Lab Portal: Architecture & Integration Guide covers the full system design.

On-premises vs cloud HSM: choosing the right path

Trade-off	On-premises HSM	Cloud HSM (QTSP-hosted)
Key custody	Full lab control	QTSP-managed
Latency	Low (local network)	Dependent on API round-trip
Throughput	Hardware ceiling	QTSP SLA-bound
Vendor lock-in	Hardware vendor	QTSP API
Operational burden	High (HSM administration)	Low
Initial cost	High capital expenditure	Subscription / OPEX

The right choice depends on how many documents your lab seals per day, whether your IT team can manage key custody, and your data residency requirements. Labs issuing a few hundred certificates per month usually find that a cloud HSM through a QTSP is the lower-friction path. High-volume environments with strict data residency constraints - common in medical diagnostics - often justify the capital expenditure of on-premises hardware.

If you want to see what this looks like in practice, our sealed certificate portal development service page describes how Sandorian builds these pipelines for regulated labs.

Remote qualified sealing: what it means and when it fits

How remote sealing works

In a remote qualified sealing model, the private signing key lives on a QSCD operated by your QTSP. Your lab's sealing service sends the document hash to the QTSP's sealing API; the QTSP signs the hash inside their QSCD and returns the signature. Your lab never touches the private key and never operates certified hardware. The resulting seal is still a qualified electronic seal under eIDAS Article 36, provided the QTSP and device are properly qualified.

When remote sealing is the right fit

Remote sealing suits labs that:

Lack the budget or personnel to operate and audit on-premises HSM hardware.
Need qualified sealing capability running quickly.
Seal documents at volumes the QTSP's API SLA can handle comfortably.
Operate across multiple sites where a single QTSP API endpoint is easier to govern than distributed HSMs.

Where remote sealing introduces risk

Remote sealing makes your sealing pipeline dependent on a third-party API. Risks to plan for include:

API availability: If the QTSP's sealing endpoint is down, your lab cannot issue sealed certificates. Build failover and retry logic into the pipeline accordingly.
Hash transmission security: The document hash - and in some implementations the document itself - travels to the QTSP over the network. Use mutual TLS and confirm your QTSP's data processing agreements cover your jurisdiction's requirements.
Vendor lock-in: Switching QTSPs means re-issuing certificates under a new qualified certificate and potentially migrating pipeline integrations.

Remote sealing keeps your lab out of the key-management business - but it makes your sealing pipeline directly dependent on a third-party API's availability. That is a genuine architectural tradeoff, not a footnote.

When labs need a qualified electronic seal

Regulatory triggers: when a qualified seal is mandatory

Checklist of five questions lab managers should answer to determine whether a qualified electronic seal is mandatory, covering regulations, customer requirements, IVDR, accreditation body rules, and…

A qualified seal becomes mandatory when:

A specific EU regulation or national sectoral rule explicitly names a qualified electronic seal as the required level.
A relying party - your customer, a notified body, or a regulatory authority - contractually or technically requires the Article 35 legal presumption.
The lab operates in a framework where cross-border legal enforceability without additional evidence is required, such as IVDR technical documentation submitted to a notified body in another member state.

When an advanced seal is often sufficient

Many labs issue perfectly valid certificates under an advanced electronic seal. If your customers are domestic, no applicable regulation names a qualified seal, and your relying parties accept advanced-level assurance, you may not need the additional infrastructure. Whether your specific arrangement satisfies your obligations is a legal question - seek qualified legal advice before concluding either way.

Decision checklist for lab managers

Use this checklist to assess whether your lab likely needs a QSeal:

Does any applicable regulation (EU or national) explicitly name a qualified electronic seal?
Do your customers or notified bodies require cross-border presumption of integrity and origin?
Are you issuing certificates under IVDR or another framework requiring non-repudiation?
Does your accreditation body specify a minimum seal level for issued certificates?
Do you need the Article 35 legal presumption to hold automatically in potential disputes?

If you answered yes to any of these, engage a QTSP and consult a qualified legal adviser. For the software obligations that sit alongside seal requirements, ISO 17025 software requirements: validating your LIMS and lab tools covers what your LIMS and surrounding tools need to demonstrate.

Integrating qualified sealing into a lab certificate portal

Where sealing sits in the pipeline

A qualified sealing integration follows this sequence:

Lab LIMS produces the completed test or calibration record.
Report generator renders the record as a PDF document.
Sealing service calls the QSCD (on-premises HSM or remote QTSP API), applies the qualified seal, and receives a PAdES-structured signed PDF.
Delivery portal stores and presents the sealed PDF to the recipient.
Recipient verifies the seal using their PDF reader or validation service, optionally checking the QTSP against the EU Trusted List.

The key custody boundary sits between your sealing service and the QSCD. Nothing crosses that boundary except the document hash and the returned signature value.

PAdES: the right container format for sealed lab PDFs

PAdES (PDF Advanced Electronic Signatures), standardised by ETSI, is the correct container format for a qualified seal on a PDF lab certificate. It embeds the signature, the signing certificate chain, and revocation information directly inside the PDF file, making the sealed document self-contained and validatable offline.

Labs typically use one of these PAdES levels:

PAdES-B: Signature only. Suitable for short-lived documents but carries no long-term validation data.
PAdES-T: Adds a qualified timestamp to prove the seal existed at a specific point in time.
PAdES-LT: Embeds revocation data (CRL or OCSP response) so the document can be validated without network access.
PAdES-LTA: Adds archive timestamps for long-term re-validation - recommended for calibration certificates with multi-year retention requirements.

For detailed guidance on timestamping and its legal context, see adding a qualified timestamp to reports.

Automated sealing API patterns

Labs sealing documents at scale have two main API patterns to choose from.

Synchronous sealing is the simpler approach: the lab portal sends a document hash, waits for the QTSP to return the signature, embeds it into PAdES, and hands back the sealed PDF in a single request cycle. This works well at low to moderate volumes and keeps pipeline logic straightforward.

Asynchronous sealing with webhooks suits high-volume batch jobs - end-of-day certificate runs, for example. The portal submits a batch of hashes, receives a job ID, and the QTSP calls a webhook endpoint when the batch is complete. Error handling needs to account for partial failures: individual documents can fail even when the batch as a whole succeeds, so retry logic should track document-level status rather than batch-level status.

In both patterns, build idempotent submission so that a network timeout does not result in double-sealing the same document.

How Sandorian approaches these integrations

From our work building sealed lab report delivery systems, the single biggest decision point is not the QSCD itself - it is where the key custody boundary sits relative to the lab's existing infrastructure and data residency requirements. Labs that already run regulated IT environments (ISO 17025-accredited, IVDR-compliant) often have security governance processes that make on-premises HSM custody tractable. Labs without that infrastructure consistently benefit from starting with a remote QSCD through a QTSP, then re-evaluating once volume justifies the operational overhead of hardware custody.

Our work with ViroVet Diagnostik is an example of how these integration decisions play out in a real diagnostic lab context.

Ready to design a qualified sealing pipeline for your lab's certificate portal? Discuss qualified sealing for your report pipeline with a Sandorian engineer.

Frequently asked questions

What is a qualified electronic seal under eIDAS?
A qualified electronic seal is an electronic seal that meets all three requirements of eIDAS Article 36: it is based on a qualified certificate for electronic seals, it is created using a Qualified Seal Creation Device, and it is linked to the legal entity that issued it. It carries a legal presumption of integrity and origin under Article 35.

How is a qualified seal different from an advanced electronic seal?
An advanced seal can be created with any secure device and any certificate. A qualified seal requires a QSCD and a qualified certificate issued by a QTSP on the EU Trusted List. Only the qualified seal triggers the Article 35 legal presumption automatically across all EU member states.

What is a QSCD?
A Qualified Seal Creation Device is a hardware device that generates and stores sealing keys in a tamper-resistant environment. Under eIDAS Annex II, the private key must not be derived, forged, or extracted, and all signing operations must remain confined to the device.

Does a testing or calibration lab always need a qualified electronic seal?
Not necessarily. A qualified seal is required when a regulation, customer contract, or relying party explicitly demands the Article 35 legal presumption. Many labs operate adequately with an advanced seal. The decision depends on regulatory context and customer requirements - always seek legal advice for your specific situation.

What document format do qualified seals use for lab PDF certificates?
PAdES is the standard format for qualified-sealed PDF documents. Labs issuing calibration or test certificates typically use PAdES-LT or PAdES-LTA to embed the signature, certificate chain, and revocation information within the PDF itself.

How do I verify that a QTSP is qualified?
Check the EU Trusted List at eidas.ec.europa.eu/efts. A QTSP offering qualified electronic seal services must appear there with the correct service type, as maintained by the member state's national supervisory body.

Qualified Electronic Seal: Requirements and Lab Use