Qualified Electronic Signatures Under eIDAS: Lab Guide

A qualified electronic signature (QES) under eIDAS Regulation (EU) No 910/2014 is an advanced electronic signature created with a qualified electronic signature creation device (QSCD) and backed by a qualified certificate issued by a qualified trust service provider (QTSP) listed on the EU Trusted List. Under Article 25(2) of eIDAS, a QES carries the equivalent legal effect of a handwritten signature and receives mandatory cross-border recognition across all EU member states - making it the highest-assurance tier in the three-level eIDAS signature hierarchy.

For regulated laboratories, that definition is not abstract. It determines which signature your accredited test certificates must carry, how your portal issues them, and whether they remain verifiable five years from now.

What eIDAS Actually Defines: Articles 3 and 25

Article 3(12) of eIDAS Regulation (EU) No 910/2014 defines a qualified electronic signature as "an advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures." Three components must all be present - not two of three, all three:

The signature must meet the four requirements in Article 26 as an advanced electronic signature.
A QSCD must have created it.
It must rest on a qualified certificate for electronic signatures issued by a QTSP that appears on the relevant EU Trusted List.

Article 25(2) delivers the legal consequence: a QES "has the equivalent legal effect of a handwritten signature." That equivalence applies across every EU member state without additional formality - a direct result of the regulation's status as EU law.

This is where QES separates from every lower-tier signature. An advanced electronic signature (AdES) may be cryptographically strong, but without a QSCD and a qualified certificate, it does not carry statutory handwritten-signature equivalence.

QES vs. AdES vs. Simple Electronic Signatures

eIDAS structures electronic signatures across three tiers with increasing assurance and legal weight. Where each tier begins and ends is the first architectural decision a lab portal builder must make.

A simple electronic signature (SES) is, at its broadest, any data in electronic form attached to or associated with other data and used to sign. A name typed at the bottom of an email qualifies. There is no authentication requirement, no identity proofing, and no cryptographic binding.

An advanced electronic signature (AdES) must meet all four requirements under Article 26: unique linkage to the signatory; capability of identifying the signatory; creation using data under the signatory's sole control; and detection of any subsequent change to the signed data. A standard PKI certificate from a non-qualified issuer can satisfy these. AdES does not require a QSCD, and it does not carry handwritten-signature equivalence.

QES adds the QSCD and qualified certificate requirements on top of all four Article 26 conditions. The QSCD guarantees sole control of the private key in a tamper-resistant environment. The qualified certificate confirms that a supervised QTSP proofed the signatory's identity to the required standard.

Feature	Simple (SES)	Advanced (AdES)	Qualified (QES)
eIDAS article basis	-	Article 26	Article 3(12), Article 25
Identity verification	None required	Required	Strict identity proofing by QTSP
QSCD required	No	No	Yes
Qualified certificate	No	No	Yes (from a QTSP on EU Trusted List)
Legal equivalence to handwritten signature	No	No	Yes (Article 25(2))
Cross-border EU recognition	Not guaranteed	Limited	Mandatory
Typical lab use	Internal routing	Non-accredited reports	Accredited test certificates, calibration records

When AdES Is Sufficient and When QES Is Mandatory

AdES is appropriate for internal workflow documents, draft reports circulating within the laboratory, and non-accredited outputs where no regulatory instrument specifies a higher assurance level.

QES is required - or its closest equivalent - when the document leaves the lab for an external client, when cross-border recognition under EU law is needed, or when an accreditation body, directive, or regulation specifies handwritten-signature equivalence. For ISO/IEC 17025-accredited test certificates issued to clients, the practical expectation across most EU member states is QES or a qualified electronic seal issued by the legal entity.

The Legal and Standards Framework Behind QES

eIDAS Regulation (EU) No 910/2014 - The Articles That Matter

Three articles form the compliance skeleton for any lab portal implementing QES:

Article 3 - Definitions. QES, AdES, SES, QSCD, QTSP, and qualified certificate are each formally defined here. When an accreditation body or notified body asks which type of signature applies, the answer must trace back to these definitions.
Article 25 - Legal effects of electronic signatures. Paragraph 2 grants QES its handwritten-signature equivalence. Paragraph 1 prohibits denying legal effect to any electronic signature solely because it is electronic - though SES and AdES still lack the Article 25(2) equivalence guarantee.
Article 26 - Requirements for advanced electronic signatures. These four requirements are the floor that QES also satisfies and that AdES alone must meet.

A note on eIDAS 2.0: The revised regulation - formally Regulation (EU) 2024/1183, amending eIDAS - entered into force in 2024. It introduces the European Digital Identity Wallet (EUDI Wallet), new obligations for QTSPs, and expanded qualified certificate provisions. As of 2026, member state implementation timelines for the EUDI Wallet and associated QTSP obligations are still being finalised. Labs planning new portal builds should verify current status against EUR-Lex and their national supervisory body, as eIDAS 2.0 provisions are actively being phased in.

