Digital Product Passport architecture

The product-to-information chain

Permissions apply at the service and data layers, rather than relying on a hidden link. This is an illustrative architecture; the applicable regulation and technical specifications determine implementation constraints.

Source systems and the publication boundary

Use an integration layer to validate and normalise records before publication. Do not make the public service depend on unrestricted access to live ERP or engineering databases. Preserve provenance and approval state.

Centralise operations without confusing the registry

You can use a shared platform to operate many passports while source evidence remains distributed. Alternatively, multiple services can publish governed records. The choice depends on scale, ownership, continuity and integration needs—not an assumption that “decentralised” requires blockchain.

The Commission describes the registry as infrastructure for identifiers and associated metadata while product data remains decentralised. A registry is not a replacement for your hosting, access or quality controls. Read the July 2026 launch notice.

Identity and resolution must survive migration

Choose identifier rules before generating labels. Define collision prevention, model-to-batch-to-item relationships and who can retire or replace a reference. Keep a stable access address where your design allows it and make the resolver route independent of a provider-specific front-end URL.

Document redirects, authenticated API routes, failure responses and export formats. Test a migration using an existing carrier: it should still reach the correct record. A successful CSV download does not by itself demonstrate continuity.

Security and interoperability are testable

• Authenticate restricted users and authorise each requested field or operation.
• Separate public content from protected records and control write permissions.
• Maintain audit history for changes, approvals and access-policy updates.
• Document schemas, units, codes and version negotiation for machine users.
• Test exchanges with an independently implemented consumer.
• Test backup restore, provider exit and incident procedures.

CEN-CENELEC’s 2026 publications address system topics such as identifiers, carriers, protocols and persistence. Verify the applicable standard and version, and relevant Official Journal references; do not treat a generic standard claim as proof of product compliance. Standards overview.

Standards that have reached the Official Journal

Decision (EU) 2026/1736 publishes these six references. Conformity supports a presumption of conformity only for the ESPR requirements covered by the standards. It does not establish the product’s mandatory field list or certify an entire vendor platform.

Keep a standards register with reference, version, covered requirement, implementation evidence and test result. Access-rights/security and authentication/integrity are also part of the wider JTC 24 work; verify their current publication and citation status separately.

Make the design review a procurement input

Provide vendors with the identity model, source map, data volumes, access matrix and continuity expectations. Ask them to demonstrate the hardest integration and a portable export with history. Record which responsibilities stay with your team and which are delivered by the provider. Review the software capability guide.