DPP × eSignature: How Qualified Signatures Power Product Passport Compliance

The signature layer most DPP guides skip

Every Digital Product Passport depends on qualified electronic signatures at two critical points: proving who registered it (QSeal on the operator enrolment PDF) and proving the passport data itself is authentic (XAdES-LTA on each DPP data file). Yet across the top 10 Google results for 'Digital Product Passport', zero mention electronic signatures. This guide fills that gap — covering the regulatory requirements, the technical signing stack, batch architecture for manufacturers issuing thousands of passports per day, and practical QTSP selection criteria.

Signature types required

Art. 35 + 41

eIDAS legal presumption

10 years

DPP data retention

Mandatory

LTA archive timestamp

The two-signature stack

DPP compliance isn't a single signature — it's two distinct qualified trust services, each serving a different regulatory function. Both must come from a QTSP accredited on the EU Trusted List.

A Qualified Electronic Seal applied to the operator registration PDF during the 7-step Verified Economic Operator enrolment. Proves the organisation's legal identity to the European Commission. Only needed once per operator — not per product.

A qualified XML Advanced Electronic Signature with Long-Term Archive timestamps, applied to each DPP data file. Ensures the passport remains verifiable for the full 10-year ESPR retention period — even after the original signing certificate expires. Required for every product passport at issuance.

Embedded inside LTA-level signatures. Provides a trusted time reference from a Time Stamping Authority (TSA), proving the signature existed at a specific moment. Required for long-term validation after certificate expiry.

The underlying cryptographic operation for batch signing. Only the hash of the DPP content leaves the manufacturer's server — the private key never moves. This is how manufacturers sign 100+ passports per API call without exposing keys.

QSeal in detail: The operator registration flow

Before any product can be registered in the EU DPP Registry, the manufacturer must complete the 7-step Verified Economic Operator (VEO) enrolment. Step 4 is where the QSeal enters.

Step 1–3: Identity establishment

The operator creates an account in the EU DPP Registry, submits organisation details (legal name, address, national identifier with country code prefix like 'CN' for Chinese companies), and undergoes initial identity verification.

Step 4: The critical QSeal step

The operator downloads a PDF declaration from the Registry. This PDF already carries the European Commission's institutional seal. The operator must apply a Qualified Electronic Seal (QSeal) from a QTSP on the EU Trusted List. The result: exactly two signatures on one document. The QSeal certificate's subject name must match the operator's registered organisation name character-for-character. Any mismatch — a missing 'Co., Ltd.', a different transliteration, a truncated name — causes automatic rejection.

Step 5–7: Validation and activation

The Registry validates the dually-signed PDF, cross-checks the QSeal certificate against the EU Trusted List, and activates the operator account. After activation, the operator can register product passports — but each passport still needs its own XAdES-LTA signature.

XAdES-LTA in detail: Content signing at production scale

Every individual product passport must be signed with a qualified signature. For a battery manufacturer producing 10,000 units per day, this means 10,000 qualified signatures per day — roughly 7 per minute. Manual signing is impossible. This is where XAdES-LTA batch signing comes in.

Why LTA and not just XAdES-BES?

XAdES-BES (Basic Electronic Signature) is valid at signing time but becomes unverifiable when the signing certificate expires (typically 2–5 years). ESPR requires DPP data to remain verifiable for up to 10 years. XAdES-LTA (Long-Term Archive) solves this by embedding archive timestamps from a TSA at regular intervals. Even after the original certificate expires, the archive timestamps prove the signature was valid at signing time, maintaining legal verifiability. LTA signatures carry automatic legal presumption under eIDAS Articles 35 and 41 across all 27 EU member states.

Batch signing architecture

The manufacturer's signing system generates XAdES-LTA signatures via API. A typical batch call: (1) The system prepares 100 DPP data files as XML, (2) computes SHA-256 hashes for each, (3) sends the hash array to the signing API, (4) the signing service (holding the HSM-protected private key) signs each hash and returns the signature objects, (5) the manufacturer assembles the final XAdES-LTA signatures locally. Throughput: 1,000+ operations per minute. The private key never leaves the QTSP's HSM.

JAdES-LTA: The JSON alternative