ETSI Format Standards: Choosing the Right Signature Container

Choosing the correct ETSI format standard is not optional - it determines whether your signed certificate can be validated by third parties and accreditation tools. Three formats apply in lab contexts:

XAdES (XML Advanced Electronic Signatures) - governed by ETSI EN 319 132. XAdES wraps or envelops a signature within an XML document structure, making it the natural fit for lab portals that issue structured XML test certificates. It supports long-term validation profiles (XAdES-LTA) that embed the timestamp and revocation data needed for records that must remain verifiable for years.
CAdES (CMS Advanced Electronic Signatures) - governed by ETSI EN 319 122. CAdES operates on binary data using Cryptographic Message Syntax. It applies where the signed payload is not XML or PDF - for example, a signed data package containing raw measurement results.
PAdES (PDF Advanced Electronic Signatures) - for PDF-based calibration reports and human-readable certificates. PAdES embeds the signature within the PDF structure, producing a self-contained signed document that most recipients can validate with standard PDF tools.

The selection rule for lab documents:

XML test certificate → XAdES (ETSI EN 319 132)
PDF calibration report → PAdES
Binary or CMS payload → CAdES (ETSI EN 319 122)

When Regulated Labs Must Use a QES on Test Certificates and Reports

ISO/IEC 17025 and ISO 15189 Signature Requirements

ISO/IEC 17025:2017, the international standard for testing and calibration laboratories, requires that reports and certificates be authorised. Clause 7.8 addresses the content and controlled release of test reports and calibration certificates; clause 8.2 covers management system requirements that ensure document integrity. The standard does not name "qualified electronic signature" explicitly, but it requires that the laboratory control the authenticity and integrity of all issued reports.

In practice, when EU-based accreditation bodies assess how digital signatures satisfy those requirements, they look for an assurance level proportionate to the document's legal and regulatory weight. For externally issued accredited certificates, that means QES or a qualified electronic seal.

ISO 15189:2022 - the equivalent standard for medical laboratories - and the In Vitro Diagnostic Regulation (IVDR) impose additional traceability requirements on diagnostic result reports. For laboratories issuing IVDR-relevant outputs digitally, the qualified signature tier is the expected minimum where the document carries regulatory evidentiary value.

Scenarios: QES vs. AdES in Lab Workflows

The decision comes down to three questions: Does the document go to an external client? Does it need cross-border recognition? Does it serve as legal evidence of conformity?

Scenario	Required signature tier
Accredited test certificate issued to an external client (EU)	QES or qualified electronic seal
Calibration certificate with legal evidentiary value	QES or qualified electronic seal
Cross-border certificate recognition required	QES (mandatory for Article 25(2) equivalence)
Internal draft or routing document	SES or AdES acceptable
Non-accredited commercial report	AdES typically sufficient

If the answer to all three questions is "no," AdES may suffice. If any answer is "yes," plan for QES or a qualified seal.

Seal vs. Personal Signature in a Lab Portal

This distinction causes more compliance and operational problems in lab portal design than almost any other eIDAS question. Getting it wrong has consequences on both fronts.

A personal qualified electronic signature is issued to a named natural person - an individual scientist or laboratory director - following strict identity proofing by a QTSP. It binds the signature to that specific individual.

A qualified electronic seal is issued to a legal entity - the laboratory as an organisation. Under eIDAS Article 35, a qualified electronic seal guarantees the origin and integrity of the document but does not assert any natural person's identity. For a lab portal issuing hundreds of test certificates per day on behalf of the accredited laboratory, the qualified electronic seal is the correct instrument. It supports automated, batch signing without requiring a named individual to authenticate for every document.

Personal QES is appropriate when a specific signatory - a lab director countersigning a report - must be individually identified on the document. Using a personal QES certificate in a batch portal issuance pipeline is a common and serious architectural error. More on that below.

Qualified Trust Service Providers: The Required Chain of Trust

What Makes a QTSP Qualified

A QTSP is a trust service provider that has received qualified status from its national supervisory body under eIDAS. Appearing on a member state's supervisory body list is not sufficient - the provider must appear on that member state's official EU Trusted List with the specific service type "QC" (qualified certificate issuance) active. The EU Trusted List Browser maintained by the European Commission is the authoritative, publicly searchable registry. As of 2026, the Trusted List includes QTSPs across all EU member states plus a number of EEA and associated states - verify the current count and status directly via the browser, as the list updates continuously.

The constitutive effect of the EU Trusted List means a qualified certificate holds the legal status "qualified" only because the issuing QTSP appears on that list - not because the certificate itself claims to be qualified. A certificate from a provider not on the list cannot produce a QES, regardless of its technical characteristics.

