Qualified signatures, explained

Spec: ETSI EN 319 411-2 Spec: ETSI EN 319 411-1 Spec: ETSI EN 319 421 Evidence: Standard-backed

At a glance

“Qualified” is a legal status under the EU eIDAS Regulation, not a property a library can grant. Several parties each do specific work to produce it: a qualified certificate, a qualified signature creation device, a qualified trust service provider, and published trusted lists. This page maps those roles and states plainly the one narrow part NextPDF plays — and the larger parts it does not.

Why this matters

A qualified electronic signature has, in its jurisdiction, the legal effect the law assigns it. That is why “qualified” is attractive. It is also why claiming it loosely is dangerous. Suppose a workflow is described as producing qualified signatures but one role in the chain is missing — the certificate is not qualified, the device is not a QSCD, or the provider is not on a trusted list. Then the signatures are not qualified. That gap usually surfaces at the most consequential moment: a dispute, an audit, a cross-border acceptance check.

The difficulty is that a perfectly valid advanced signature and a qualified one can look identical in a PDF viewer. The difference is in the certificate, the device, the provider, and the trust list — none of which a signing engine supplies. The entire task is knowing exactly which party owns which guarantee.

The short version

Qualified is a chain, not a feature. It requires a qualified certificate, signing on a QSCD, issued under a qualified trust service provider, discoverable through trusted lists. Remove any one and the result is no longer qualified.
A QSCD is mandatory. Under the qualified certificate policies, signatures must be created only by a qualified signature creation device. Spec: ETSI EN 319 411-2, §6.3.5
Sole control sits with the signatory and the device. The private key must be under the signatory’s sole control, held in a device that protects it and signs on the user’s behalf. Spec: ETSI EN 319 411-1, §6.3.5
NextPDF’s part is narrow and honest. It assembles a structurally correct PDF signature and can embed a trusted timestamp and long-term validation material. It is not a QSCD, not a (qualified) trust service provider, and it does not issue certificates, run trusted lists, or confer qualified status.

How NextPDF approaches it

The roles, named

A qualified electronic signature under eIDAS is built from distinct responsibilities. NextPDF occupies exactly one box; the others belong to parties and standards outside the engine.

Step 1 of 5: eIDAS Regulation (EU) 910/2014 defines "qualified" and its legal effect — the legal frame
Step 2 of 5: ETSI EN 319 411-1 / 411-2 qualified certificate policy; QSCD mandatory; sole control
Step 3 of 5: ETSI EN 319 412-5 qualified-certificate profile — the QC statements
Step 4 of 5: ETSI EN 319 421 / RFC 3161 trusted time from a TSP issuing time-stamps
Step 5 of 5: ISO 32000-2 §12.8 the PDF signature carrier NextPDF builds

The chain a qualified electronic signature traverses, in order, and who owns each link: the qualified certificate and the QSCD and the qualified trust service provider and the trusted list are not the signing engine — NextPDF only assembles the PDF signature carrier and can add trusted time and validation material.

The qualified certificate. Issued to the signatory, carrying the QC statements that mark it, in machine-readable form, as a qualified certificate for electronic signature and identifying the qualified trust service provider that issued it. Spec: ETSI EN 319 412-5, §4.2 NextPDF does not issue it.
The QSCD. A qualified signature creation device — in ETSI’s terms a secure cryptographic device that holds the user’s private key, protects it against compromise, and performs the signing on the user’s behalf. Spec: ETSI EN 319 411-1, §3.1 NextPDF is software that signs through such a device; the engine is not itself a QSCD, and its software-key path is not one.
The qualified trust service provider. The QTSP issues the qualified certificate and is itself supervised; the policies require that signatures under these certificates are created only by a QSCD. Spec: ETSI EN 319 411-2, §6.3.5 NextPDF is not a trust service provider.
Trusted lists. The published evidence by which a relying party establishes that the provider and the service were qualified. NextPDF does not operate or vouch for trusted lists.

