eIDAS QES Validation

Article 32 of Regulation (EU) No 910/2014 sets the validation requirements for qualified electronic signatures. A relying party should treat the output as a technical conclusion about the Article 32 conditions. Whether to accept the transaction can still depend on authority, intent, contract rules, required form, and other case-specific law.

The check should be anchored at the time of signing. A certificate can be revoked later, but QES validation still needs evidence about whether the certificate was qualified, issued by a QTSP, and valid at the relevant signing time.

Keep the signature classes separate. An electronic signature cannot be denied legal effect solely because it is electronic or is not qualified. An advanced electronic signature must meet Article 26, but it is a QES only when it also uses a qualified certificate and a qualified electronic signature creation device. An advanced signature based on a qualified certificate is therefore not automatically a QES.

The trusted-list check is the control that prevents a relying party from accepting a certificate as qualified only because a vendor label says it is. ETSI explains that EU Member State trusted lists include qualified trust service providers and their qualified trust services, and that the Commission publishes a central List Of Trusted Lists for access to Member State lists.

For QES validation, retain the trusted-list status used by the validator: the Member State list or LOTL source, the service type, the service status and history, the qualified certificate status, and the time at which the trust-list evidence was evaluated.

Certificate validation should capture both current cryptographic checks and signing-time context. eIDAS requires the certificate to have been qualified, QTSP-issued, and valid at signing time; the certificate also needs usable validity or revocation status information.

A validator may report a certificate as currently revoked yet still reach a valid signature conclusion when reliable proof of existence shows that the signature existed before revocation. This is validation-policy and evidence dependent. The report must expose the time evidence, revocation facts, and trusted-list history instead of treating later revocation as automatically harmless.

DSS is useful source support for implementation because its reports make the validation decision inspectable. The detailed report separates validation processes from building blocks, so a relying party can see whether a failure came from the signature, a timestamp, revocation data, certificate validation, or trusted-list interpretation.

For QES acceptance, do not retain only a green banner or a PDF viewer screenshot. Retain the diagnostic data, detailed report, validation policy or constraints, trusted-list source, certificate path, revocation responses, timestamp evidence, and the final indication that the signature was qualified.

The retained evidence should let a later reviewer reproduce why the signature was accepted as qualified. It must show that the validation result supports the eIDAS conditions at the relevant time, rather than merely showing that the document contains a signature.

If the business depends on the signature's qualified status, store validation evidence with the transaction record. Do not leave the only copy inside a temporary signing platform. Re-run validation when the signed object, detached contents, trust-list configuration, validation policy, or certificate status evidence changes.