QTSPs operating at qualified level must maintain a certificate revocation service (CRL or OCSP), provide trusted timestamping, ensure trained personnel handle issuance and revocation, and use hardware that meets QSCD security requirements.

How to Select a QTSP for a Lab Portal

Here is what selection criteria look like in a lab context:

Jurisdiction: The QTSP must appear on the EU Trusted List for the member state under whose law the lab operates, or a member state whose Trusted List entries receive mutual recognition.
Service type: Confirm the QTSP's Trusted List entry explicitly covers qualified certificate issuance for electronic signatures or electronic seals - not only timestamping or other trust services.
Remote vs. local signing: Most modern lab portals use remote QSCDs operated by the QTSP rather than local hardware tokens. Confirm the QTSP offers a remote signing API compatible with your portal stack.
API and integration support: Lab portals require programmatic access. Evaluate the QTSP's signing API, SDK availability, and support for the European Commission's DSS library for signature creation and validation.
Sector experience: Some QTSPs have established integrations with laboratory information management systems (LIMS). That experience reduces integration risk.

For deeper guidance on matching QTSPs to specific lab portal architectures, see our coverage of EU trust service providers for labs.

Technical Components of a QES Implementation in a Lab Portal

The QSCD: What It Is and Why It Exists

A QSCD is the hardware or software environment in which the private signing key is generated and used - and from which it cannot be extracted in the clear. The QSCD requirement exists to guarantee the "sole control" condition in Article 26(d): only the rightful signatory can initiate a signature, and the key material cannot be copied or transferred.

Three QSCD form factors apply to lab portals:

Hardware Security Module (HSM): A physical device - usually a rack-mounted server component - that generates and stores private keys in tamper-resistant hardware. HSMs certified to Common Criteria EAL 4+ or FIPS 140-2 Level 3 are typical QSCD implementations.
Smart card or USB token: A personal device carried by an individual signatory. Appropriate for personal QES scenarios involving a named signatory; not suitable for batch portal issuance.
Remote QSCD (server-side signing): The QSCD is operated by the QTSP on behalf of the subscriber. The lab portal calls the QTSP's signing API; the key never leaves the QTSP's HSM. This is the practical choice for automated, high-volume certificate issuance in lab portals - and a remote QSCD fully satisfies the eIDAS QSCD requirement, provided the QTSP has qualified status and the remote signing service appears on the Trusted List.

Long-Term Validation for Accreditation Records

Long-term validation (LTV) is the mechanism by which a QES-signed document remains verifiable years after its signing certificate has expired or been revoked. Without LTV, a test certificate signed today becomes unverifiable once the signing certificate expires - typically within one to three years. For accredited laboratories whose records must be retained and produced on demand for years or decades, that is an unacceptable outcome.

LTV works by embedding, within the signed document at the time of signing or shortly after, all materials needed for future validation:

A timestamp token from a qualified timestamp authority, proving the signature existed before a specific point in time.
OCSP responses or CRL snapshots proving the signing certificate was valid at the moment of signing.
The full certificate chain up to the trust anchor, so future validators do not need to retrieve it from a potentially unavailable server.

ETSI EN 319 132 defines the XAdES-LTA (Long-Term Archival) profile, which packages these elements within the signed XML structure. Equivalent LTA profiles exist for PAdES and CAdES. The European Commission's open-source DSS library implements these profiles and is a practical starting point for portal developers.

One operational point worth stating plainly: LTV embedding must happen at signing time or within the window before the signing certificate's revocation information becomes unavailable. Retrofitting LTV to historical certificates after expiry is technically complex and sometimes impossible. Build LTV into the signing pipeline from day one.

Integration Architecture for a Lab Certificate Portal

The end-to-end flow in a QES-enabled lab portal runs as follows: the laboratory's LIMS generates the test result data and triggers certificate creation in the eIDAS certificate portal. The portal assembles the certificate document (XML or PDF), calls the QTSP's remote signing API to apply the QES or qualified seal using the remote QSCD, receives the signed document, immediately embeds LTV materials (timestamp token plus OCSP response), and delivers the fully signed and LTV-equipped certificate to the client.

For a detailed breakdown of how each layer connects, see our certificate portal architecture guide.

This video from ZealiD explains the practical context for choosing between advanced and qualified signatures in EU workflows:

https://www.youtube.com/watch?v=dIorwcwHTHk

Common QES Implementation Mistakes in Regulated Lab Portals

From Sandorian's experience building eIDAS-sealed certificate portals for European regulated laboratories, the same errors appear repeatedly. These are the ones that generate the most compliance and operational risk:

