Building an Enterprise Digital Product Passport Architecture

Executive Summary

The preceding articles in this pillar each explain one enterprise capability required to manage trusted product information: master data, the roles of ERP, PIM and PLM, enterprise integration, governance, maturity, quality, stewardship, systems of record, master data management and Golden Records. Individually they are well understood. The difficulty organisations run into is not understanding any one of them, it is assembling them into something that can actually publish a Digital Product Passport and keep it correct for years.

This capstone article sets out The Enterprise Digital Product Passport Reference Architecture, a seven layer logical model running from source systems, through identity and authority, trust and governance, integration and orchestration, the passport service itself, and access and discovery, to the consumers who read the result. It also describes the capabilities that cut across every layer, such as security, privacy, auditability and regulatory change management, and the three distinct information flows the architecture has to carry: master and reference data, lifecycle and event data, and compliance and evidence data.

One principle runs through the whole model. A Digital Product Passport should not become a new enterprise master database. It should consume, validate, assemble and publish trusted information from governed enterprise sources, preserving authoritative source ownership, attribute-level authority, governance, stewardship, traceability, evidence, lifecycle updates and controlled publication. Nothing in European product legislation requires an organisation to physically consolidate all product information into a single system, and programmes that attempt it usually discover they have built a second, unreconciled version of the truth.

The architecture is deliberately logical rather than technical. It says what capabilities are required and how they relate, not which systems, products or deployment patterns should provide them. Federated, centralised and hybrid implementations of the same logical model are all legitimate, and the article explains the trade-offs rather than declaring a winner.

Table of Contents

• Definition
• Why Digital Product Passport Architecture Matters
• The Enterprise Digital Product Passport Reference Architecture
• Architectural Principles
• Layer 1: Source Systems
• Layer 2: Identity and Authority
• Layer 3: Trust and Governance
• Layer 4: Integration and Orchestration
• Layer 5: Digital Product Passport Service
• Layer 6: Access and Discovery
• Layer 7: Consumers
• Cross-Cutting Capabilities
• Master and Reference Data
• Lifecycle and Event Data
• Compliance and Evidence Data
• How Information Moves Through the Architecture
• Where the Digital Product Passport Should Sit
• What the Digital Product Passport Should Not Become
• Architecture Patterns
• Architecture Anti-Patterns
• Practical Enterprise Example
• Implementation Sequence
• Benefits
• Common Mistakes
• Frequently Asked Questions
• Key Takeaways
• Related Articles
• Related Glossary Terms
• References

Definition

Three qualifications matter immediately.

It is an architecture, not an application. The capabilities described here may be delivered by one system, by several existing enterprise systems working together, by external infrastructure, or by a combination. Two organisations can implement the same logical architecture with entirely different technology and both be correct.

It is enterprise architecture, not compliance tooling. A passport draws on the same product information used for planning, sourcing, sales, service and reporting. Treating it as an isolated compliance application detaches it from the governance that makes the underlying information trustworthy, which is precisely the governance a regulator will ask about.

It is not a data consolidation programme. The architecture assumes information stays where it is authoritatively managed and is assembled for publication. Consolidation is a possible tactic in specific places, not the goal.

Why Digital Product Passport Architecture Matters

Most passport programmes fail for architectural reasons rather than regulatory ones. The regulation is knowable; the information is scattered.

Because the obligation is continuous, not one-off. A published passport is a standing representation that must remain accurate as products are revised, suppliers change, certificates expire and units move through repair, resale and recycling. A one-time data extraction cannot satisfy a continuing obligation, and a spreadsheet driven first release almost always becomes the constraint on the second.

Because information originates in many places. As set out in How Enterprise Systems Support Digital Product Passports, specifications, commercial attributes, manufacturing records, supplier declarations and conformity evidence sit in different systems, owned by different functions, on different update cycles. The architecture exists to make that acceptable rather than to eliminate it.

Because publication removes tolerance for internal disagreement. Internally, two systems holding two weights is an irritation. Published to market surveillance authorities, recyclers and consumers, it is a defect with a public audit trail.

Because scope will widen. Requirements arrive product category by product category through delegated acts, as explained in What Are Delegated Acts?. An architecture built around one product family and one set of attributes tends to be rebuilt when the second arrives.