JAdES-LTA (JSON Advanced Electronic Signature with Long-Term Archive) is the JSON equivalent of XAdES-LTA, designed for REST API-native architectures. For manufacturers building DPP signing into microservices or serverless functions, JAdES-LTA offers the same eIDAS compliance with lighter-weight payloads. Both formats are acceptable under ESPR implementing rules.

Selecting a QTSP: 5 non-obvious criteria

Any QTSP on the EU Trusted List can issue QSeal certificates. But in practice, the choice matters for four reasons that won't appear in the official listing.

1. HSM jurisdiction and data residency

The QTSP's Hardware Security Module stores the private key. If the HSM is in a non-EU jurisdiction, some EU customs auditors may question the chain of trust. ANF AC (Spain), InfoCert (Italy), and D-TRUST (Germany) keep HSMs in EU data centres. For non-EU operators, check whether the QTSP's Registration Authority in your region uses a local intermediate HSM or tunnels to the EU.

2. API throughput and rate limits

DPP batch signing requires sustained throughput — 1,000+ signatures per minute for large battery manufacturers. Some QTSPs cap API calls at 50/minute on standard tiers. Verify the signing API supports: (a) batch hash submission (50–100 hashes per request), (b) concurrent connections for parallel processing, (c) throughput SLAs in writing, not just burst limits.

3. Certificate lifecycle management

Signing certificates expire. When a certificate is renewed, previously-signed DPPs remain valid (thanks to LTA timestamps) but new DPPs must use the new certificate. The QTSP should provide: (a) automated renewal notifications 60–90 days before expiry, (b) a rollover API to update signing configurations without downtime, (c) OCSP/CRL endpoints with high availability for verification.

4. Registration Authority availability in your region

Non-EU manufacturers need identity verification before QSeal issuance. If the QTSP has a Registration Authority in your country (e.g., eSign.AI for ANF AC in Asia-Pacific), the identity verification and certificate issuance take days, not weeks. Without a local RA, you'll need to ship physical documents or conduct video verification with EU-based notaries.

5. Audit trail and compliance evidence

During a customs audit, you'll need to prove every DPP was signed with a valid qualified signature at issuance time. The QTSP should provide: (a) signed audit logs for every API call, (b) TSA timestamp receipts, (c) Trust Service Status (TSL) snapshots at the signing date, (d) a compliance portal or API to retrieve historical evidence.

Pre-deployment checklist

Before going live with DPP signing, verify each of these items. Missing any one can block product registration or fail a customs audit.

Valid QSeal from an EU Trusted List QTSP, with subject name matching your registered organisation name exactly.

XAdES-LTA or JAdES-LTA batch signing API connected, tested with 100+ signatures, throughput verified.

Qualified timestamping service accessible and embedded in LTA signature assembly.

Confirmed that only SHA-256 hashes leave your server — no DPP content or private keys transmitted.

Operator enrolment tested in the EU DPP Registry sandbox environment (registry.product-passport.ec.europa.eu).

Renewal notification → new certificate → signing config update → resume signing, with zero downtime.

Frequently asked questions

No. ESPR implementing rules require qualified electronic signatures as defined by eIDAS. Standard digital certificates (even from reputable CAs) do not provide the automatic legal presumption of Articles 35 and 41. Only qualified trust services from QTSPs on the EU Trusted List meet the requirement.

How eSign.AI implements the full DPP signature stack

eSign.AI operates as the Registration Authority for ANF AC (Spain), a QTSP on the EU Trusted List, with infrastructure optimised for high-volume DPP signing. The implementation covers: QSeal certificate issuance for operator registration (identity verification completed in 3–5 business days for Asia-Pacific operators), XAdES-LTA and JAdES-LTA batch signing APIs (up to 100 DPPs per call, throughput exceeding 1,000 operations per minute, SDKs available in Python, Java, and Go), qualified timestamping embedded in every LTA signature, PKCS#1 batch signing where only hash values leave the customer's server, and a compliance portal providing signed audit logs, TSA receipts, and TSL snapshots for customs audits. The battery DPP module activation window — between now and the February 2027 mandatory deadline — is the optimal time for API integration, sandbox testing, and throughput validation.

Team discussing the right eSignature approach for a business

Explore the right eSignature approach for your business

Talk to our team about eSignature requirements, compliance considerations, and document workflows across your target markets.

Keep reading

Industry Insights