The narrow part NextPDF plays

Within that chain, NextPDF’s job is bounded and concrete. It assembles the PDF signature: it places the signature field, computes the byte range, and builds the CMS SignedData that the standard requires the Contents entry to hold. Spec: ISO 32000-2, §12.8 When the signing key is on a QSCD, NextPDF signs through it across the same hardware seam described in HSM-backed signing, and the key stays on the device.

NextPDF can also embed the two ingredients that make a signature durable: a trusted timestamp from a time-stamp authority, and the long-term validation material that keeps it verifiable. A timestamp is a Trusted Third Party’s proof that a datum existed before a particular instant Spec: RFC 3161, §1 ; in the EU framework, that authority operates under a policy for trust service providers issuing time-stamps. Spec: ETSI EN 319 421, §1 NextPDF requests and embeds the token. It does not operate the timestamp authority, and embedding a timestamp does not by itself make a signature qualified.

What the evidence says

Evidence: Standard-backed The QSCD requirement is explicit in the qualified certificate policies: the subscriber’s (or the managing TSP’s) obligations require that digital signatures are created only by a QSCD. Spec: ETSI EN 319 411-2, §6.3.5 The device itself is defined as one that holds the user’s private key, protects it against compromise, and performs signing on the user’s behalf Spec: ETSI EN 319 411-1, §3.1 ; for a natural person the private key must be under the signatory’s sole control. Spec: ETSI EN 319 411-1, §6.3.5 A signing library cannot satisfy any of these obligations on the chain’s behalf.

Evidence: Standard-backed What makes a certificate qualified is carried in the certificate’s QC statements, including a machine-readable indication that it was issued as a qualified certificate for electronic signature and data identifying the qualified trust service provider that issued it. Spec: ETSI EN 319 412-5, §4.2 A library that consumes a certificate to build a signature does not make the certificate qualified; the QTSP that issued it does.

Evidence: Standard-backed Trusted time has its own provider role. RFC 3161 defines a Time Stamp Authority as a Trusted Third Party that provides proof-of-existence for a datum at an instant in time Spec: RFC 3161, §1 ; ETSI EN 319 421 specifies the policy and security requirements for trust service providers issuing time-stamps, which can support digital signatures or prove a datum existed before a particular time. Spec: ETSI EN 319 421, §1 NextPDF embeds a token from such a provider; the provider’s qualified status, if any, is the provider’s, not the engine’s.

Practical example

There is no API that “makes a signature qualified”, and a code sample that implied otherwise would be the error. The useful artifact here is a responsibility checklist a reviewer can use:

Link in the chain	Who owns it	NextPDF’s part
Qualified certificate issued	Qualified trust service provider	Consumes it; does not issue it
Signing on a QSCD	The signatory + the device	Signs through it; is not a QSCD
Private key sole control	The signatory + the device	Never holds the key when on a QSCD
Provider/service is qualified	The QTSP + supervision	Asserts nothing about it
Discoverable via trusted lists	Trusted-list operators	Does not operate or check them
PDF signature is well-formed	The signing engine	This is NextPDF’s box
Trusted timestamp embedded	A time-stamp authority	Requests and embeds the token
Long-term validation material	The signing/validation flow	Can embed it (see Related docs)

If any row above the engine’s box is unmet, the result is — at best — a valid advanced signature, not a qualified one. NextPDF can make every row it owns true and still not make the signature qualified, because the status is not the engine’s to confer.

Common misconception

“NextPDF produces qualified signatures.”

It does not, and the precise phrasing matters. NextPDF produces structurally correct PDF signatures and is compatible with signing on a QSCD and embedding qualified-provider timestamps. Whether a given signature is qualified is deployment-dependent: it depends on a qualified certificate, a QSCD, a qualified trust service provider, and trusted-list status — none of which the engine supplies or certifies. The correct claim is “NextPDF assembles the signature; the qualified status comes from the certificate, the device, and the provider.” To say more than that is to overclaim a legal status software cannot grant.