Because evidence must be producible. Regulated claims must be defensible on request. That is an architectural property, expressed through lineage, provenance and audit trails, and it cannot be retrofitted convincingly after publication.

The Enterprise Digital Product Passport Reference Architecture

The reference architecture is a tieback educational model, not an external standard. It describes seven logical layers and the capabilities that span them. Layers are read as responsibility boundaries: each layer depends on the one below it and must not silently assume the duties of another.

This model is the synthesis layer for the pillar. It does not restate the earlier frameworks; it positions them.

The reference architecture adds what none of those frameworks provides on its own: the assembly, publication and access path that turns governed internal information into an externally addressable passport, and the boundaries that keep each capability in its place.

Architectural Principles

Ten principles govern the model. They are stated as constraints because that is how they earn their keep during design reviews.

Layer 1: Source Systems

Layer 1 is where product information is actually created and maintained. Representative sources include product lifecycle management for design, structure and specification, enterprise resource planning for commercial and operational attributes, product information management for customer facing content, manufacturing execution systems for production records, supplier systems for supplier originated declarations, compliance and evidence repositories for certificates and test results, and traceability or event systems for movements and lifecycle events.

The essential architectural statement about this layer is that different systems can remain authoritative for different information domains, permanently. There is no requirement, regulatory or architectural, to make one of them authoritative for everything. ERP vs PIM vs PLM sets out what each system is genuinely good at owning; the reference architecture simply takes that division as given.

Two practical consequences follow. First, source systems are read by the architecture, not rewritten by it: a passport programme that starts editing PLM records to satisfy a publication format has inverted the dependency. Second, sources have very different change characteristics, and Layer 4 must accommodate that rather than assume a common cadence.

Layer 2: Identity and Authority

Layer 2 answers two questions before any information is assembled: which product is this, and which source speaks for each attribute of it.

Product identification establishes a stable, unambiguous identity, as explained in What is a Product Identifier?. Identity may exist at several granularities, typically model, batch and individual item, and the architecture must be explicit about which level a passport addresses.

Attribute-level authority assigns each attribute to a designated source, following TBF-027. This is the single highest value artefact in the whole architecture and the one most often skipped.

Identity resolution reconciles the different internal codes the same product carries across systems. Attribute reconciliation is meaningless until identity is resolved.

Master data management and Golden Records appear in this layer as possible capabilities. They are appropriate when the same entity is described in multiple systems and the description is consumed externally at scale. They are not mandatory architectural components, and an organisation with a single authoritative product source and clean identity may implement the reference architecture without either. See What is Master Data Management? and What is a Golden Record? for when each is justified.

Layer 3: Trust and Governance

Layer 3 determines whether information may be trusted and used. It contains data governance, stewardship, data quality, validation, evidence, lineage and provenance, and access controls.

Governance sets the policies, decision rights and escalation paths, as described in What is Product Data Governance?. Stewardship provides the people who operate them, per What is Product Data Stewardship?. Quality supplies the dimensions against which candidate values are tested, per What is Product Data Quality?: completeness, accuracy, consistency, validity, timeliness and traceability.

Validation is the executable expression of those dimensions, applied to specific attributes with specific rules. Evidence links claims to the documents and test results that support them. Lineage and provenance record where each value came from and how it was transformed.

Access controls belong here rather than only at the publication boundary, because different audiences are entitled to different information. A repairer, a recycler and a market surveillance authority may legitimately see different views of the same product, and the rules governing that should be defined where trust is established, then enforced at Layers 5 and 6.

Layer 4: Integration and Orchestration

Layer 4 moves and coordinates information. It contains APIs, events, integration services, transformation, validation rules, workflow and exception handling, and publication orchestration. Its internal design is the subject of How Enterprise Systems Support Digital Product Passports.

The defining constraint of this layer is that integration is not ownership. The integration layer sees every attribute and is therefore constantly tempted to become the place where values are “fixed”. Once that happens the organisation has an undocumented second system of record, invisible to the governance in Layer 3.

Four capabilities deserve emphasis:

