Zum Hauptinhalt springen
Alle Artikel
DPP
Technical
W3C VC
Cryptographic Signing

Death of the Static PDF: Why DPPs Cannot Be Documents

Many brands are treating their Digital Product Passport as a sophisticated PDF. This approach is not just incomplete — it is fundamentally incompatible with how DPP verification actually works.

6 min read

A significant fraction of the "DPP solutions" being marketed to brands in 2025 are, at their core, PDF generators with a QR code on top. The QR code links to a hosted PDF. The PDF contains the product data. Someone, somewhere, reads the PDF and decides whether the product is compliant.

This approach fails at every layer of the ESPR technical specification. Here is why, and what a DPP actually needs to be.

The PDF Cannot Be Verified

ESPR requires that DPP data be cryptographically verifiable. Specifically, the data must carry a verifiable credential (W3C Verifiable Credentials 2.0) signed by the economic operator using a key registered under their legal entity identity. A customs officer or market surveillance authority must be able to verify that:

  1. The data was issued by the organisation claiming to issue it
  2. The data has not been modified since issuance
  3. The issuing organisation is the legitimate economic operator for this product

A PDF cannot carry a W3C VC. A PDF cannot be verified by an automated system. A PDF requires a human to read it, which does not scale to the volume of products crossing EU borders.

The PDF Cannot Be Queried

EU customs pre-filing systems, market surveillance tools, and retail compliance platforms all query DPP data programmatically. They call a REST endpoint, receive JSON, and check specific fields against required values. A PDF has no queryable API. It cannot be integrated into import declaration systems. It cannot be cross-referenced with the EU Common Information Repository.

The ESPR technical specification requires that the DPP endpoint return machine-readable JSON. The GS1 Digital Link standard specifies how the URL should be structured. The CIRPASS-2 interoperability format specifies what the JSON must contain. None of these requirements can be satisfied by a PDF.

The PDF Is Static — DPPs Must Be Dynamic

A DPP is not a point-in-time document. It is a living record. Under ESPR, the DPP must be updated when:

  • The product is repaired or remanufactured (status changes to remanufactured)
  • The product is destroyed (status changes to destroyed)
  • The product model is discontinued (triggers 10-year retention clock)
  • Recycled content percentages change due to supply chain adjustments
  • A conformity certificate is renewed or revoked

None of these updates can be reflected in a static PDF without reissuing the entire document and invalidating all the existing QR codes in the field. A DPP must be a live data record with a stable URL that always returns current data — not a document frozen at issuance time.

What a Compliant DPP Actually Needs

A compliant DPP requires:

A stable, resolvable URL — the GS1 Digital Link format /01/{gtin}/21/{serial} is the preferred form. The URL must resolve for the lifetime of the product plus 10 years after discontinuation.

Machine-readable JSON at that URL — conforming to the ESPR delegated act schema for the product category. For batteries, this means Annex XIII fields. For textiles, the relevant delegated act fields.

A W3C Verifiable Credential — signed by the economic operator's DID (Decentralised Identifier), using Ed25519 or similar algorithm. The credential must be verifiable against the issuer's published DID document.

EU CIR registration — the product's unique identifier must be registered in the EU Common Information Repository so discovery tools can find the authoritative data endpoint.

Selective Disclosure capability — some fields in the DPP are public (basic product data), others are restricted (B2B supply chain data visible only to authorised parties). SD-JWT format allows field-level access control without invalidating the credential.

The Time to Switch Is Before Enforcement

If your current DPP solution produces PDFs, the time to replace it is before the 2027 battery DPP deadline, not after. Migration from a PDF-based approach requires:

  1. Re-creating all DPP records in a compliant JSON format
  2. Re-issuing cryptographic credentials for all products
  3. Re-registering all products with the EU CIR
  4. Re-distributing QR codes that resolve to the new endpoints (or setting up redirect infrastructure from old QR codes)

This is significant operational work. It is much less significant if done proactively than if triggered by a customs rejection at the border.


PassportLab generates cryptographically signed, W3C VC 2.0 compliant DPPs with GS1 Digital Link resolution and EU CIR registration. See the technical details or generate a compliant DPP now.

Ready to generate a compliant DPP?
Create your first Digital Product Passport in under 10 minutes — no technical team required.