Publishing a Digital Product Passport is often reduced, wrongly, to “put a QR code on the product.” The code is the last, cheapest step. What actually needs designing is the record behind it: what state it must be in before it can be reached at all, how the printed code survives when the hosting or the data behind it changes, and what happens when a published record needs a correction. This guide covers that publishing workflow, separate from the physical carrier decision covered in the carrier comparison guide .
Start with the record, not the code
A QR code or other data carrier is only ever a pointer. Printing it before the record behind it is defined, governed and complete just moves the problem: the code works, but what it resolves to is unreliable. Design the published record model first, decide what “publishable” means for your product group, and only then choose how it is physically reached.
Five publishing states
| State | What it means | Who can see it |
|---|---|---|
| Draft | Work in progress; incomplete fields and missing evidence are expected | Editors only; not reachable from any published carrier |
| Validated | Structural and format rules pass; required fields and evidence are present | Internal reviewers; still not public |
| Approved | The accountable role has signed off release readiness | Internal, queued for publication |
| Published | Live and reachable through the data carrier | Public, through the resolver |
| Superseded | A prior version, replaced but retained | Internal only, for audit and dispute resolution |
Only the published state should be reachable from a live data carrier. A code that resolves to a draft or unapproved record undermines the entire point of governance.
Use a stable identifier, because the record will move
The physical carrier is permanent once printed; the data behind it will not be. Systems change, hosting providers change, and product data gets corrected. If the carrier encodes a fixed address, every product already in the field breaks when that address changes. A GS1 Digital Link (ISO/IEC 18975) solves this by encoding a stable, resolvable identifier, for example https://id.example.com/01/09506000134352/21/A1B2C3, where the resolver, not the printed code, decides what the identifier currently points to. Changing hosting means updating the resolver, not reprinting anything.
The registry and the backup copy
The ESPR expects the Commission to operate a central registry of registered passports, with a 19 July 2026 deadline set for it to be in place; check the Commission’s ESPR pages for its current operational status before finalising a publishing plan. The ESPR also expects an independent backup copy of the passport to be held by a third party, separate from your own hosting, so the record survives even if your primary system fails. Both of these are publishing infrastructure decisions, not carrier decisions, and should be designed alongside the resolver architecture.
What happens when a published record changes
- Never edit a published record silently. A change should move the current version to superseded and publish a new version, both retained.
- Version the payload, not just the record. Track schema version, record version and payload version separately, so a dispute months later can be traced to exactly what was shown on a given date.
- Use a dual-publish window for major changes. Keep the previous and new payload versions available in parallel briefly when a change could affect systems or people relying on the old one, then deprecate on a defined schedule.
- Log every transition with the actor, timestamp and reason, feeding the same audit trail described in the workflow and roles guide .
Plan multilingual publishing from the start
Because the resolver can route by locale, publishing and localisation should be designed together, not sequentially. See DPP and multilingual product data: what teams miss for how that routing works and what content should and should not be translated.
A publishing checklist
- The published record model and its required fields are defined before any carrier is chosen.
- Only the published state is reachable from a live data carrier.
- The encoded identifier is stable and resolvable, not a fixed address.
- An independent backup copy exists, separate from primary hosting.
- Every publish and correction is logged with actor, timestamp and reason.
- A rollback path exists for an erroneous published record.
Publishing is phase five of a typical six-phase rollout; see the 30-step ESPR compliance roadmap for the full sequence and the DPP Data Carrier Selection Guide for the physical carrier decision.
Frequently asked questions
What workflow states should a published DPP record pass through?
Draft, validated, approved, published, and superseded. Only the published state should be reachable from a live data carrier; earlier states remain internal.
Why should the identifier be resolvable rather than a fixed address?
The physical carrier is permanent once printed, but hosting and data will change over time. A resolvable identifier, such as a GS1 Digital Link, lets you update where it points without reprinting anything already in the field.
What is the EU DPP registry and does it affect publishing?
The ESPR expects the Commission to operate a central registry of registered passports, with a 19 July 2026 deadline for it to be operational. Registration and the passport’s own publishing infrastructure are related but separate; check the Commission’s ESPR pages for the registry’s current status.
Do I need a backup copy of the passport?
Yes. The ESPR expects an independent backup copy held separately from your primary hosting, so the record remains available even if your own systems fail.
What should happen when a published record needs a correction?
Move the current version to superseded and publish a new version, both retained, with the change logged. Avoid editing a published record silently, since that breaks the ability to explain what was shown on a given date.
How does multilingual content affect publishing?
A resolver can route the same physical code to different locale content, so publishing and localization should be designed together rather than as separate projects.
Digital Product Passport data workflow connecting products, materials, suppliers and compliance