• Transformation converts source representations into the publication model. It must be declarative and inspectable, because a transformation is part of the provenance chain.
• Validation rules execute the Layer 3 policy at the point of movement, so failures are caught before assembly rather than after publication.
• Workflow and exception handling routes what cannot be resolved automatically to a named steward. An architecture with no exception path silently publishes its worst data.
• Publication orchestration decides when a change is released, in what sequence, and with what approval. It is the difference between a controlled release and a live edit.

Layer 5: Digital Product Passport Service

Layer 5 is the logical passport capability. It provides passport assembly, product identity binding, data access rules, version and lifecycle management, publication, resolution and auditability.

The word logical is doing real work. This capability may be delivered by one application, by several services, by existing enterprise capabilities, by external infrastructure, or by a combination. Nothing in the architecture implies a single physical “passport database”, and organisations should resist reading one into the diagram.

• Passport assembly composes the publishable representation from governed inputs according to the applicable requirements for that product category.
• Identity binding ties the representation to a specific product identity at a specific granularity.
• Data access rules determine which audience sees which elements.
• Version and lifecycle management maintains the sequence of published states, so that what was visible at a given moment can be reconstructed.
• Publication is the controlled act of making a version externally available.
• Resolution connects an incoming request for an identifier to the correct published representation.
• Auditability records what was published, when, by whom, from which inputs.

How Does a Digital Product Passport Work? describes the same sequence from the outside in, from the reader’s perspective.

Layer 6: Access and Discovery

Layer 6 connects the physical product to its published information. It contains the product identifier, the data carrier, QR codes and GS1 Digital Link where appropriate, resolver capability and APIs.

The distinction this layer must preserve is fundamental:

QR Codes vs GS1 Digital Link covers the encoding question in detail, and What is GS1? covers the standards body. The architectural point is only that these are four separable concerns, and that a design which fuses them cannot later change its carrier, its identifier scheme or its presentation independently.

Resolver capability translates an incoming identifier into the correct representation for the requesting audience. APIs serve the same content to systems rather than people, and are frequently the channel that matters most for business partners, recyclers and authorities operating at scale.

Layer 7: Consumers

Layer 7 is who the architecture ultimately serves: consumers, business partners, repairers, recyclers, market surveillance authorities, regulators, internal enterprise teams, and other authorised systems.

Consumers are not a uniform audience, and this is an architectural fact rather than a presentation detail. A consumer typically needs comprehensible summary information. A repairer needs part and procedure detail. A recycler needs material and substance information at the point of disassembly. A market surveillance authority needs traceable evidence and the ability to verify claims. Internal teams need to see the same published state that external audiences see, which is more often missing than one might expect.

Because entitlement differs by audience, the access rules defined in Layer 3 and enforced in Layers 5 and 6 are the mechanism that makes a single governed representation serve all of them without publishing everything to everyone.

Cross-Cutting Capabilities

Some capabilities span the entire architecture and should not be forced into a single layer.

Security applies to source access, integration transport, published endpoints and administrative functions alike. Privacy matters wherever product information can be linked to individuals, for example through registration, service history or resale. Governance sets policy at Layer 3 but is exercised everywhere, including over integration changes and publication approvals. Auditability must hold across the whole path, because an audit trail that stops at the integration boundary cannot explain a published value. Monitoring covers data freshness, validation failure rates, resolution availability and access patterns. Lifecycle management applies to products, identities, evidence and published versions simultaneously. Regulatory change management tracks how obligations evolve through delegated acts and product-specific legislation, and turns those changes into requirement updates rather than emergencies.

Master and Reference Data

Master and reference data is the relatively stable description of the product: identifiers, product attributes, manufacturer information, materials and classification. It is the subject of What is Product Master Data?.

Its governance pattern is controlled revision. Values change infrequently, changes are deliberate, and each change should be attributable and approved. In publication terms this flow is usually the easiest to handle and the one organisations model first, which is precisely why the other two flows are so often underestimated.

Reference data, meaning the shared code lists, units, classifications and taxonomies that give attribute values meaning, deserves separate attention. Uncontrolled reference data quietly breaks comparability between products, and comparability is much of the point of a passport.

Lifecycle and Event Data

