The Digital Product Passport (DPP) is a machine-readable, per-device record required under the EU’s Ecodesign for Sustainable Products Regulation (ESPR). For an embedded team, it reduces to four engineering deliverables: a unique identity per device, a data carrier on the device, a backend record that outlives the product line, and a manufacturing step that wires the three together.

Most of what is written about the Digital Product Passport is written for compliance officers: what the ESPR requires, when delegated acts land, what fines apply. Almost none of it answers the question an embedded team actually has: what has to be built?

Here is that answer. Teams that already did the CRA and ESPR architecture work own most of the pieces. The DPP is where they get assembled.

What Identifier Does a DPP Need?

Every unit needs a globally unique, registry-resolvable identifier, assigned at manufacturing. The DPP attaches to the individual item (or batch, depending on the delegated act), which means serialisation is the entry requirement.

The practical choice for most products is a GS1 Digital Link — a URI that encodes the GTIN plus serial number and resolves over standard web infrastructure. This is the direction the EU’s DPP standardisation work has been converging toward: the CEN/CENELEC JTC 24 committee is developing the standards framework, building on the CIRPASS project pilots. For products that already carry GS1 barcodes for retail, this is an extension of numbering the organisation already manages.

The identifier must be assigned and recorded at the moment of provisioning. The manufacturing station that injects device keys and initial firmware is the right place, because it is the one step every unit already passes through under test control.

One decision to make deliberately: whether the DPP identity and the device’s cryptographic identity (the certificate provisioned for CRA-grade OTA) are linked or independent. Linking them lets the device attest its own passport data later. Firmware version history in particular is the difference between a DPP that is manually maintained and one that updates itself.

QR Code, NFC, or RFID: Choosing the Data Carrier

The regulation requires the identifier to be physically accessible on the product, its packaging, or its documentation — machine-readable, throughout the product’s life. Three realistic options:

The engineering trap is treating this as a packaging decision. The carrier must survive the use environment for the declared lifetime, because the recycler at end of life is a primary intended reader. A label on an industrial device that lives outdoors for ten years needs to be specified like a component, not an afterthought. Specify the carrier at EVT, test it like any other component.

What Data Does the DPP Record Hold?

The passport itself is a structured, machine-readable record the identifier resolves to. The delegated acts will fix the exact schema per product category, but the embedded-relevant payload is already clear from the regulation’s text and the pilot work:

• Product and manufacturer identification
• Material composition, including critical raw materials
• Repairability information and spare-part availability
• Recycled content
• Dismantling information
• For connected products: software composition and update history

Architecturally, three properties matter more than the schema:

1. Longevity beyond the product line. The record must be servable for the product’s lifetime plus its afterlife. Build it as a boring, exportable data store behind a resolver — not as a feature inside this year’s cloud application, which will be rewritten twice before the product dies.

2. Per-unit lifecycle events, not just birth data. Firmware updates, repairs, battery replacement. This is where the DPP stops being a static certificate and becomes a living record — and where existing fleet telemetry, if it was built audit-grade for the CRA, already produces the events.

3. Tiered access. Consumers, repairers, recyclers, and market-surveillance authorities are entitled to different slices. Design the record with access tiers from the start rather than bolting a permissions layer onto a flat document later.

The SBOM the CI pipeline already generates per release is the software-composition feed. The BOM-level material declarations are the harder data problem: a supplier conversation measured in months, which is why it starts now and not when the delegated act publishes.

How the Manufacturing Line Ties It Together

At end-of-line, one station assigns the serial, provisions the device identity, applies or verifies the data carrier, and writes the birth record (hardware revision, firmware version, test results reference, BOM revision) to the passport backend. One station, one transaction, every unit.

Retrofit is the expensive version of this; designing it into the PVT line is the cheap one.

The Implementation Sequence That Works

For a product currently in development:

1. EVT: assign the identifier scheme and select the data carrier
2. DVT: stand up the resolver and record store
3. PVT: integrate the provisioning station into the line
4. From day one, in parallel: start the supplier material-declaration requests — they are the long pole

None of the steps is individually difficult. The failure mode is treating the DPP as a 2027 documentation task and discovering that serialisation, carrier durability, and supplier data were all architecture decisions that needed to happen at EVT.

Building the DPP into a current programme?

DPP readiness is scoped as part of the same architecture assessment that covers CRA and ESPR — identifier scheme, carrier selection, backend design, and the provisioning-line integration. Talk to an Embedded Architect →

Frequently Asked Questions