Limits and boundaries

The boundary, stated plainly and without softening:

What NextPDF is. A PDF 2.0 signing engine. It builds the signature per Spec: ISO 32000-2, §12.8 , signs through a device when given one, and can embed a timestamp and long-term validation material.
What NextPDF is not. It is not a QSCD, not a qualified (or any) trust service provider, not a certificate authority, and not a trusted-list operator. It does not assess, confirm, or confer qualified status.
Conformant-to is not certified. It is a structural statement that NextPDF builds signatures conformant to the PDF signature standard and can carry the elements an AdES profile expects. It is not a certification that any resulting signature is qualified, and not a substitute for the QSCD, certificate, provider, and trusted-list conditions that — together — make it so.
Jurisdiction matters. “Qualified” and its legal effect are defined by the eIDAS Regulation in its scope. This page is an engineering explanation, not legal advice. The legal sufficiency of a signature for a specific use is a question for the relevant law and the parties’ counsel, not for a library’s documentation.

Qualified-signature support — edition availability
Edition	Availability
Core	Core builds the PDF signature carrier and the CMS container. It does not contribute to qualified status by itself.
Pro	Pro adds managed-key signing and signature augmentation, described at the behaviour level. It is still not a QSCD or a trust service provider.
Enterprise	Enterprise adds hardware-token signing through PKCS#11, so the signing key can live on a device a deployment operates as a QSCD. The engine signs through the device; the qualified status remains the certificate’s, the device’s, and the provider’s — never the engine’s.

Mini-FAQ

Is an advanced signature the same as a qualified one? No. They can look identical in a viewer. A qualified signature additionally requires a qualified certificate, a QSCD, and a qualified trust service provider; an advanced signature does not. The difference is in the chain, not the PDF bytes.

Does signing on an HSM make a signature qualified? Not on its own. A QSCD is necessary but not sufficient. The certificate must be a qualified certificate from a qualified trust service provider, and the device must meet the QSCD criteria for that deployment. A general HSM is not automatically a QSCD.

Does adding a timestamp make a signature qualified? No. A trusted timestamp strengthens durability and proof of time; it does not supply the certificate, device, or provider conditions that define qualified status. It is necessary for long-term profiles, not sufficient for qualified status.

Can NextPDF tell me if my signature is qualified? No. The engine asserts nothing about qualified status. Establishing it is a matter of the certificate, the device, the provider, trusted lists, and the applicable law — outside the engine’s responsibility.

HSM-backed signing — the device seam a QSCD-based signature uses, and where the key boundary sits.
Timestamps and trusted time — what an RFC 3161 timestamp proves and the provider role behind it.
Long-term validation — the validation material that keeps a signature verifiable over time.

Glossary

Qualified electronic signature — under the eIDAS Regulation, an advanced electronic signature created by a QSCD and based on a qualified certificate; a legal status, not a software feature.
eIDAS — EU Regulation (EU) No 910/2014 on electronic identification and trust services; the legal frame defining “qualified” and its effect.
QSCD (qualified signature creation device) — a device meeting the eIDAS criteria; in ETSI terms a secure cryptographic device holding the user’s key, protecting it, and signing on the user’s behalf.
Qualified certificate — a certificate issued by a qualified trust service provider whose QC statements mark it, machine-readably, as qualified for electronic signature.
QTSP (qualified trust service provider) — a supervised trust service provider issuing qualified certificates and related qualified services.
Trusted list — published evidence by which a relying party establishes that a provider and service were qualified.
Sole control — the obligation that a natural-person signatory’s private key is kept under that signatory’s sole control.
Time Stamp Authority (TSA) — a Trusted Third Party providing proof-of-existence for a datum at an instant in time (RFC 3161).