Lifecycle and event data is created as the product moves: manufactured, shipped, received, serviced, repaired, reused, recycled. Its structure and semantics are the subject of What is EPCIS?, and its movement across organisational boundaries is described in How Product Data Moves Through the Supply Chain.

Its governance pattern is append, not overwrite. An event that happened remains true; later events add to the history rather than replacing it. Three architectural consequences follow:

• Volume is much higher than master data, so publication is usually selective rather than complete.
• Identity granularity matters more, because events attach to items or batches rather than models.
• Much of it originates outside the organisation, so trust depends on the arrangements with the party that reported it.

Event data is also where the temptation to publish everything is strongest and least justified. The architectural question is not what events exist, but which of them a defined audience is entitled to see and needs.

Compliance and Evidence Data

Compliance and evidence data demonstrates regulatory or conformity status: certificates, test evidence, declarations, technical documentation and verification status. Conformity assessment is the process that produces much of it.

Its governance pattern is validity with expiry. Unlike master data, evidence is not simply current or superseded; it is valid until a date, for a defined scope, issued by a defined party. That makes three requirements architectural rather than optional: expiry handling, scope checking, and the ability to suppress a dependent claim when its supporting evidence lapses.

Evidence is also the flow most likely to arrive from suppliers, in inconsistent formats, at inconvenient times. Programmes routinely underestimate the stewardship effort this creates.

How Information Moves Through the Architecture

Reading the model as a path clarifies the responsibility boundaries.

1. Information is created and maintained in Layer 1 source systems, each authoritative for its own domain.
2. Layer 2 establishes product identity, resolves competing internal identities, and determines which source is authoritative for each attribute.
3. Layer 3 applies governance, quality rules, validation and evidence checks, and records lineage, determining whether a value may be used at all.
4. Layer 4 moves and transforms information, executes the validation rules at the point of movement, routes exceptions to stewards, and orchestrates release.
5. Layer 5 assembles the publishable representation, binds it to a product identity, applies access rules, versions it, publishes it and records the audit trail.
6. Layer 6 makes the published representation discoverable through an identifier, a data carrier and resolution, or directly through APIs.
7. Layer 7 consumers read what they are entitled to read.

Two directional rules keep the model honest. Authority does not travel with data: a system downstream of the authoritative source never becomes authoritative by virtue of holding a copy. And corrections travel upward, not downward: a wrong published value is corrected in the authoritative source and republished, never edited at the publication layer.

Where the Digital Product Passport Should Sit

The passport service sits above integration and below access. That position is deliberate.

It sits above the integration layer because it should receive validated, governed information rather than raw extracts, and because it should not be responsible for reaching into source systems itself. It sits below access and discovery because identifiers, carriers and resolution are separable concerns that should be changeable without redesigning assembly.

It sits within the enterprise information architecture, not beside it. The information a passport publishes is the same information that supports planning, sourcing, service and reporting. Where an organisation builds a parallel compliance data set, the two versions diverge, usually within a year, and the published one is the one with an external audience.

What the Digital Product Passport Should Not Become

The passport should not become a new enterprise master database.

That means it should not be the place where product data is corrected, where attributes are authored, where missing information is invented, or where teams go to look up an internal value. Each of those behaviours makes it authoritative by accident: an unowned, ungoverned, unstewarded source of record that nevertheless shapes external claims.

It should also not become the only copy of anything. If the sole record of a value is inside the publication layer, its provenance cannot be established and its correctness cannot be defended.

Finally, it should not absorb the responsibilities of other layers. A passport service that performs its own identity resolution, its own data quality remediation and its own supplier chasing is not an architecture; it is the previous spreadsheet, hosted.

Architecture Patterns

The same logical architecture can be implemented in materially different ways. Three patterns dominate, and each is legitimate.

Federated. Information remains distributed in its source systems and is assembled when required, at request time or shortly before publication. Strengths: minimal duplication, values are as current as their sources, ownership stays unambiguous. Trade-offs: publication depends on source availability and performance, latency is harder to control, historical reconstruction requires deliberate versioning, and every source must be able to answer reliably at the moment it is asked.