Using AdES where QES is required. Labs sometimes implement a strong AdES and assume it satisfies accreditation requirements. If the accreditation body expects handwritten-signature equivalence for issued certificates, only QES delivers that under EU law.
Confusing a qualified electronic seal with a personal QES. A lab portal issuing certificates automatically on behalf of the legal entity must use a qualified electronic seal (issued to the organisation), not a personal QES (issued to a named individual). Using a personal certificate in a batch pipeline exposes the individual as the sole signatory of all certificates - a legal and operational problem.
Selecting a QTSP not on the EU Trusted List, or one listed for the wrong service type. A QTSP may appear on the Trusted List for timestamping but not for qualified certificate issuance. Verify the specific service type entry in the EU Trusted List Browser before contracting.
Choosing the wrong ETSI format for the document type. Applying CAdES to a structured XML test certificate instead of XAdES, or embedding a PAdES signature in a non-PDF document, produces a signature that conformance checkers and downstream validators reject.
Omitting LTV embedding. Certificates signed without LTV materials are legally valid at issuance but become unverifiable once the signing certificate expires. Accreditation auditors who request historical certificates three years later will find documents they cannot verify.
Failing to renew LTV timestamps before the signing certificate expires. The timestamp token itself has a validity period. If re-timestamping does not occur before the previous timestamp's certificate expires, the chain of verifiability breaks. Implement automated renewal monitoring.

One of the most frequent errors we see in lab portal builds is confusing an organisational electronic seal - which the portal issues automatically on behalf of the lab as a legal entity - with a personal qualified electronic signature. They are different eIDAS instruments with different certificate types and different QTSP issuance processes. Mixing them up creates documents that are either attributable to the wrong legal subject or invalid for batch issuance contexts.

Frequently Asked Questions

What is a qualified electronic signature under eIDAS?

A qualified electronic signature (QES) is an advanced electronic signature created with a QSCD and backed by a qualified certificate issued by a QTSP on the EU Trusted List. Under Article 25(2) of eIDAS Regulation (EU) No 910/2014, it carries the same legal effect as a handwritten signature and receives recognition across all EU member states without additional formality.

How does a QES differ from an advanced electronic signature?

An advanced electronic signature (AdES) meets the four Article 26 requirements - unique linkage, signatory identification, sole control of signing data, and change detection - but does not require a QSCD or a qualified certificate from a supervised QTSP. QES adds both requirements on top of Article 26. The practical difference is legal weight: AdES does not carry handwritten-signature equivalence; QES does.

Does an ISO/IEC 17025-accredited lab need a QES on its test certificates?

ISO/IEC 17025:2017 does not name QES explicitly, but it requires controlled, authenticated release of test reports. When EU accreditation bodies assess digital signatures against that requirement for externally issued accredited certificates, they expect an assurance level equivalent to QES or a qualified electronic seal issued by the laboratory as a legal entity. For cross-border certificates or those with regulatory evidentiary value, QES is the defensible choice.

What is a QSCD and why is it required for QES?

A QSCD is a tamper-resistant hardware or remote-signing environment that generates and protects private signing keys so they cannot be extracted in the clear. eIDAS Article 3(12) mandates it as one of three definitional components of QES - its purpose is to guarantee sole control of the private key, satisfying Article 26(d). AdES does not require a QSCD because the regulation applies a lower assurance requirement at that tier.

How do I find a qualified trust service provider for my lab?

Use the EU Trusted List Browser maintained by the European Commission. Filter by member state and service type (qualified certificate issuance for electronic signatures or electronic seals). Verify that the QTSP offers a remote signing API suited to portal integration. Consider sector experience, API maturity, and support for the ETSI format standards relevant to your document types (XAdES, PAdES, or CAdES).

What is long-term validation and does it apply to lab certificates?

Long-term validation (LTV) is the process of embedding timestamp tokens, revocation data (OCSP responses or CRL snapshots), and certificate chain materials into a signed document so it remains verifiable after the signing certificate expires. It applies directly to lab certificates: accredited laboratories must retain and produce records on demand for years. Without LTV, a QES-signed certificate becomes unverifiable once the signing certificate's validity period ends - typically within one to three years of issuance. ETSI EN 319 132 defines the XAdES-LTA profile that implements LTV for XML-based certificates.

What changes under eIDAS 2.0 for QES?

Regulation (EU) 2024/1183 - commonly called eIDAS 2.0 - introduces the European Digital Identity Wallet (EUDI Wallet), expands the scope of qualified trust services, and adds new obligations for QTSPs around wallet-based credential issuance. For QES specifically, the core legal framework (Articles 3, 25, and 26) remains, but QTSP supervisory requirements and the scope of qualified certificates are broadened. As of 2026, member state implementation timelines remain in progress. Laboratories planning QES implementations should check current QTSP obligations against EUR-Lex and their national supervisory body before finalising architecture decisions - eIDAS 2.0 provisions are being phased in actively and the details remain subject to change.

Qualified Electronic Signatures Under eIDAS: Lab Use Cases