Centralised. Selected passport information is assembled into a dedicated governed repository from which publication is served. Strengths: predictable performance and availability, straightforward versioning and audit, resilience to source outages, and a natural place to enforce publication controls. Trade-offs: it creates a copy, and every copy must be reconciled, refreshed and governed. Without discipline this pattern degrades directly into the anti-pattern of a second master database.

Hybrid. Master information, event information and evidence remain distributed while a controlled passport service maintains the publishable representation, typically caching what must be served reliably while resolving volatile or high volume information on demand. Strengths: it matches the three information flows to appropriate treatment. Trade-offs: it is the most complex to design and the most demanding of clear boundaries, because the rules about what is cached and for how long become part of the compliance story.

No pattern is universally superior. The determining factors are usually the availability characteristics of source systems, the volume and volatility of event data, the number of product categories in scope, and the organisation’s position on the Product Data Maturity Model.

Architecture Anti-Patterns

Each of the following is common, and each fails in a predictable way.

Practical Enterprise Example

Consider a manufacturer of a commercial refrigeration unit sold across the European Union. The product is assembled from purchased components including a compressor, an electronic controller and an insulated cabinet.

1. Product identification. The unit is identified at model level for its general description and at individual item level through a serial number, because service history and refrigerant handling attach to individual units. The model level identifier is a GTIN; the item level identity extends it with a serial number.

2. Authoritative source determination. The team produces an attribute-level authority map before any integration is built. Dimensions, materials and the bill of materials are authoritative in PLM. Commercial descriptions, packaging and logistics attributes are authoritative in ERP. Customer facing descriptions and imagery are authoritative in PIM. Refrigerant type and charge are authoritative in PLM but verified against supplier declarations. Energy performance figures are authoritative in the compliance repository, because the value is only meaningful with its test evidence. Build date, line and component lot are authoritative in the manufacturing system. Component substance declarations are authoritative in the supplier’s submission, held in the evidence repository.

3. Validation. Rules are defined per attribute: refrigerant charge must be present and within a plausible range; energy class must reference a test report that is currently valid; component substance declarations must cover every component present in the published bill of materials at the relevant revision.

4. Governance. Each attribute group has a named owner and a named steward. The escalation path is defined: a failed evidence check blocks publication of the dependent claim, a missing supplier declaration raises a stewardship task with a deadline, a conflict between two designated sources goes to the product data council.

5. Integration. PLM and ERP are read on a scheduled basis, since their change cadence is low. Manufacturing events arrive as they occur. Supplier declarations arrive through a submission process and are validated on receipt rather than at publication time, which is what makes deadlines enforceable.

6. Exception handling. One compressor supplier submits a substance declaration covering a superseded component revision. Validation detects the scope mismatch, the claim that depends on it is withheld rather than published with the old evidence, and a task is raised against the supplier manager. The rest of the passport publishes normally.

7. Passport assembly. The service composes the representation for this product category: identification, manufacturer information, materials and substances, energy performance with its evidence reference, repair and spare part information, and end of life handling guidance. Attributes that failed validation are marked unavailable rather than defaulted.

8. Publication. Version 1.0 is published with an approval record showing who released it, from which source states, and when.

9. Access through identifier and data carrier. A carrier on the unit conveys the identifier. Resolution returns the consumer view by default. A recycler authenticating as such receives additional material and disassembly detail. A market surveillance authority receives the evidence references and the audit trail. The carrier changed nothing about the information; it only conveyed the identity.

10. Lifecycle update. In year three the controller is replaced by a revised part. PLM records the engineering change, the supplier submits a new declaration, validation passes, and version 1.1 is published. Version 1.0 remains reconstructable, so what was published when a given unit was sold can still be shown. In year six a unit is refurbished and the event is appended to that item’s history without altering the model level description.

11. Regulatory access. An authority queries a specific serial number. Resolution returns the version applicable to that unit, the evidence supporting the energy claim, the lineage showing which system supplied each value, and the publication audit trail. No part of that answer required someone to assemble a file by hand.

The architecture did not eliminate the organisation’s complexity. It made the complexity governable, and it made a specific external answer defensible.

Implementation Sequence

The sequence below is deliberately not “select and buy a passport platform”. Technology selection is a consequence of the first six steps, not a substitute for them.

Benefits

A coherent architecture pays back in ways that extend well beyond the immediate obligation.

• Defensible publication. Every published value has a source, a rule, an owner and evidence, which is what makes a regulatory enquiry a retrieval exercise rather than an investigation.
• Reusability across categories. The second product category costs a fraction of the first, because identity, governance, integration and publication already exist.
• Reduced duplication. Preserving authoritative sources avoids creating copies that must be reconciled indefinitely.
• Faster correction. Corrections applied at source propagate everywhere, instead of being patched in one channel and forgotten in the others.
• Operational value beyond compliance. The same governed information improves service, spare parts, sourcing decisions and sustainability reporting.
• Lower regulatory change cost. When requirements evolve, the change lands in requirement mapping and validation rules rather than in bespoke extraction code.
• Clearer accountability. Attribute-level authority ends the recurring argument about which system is right.

Common Mistakes

• Starting with technology selection. Choosing a platform before mapping authoritative sources guarantees that the platform’s data model becomes the architecture by default.
• Treating the passport as a compliance project. Detached from enterprise information architecture, it is rebuilt at the second product category.
• Skipping attribute-level authority. System level ownership statements are too coarse to resolve real conflicts and quietly push the decision into integration code.
• Deferring evidence handling. Evidence has validity, scope and expiry, and retrofitting those properties after publication is painful.
• Modelling only master data. Lifecycle events and compliance evidence have different governance patterns and are not served by the master data pipeline.
• Publishing everything available. Scope should follow requirement and entitlement; surplus publication is surplus exposure.
• Ignoring granularity. Model, batch and item level identity are different, and a design that blurs them cannot support item level service or recycling information later.
• No exception path. Without one, the architecture publishes its least reliable data silently.
• Assuming a specific standard is mandatory. Standards are mechanisms; the legislation states the outcome required. Assuming an adoption obligation that does not exist distorts the design.
• Treating publication as the end. It is the start of a maintenance obligation measured in years.

Frequently Asked Questions

Key Takeaways

Related Articles

• How Enterprise Systems Support Digital Product Passports
• What is a Golden Record?
• What is Master Data Management (MDM)?
• How Should Organisations Prepare for Digital Product Passports?
• How to Validate Digital Product Passport Data
• How to Build a Digital Product Passport Implementation Roadmap
• How to Build a Trusted Product Data Foundation
• What is a System of Record?

Related Glossary Terms

• Digital Product Passport
• Product Data
• Product Identifier
• Data Carrier
• GS1
• GS1 Digital Link
• QR Code
• Product Lifecycle
• Product Traceability
• Conformity Assessment
• Market Surveillance
• Economic Operator
• Sustainability Data
• Delegated Act
• ESPR

References

• Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, including Digital Product Passport provisions, Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2024/1781/oj
• Regulation (EU) 2023/1542 concerning batteries and waste batteries, Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2023/1542/oj
• Regulation (EU) 2019/1020 on market surveillance and compliance of products, Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2019/1020/oj
• European Commission, Ecodesign for Sustainable Products Regulation: https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en
• EUR-Lex, official portal for European Union law: https://eur-lex.europa.eu
• GS1 identification keys, including the GTIN: https://www.gs1.org/standards/id-keys
• GS1 Digital Link standard: https://www.gs1.org/standards/gs1-digital-link
• GS1 EPCIS and Core Business Vocabulary standard: https://www.gs1.org/standards/epcis
• DAMA International, the professional association for data management and publisher of the Data Management Body of Knowledge: https://www.dama.org
• International Organization for Standardization, ISO 8000 series on data quality and master data: https://www.iso.org/standard/81745.html
• International Organization for Standardization, ISO/IEC 38505 on governance of data: https://www.iso.org/standard/56639.html

About This Article

Related Docs

• What is a Golden Record?
• What is Master Data Management (MDM)?
• What is a System of Record?
• How Enterprise Systems Support Digital Product Passports
• What is Product Data Governance?
• How to Build a Trusted Product Data Foundation
• How Does a Digital Product Passport Work?
• How Should Organisations Prepare for Digital Product Passports?
• How Product Data Moves Through the Supply Chain