Digital Product Passport Architecture: The EU ESPR Data Model (2026)

Last Updated: October 2026

A manufacturer shipping a battery, a jacket or a refrigerator into the European Union will soon have to attach something the product never carried before: a structured, machine-readable record of what it is made of, who is responsible for it, how to repair it and how to recycle it. The record is not a PDF. It is a distributed data product that spans PLM, ERP, supplier feeds and a public registry, and it must stay resolvable for longer than the software that created it. Getting digital product passport architecture 2026 right is therefore a systems-engineering problem, not a compliance afterthought.

The year changed the picture. In July 2026 the Commission adopted the implementing rules for the passport registry, and the first six harmonised standards for identifiers, carriers and APIs were cited in the Official Journal. What is still unfinished is the payload: per-product-group field lists. This post separates the stable plumbing from the moving content and shows how to design for both.

What this covers: the regulatory state as of October 2026, a layered reference architecture, the data model, identifiers and carriers, the registry and resolution path, PLM integration, field-level access control, failure modes, and a practical checklist.

Context and Background

The Digital Product Passport (DPP) is created by the Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781, known as ESPR. It entered into force in July 2024 and replaced the older Ecodesign Directive, which covered only energy-related products. ESPR is a framework law. It creates the legal basis for the passport and for a central registry, but it leaves the concrete requirements to delegated acts adopted product group by product group.

That delegation is why dates are slippery. The Commission adopted its first ESPR Working Plan, COM(2025) 187, on 16 April 2025. It lists priority groups including iron and steel, aluminium, textiles, tyres, furniture and mattresses, plus horizontal measures such as a repairability score and electronics recyclability. Secondary trackers summarising the plan put the indicative delegated-act dates between 2026 for iron and steel and 2029 for mattresses, with compliance roughly two years after each act. These dates are indicative rather than binding, and one tracker reported that no additional ESPR delegated acts had been adopted as of late August 2026. Treat any single date for a non-battery category as a planning assumption, not a deadline.

Batteries are the exception, and the reference implementation everyone studies. The EU Batteries Regulation, Regulation (EU) 2023/1542, already requires a battery passport. The Commission’s own battery-passport page gives 18 February 2027 as the date the passport becomes mandatory for the relevant categories: electric vehicle batteries, batteries for e-bikes, e-mopeds and e-scooters, home storage batteries and industrial batteries. The obligation falls on the economic operator placing the finished battery on the market, not on component suppliers. We cover that lineage in our deep dive on the battery passport and EU regulation, and the patterns generalise directly.

On the technical side, the CIRPASS project, an EU-funded coordination effort, produced the cross-sector system definition that the Commission’s design leans on. Its successor, CIRPASS-2, runs from May 2024 to April 2027 and published an updated reference architecture in June 2026, which its authors describe as an exploratory proposal rather than a binding specification. Standardisation runs through CEN-CENELEC JTC 24.

The strategic reading is simple. The plumbing is settling and the payload is not. Identifiers, data carriers, resolution and the registry are now defined in law and standards. The required fields for each product group are not yet. A sound architecture therefore commits firmly to the stable layers and treats the field catalogue and event vocabulary as versioned configuration. Teams that hard-code one category’s fields into their schema will rework it with every delegated act. Teams that build a category-agnostic core absorb each new product group as data.

What Changed in 2026

Three developments matter for architects, and each can be traced to a primary or near-primary source.

First, the registry now exists. Commission Implementing Regulation (EU) 2026/1778, dated 16 July 2026, lays down the implementation arrangements for the DPP registry under Regulation (EU) 2024/1781. EUR-Lex lists 6 August 2026 as its date of entry into force. The Commission’s battery page and law-firm summaries state the registry became operational on 20 July 2026, so the operational launch preceded formal entry into force; confirm the exact legal sequencing with counsel before relying on either date.

Second, the registry is a pointer system. Per secondary summaries of the regulation, it does not store the complete passport. It holds a unique registration identifier, registration metadata, hosting references, references to backup-hosting providers, a list of recognised DPP service providers, a verification platform, a log system and a semantic repository of data models and controlled vocabularies exposed through public APIs. Registration is by web interface or API, operator verification lasts up to three years, and registration data is kept ten years by default unless other EU law says otherwise.

Third, the first standards landed. Secondary sources report that six standards, EN 18216 to EN 18223 (a family covering unique identifiers, data carriers, programmatic access, machine-readable content and long-term availability), were cited in the Official Journal on 15 July 2026, giving a presumption of conformity with ESPR Articles 10 and 11. The same sources report EN 18239 and EN 18246, on access rights and data authentication, were published by CEN-CENELEC on 16 September 2026 but not yet cited, so no presumption of conformity applies to them. Verify the exact titles and citation status against the Official Journal before building contracts around them.

One point from the registry coverage deserves emphasis: the registry launch is not by itself a new registration obligation. Product-specific obligations arrive with each delegated act. For the engineering team, that means the next twelve to eighteen months are about building and testing capability, not flipping a switch.

The Digital Product Passport Reference Architecture

A digital product passport is a structured, machine-readable record, reachable from a data carrier on the physical product, that holds a product’s identity, composition, sustainability, repair and end-of-life data. Fields are exposed selectively to consumers, economic operators and authorities under defined access rules. The architecture below separates carrier, identifier, resolution, data and access so each can evolve independently.

Figure 1: The layered digital product passport architecture, from the physical carrier up through identifier, resolution and registry, operator service, data model and access control, fed by PLM, ERP and MES.

Figure 1 shows the spine. A QR code on the product or packaging encodes a unique identifier expressed as a GS1 Digital Link URI. A resolver and the EU registry map that identifier to the responsible economic operator’s DPP service, or to a backup provider. The operator’s service holds the data model, which is fed by engineering and production systems. An access-control layer wraps the whole record so that each audience receives only its permitted projection. The design principle is that no layer should know more than it must: the carrier knows an identifier, the registry knows a pointer, and only the operator service knows the content.

Three tiers of identity: model, batch, item

The data model has three logical tiers of identity, and conflating them is the most common early mistake. Model-level identity describes a type: a refrigerator SKU or a jacket design. Batch-level identity describes a production lot sharing a bill of materials and supplier set. Item-level identity describes one serialised unit. The registry regulation confirms passports may be registered at model, batch or item granularity, and batteries lean toward item level while many textiles may sit at model or batch level.

Your architecture must support all three because one manufacturer will span categories. The practical rule is to mint the coarsest identity the delegated act allows, then link downward. A battery pack passport, for example, can reference its cell batch and its module passports rather than copying their data. CIRPASS-2 guidance makes the same point: components that have their own passports should be linked persistently to the sub-passport instead of duplicating it.

Attributes versus lifecycle events

Around identity sits the attribute set: material composition, substances of concern, recycled content, footprint, durability and reparability indicators, spare-parts availability, and dismantling or recycling instructions. These are largely static per model or batch because they describe the product as designed and built.

The second element is the lifecycle event log: a time-ordered record of repairs, ownership transfers, refurbishment and recycling. Events are append-only and item-scoped. Modelling attributes and events with one flat schema is a trap. Attributes are snapshots and read-heavy; events are a growing ledger with different retention and write profiles. CIRPASS-2 recommends that the original passport and every update be immutable, with changes creating new timestamped entries and signed receipts.

The consequence is two storage strategies behind one API. Attributes cache well at the edge and tolerate TTLs of hours or days. Events want an append-only store with strong durability. A useful pattern is to treat the attribute record as a versioned document: each design or BOM revision produces a new immutable version, and an item pins to the version current when it was built. When a regulator asks about the recycled-content claim for the unit built in March, you resolve the item to its build-time version, not to today’s design. Without that pinning, a routine engineering change silently rewrites the history of every unit in the field, which is wrong and, for a regulated claim, a liability. Our post on engineering change management covers how ECO workflows should emit those version events.

Fields as configuration, not code

Each delegated act will define a controlled list of required and optional fields with units and allowed ranges. Hold a superset internally and project the per-category required subset at publication time. Adding a product group then becomes a configuration change rather than a schema migration. The registry’s semantic repository, which publishes data models, definitions and multilingual labels through public APIs, is the natural upstream source for that catalogue, so design your field registry to import from it rather than retype it. Treating the field catalogue as data is the highest-leverage decision in the model. For a deeper look at mapping passport fields onto Asset Administration Shell submodels, see our DPP data model with GS1 and AAS guide and the Asset Administration Shell architecture overview.

Identifiers and Data Carriers

The identifier is the keystone. The consensus reflected in CIRPASS work and in the standards trackers is to build the unique product identifier on GS1 keys and open it through a GS1 Digital Link URI. According to a secondary standards tracker, EN 18219 defines the unique product identifier, building on the GS1 GTIN, with a resolver aligned to ISO/IEC 18975; EN 18220 defines the data carrier with QR as primary and NFC and RFID as secondary. The Commission’s battery page confirms the QR-code link for batteries.

How Digital Link works

Digital Link turns a plain GTIN or serialised identifier into a resolvable web address. The path encodes GS1 Application Identifiers, for instance https://id.example.com/01/<GTIN>/21/<serial>, where 01 is the AI for a GTIN and 21 is the AI for a serial number. Through HTTP content negotiation, a browser sending Accept: text/html is redirected to a consumer page, while a machine sending Accept: application/ld+json is routed to structured data. One physical code serves two audiences, selected by a header. That is why a Digital Link is preferable to an opaque URL: it preserves the GS1 keys that existing supply-chain systems already understand.

A worked example makes the tiers concrete. A model-level passport might use only the GTIN: /01/09506000134352. A batch-level one appends the lot with AI 10: /01/09506000134352/10/LOT42. An item-level one appends the serial with AI 21. The same resolver handles all three, and link types such as a repair-instructions link or a safety-information link can sit under each path. This is one of the cleaner tricks in the stack: granularity is a property of the URI, not of the system.

Choosing the carrier

The carrier is an engineering trade-off, not a default.

Carrier	Strength	Weakness	Best use
QR code	Cheap, no power, universal phone support	Forgeable, no on-product storage, wears off	Consumer access, primary carrier
NFC tag	Tap interaction, small authenticated payload	Unit cost, needs chip integration	Anti-counterfeiting, premium goods
RFID tag	Bulk reads without line of sight	Readers not in consumers’ pockets	Logistics, recycling lines
Data matrix	Compact on small parts	Needs a reader app on many phones	Small components, electronics

A QR code carries only the identifier, so capacity limits do not bite. What bites is durability. Choose a high error-correction level, Q or H, so a scuffed code still decodes years later at a recycling facility, and test print adhesion across the product’s real life, including heat, abrasion and cleaning. Many designs combine a public QR with an NFC or RFID tag for industrial reads, with the same identifier encoded in each. A subtle point: if the code is printed on packaging only, it is lost the day the box is discarded, so carrier placement on the product itself is a design decision to settle early with industrial design.

The DPP Registry and Decentralised Resolution

Architects often assume the registry stores the passport. It does not. Per the Commission-aligned summaries, the registry stores what is needed to identify and locate each passport, and passport content remains the economic operator’s responsibility. The result is a thin, authoritative index with a decentralised data plane.

Three concerns that the word registry tends to blur should stay separate:

• Discovery: given an identifier, who is the responsible operator and where is the endpoint. This is the small authoritative mapping the registry holds.
• Resolution: the redirect from a scan to that endpoint, performed by a Digital Link resolver that can be federated and cached near the user.
• The data service: run by the operator or its service provider, holding the passport and enforcing access.

Figure 2: Resolution from a scan to a role-based view, including failover to a backup provider when the operator service is unreachable.

Figure 2 traces the read path. A scan yields a Digital Link URI, the resolver consults the registry for the hosting reference, the user is redirected to the operator’s service, and the service returns the permitted projection. If the service is down, the user is sent to a backup provider that mirrors the dataset. The registry design explicitly anticipates this: it records references to backup-hosting providers, and CIRPASS-2 recommends that backup providers mirror the full dataset, stay synchronised and apply identical access controls. It also recommends an independent EU fallback redirection service.

Why thin is right

The scaling argument is straightforward. A few billion items each needing an identifier-to-operator pointer is a modest index. Centralising every bill of materials would be a petabyte-class liability and a privacy hazard. Continuity is the second argument. Operators change cloud vendors, switch DPP service providers and occasionally go bankrupt. If the registry holds only pointers, redirecting an identifier to a successor or an escrow endpoint is a single mapping update. If it held data, every migration would be a bulk transfer with its own failure modes. Decentralisation here is not ideology; it is the cheapest route to a system that must outlive the companies inside it.

DPP service providers

The registry keeps a list of recognised DPP service providers, and authorised providers can register on behalf of operators within granted permissions, although the operator stays responsible for the registered data. Build-versus-buy therefore becomes a real option. A mid-sized manufacturer may reasonably outsource hosting and publication while keeping the mapping logic, field catalogue and access policy under its own control. The contract question that matters is exit: can you export every passport, event history and signing key, and repoint the registry entries, within a defined window? Treat the exit clause as a first-class requirement, because a ten-year-plus lifetime guarantees you will change providers at least once.

Integration with PLM, ERP and the Digital Thread

The passport is only as good as the systems behind it. Design-time data such as materials, substances, reparability and dismantling steps originates in PLM. Production-time data such as batch, supplier lot, site and date originates in ERP and MES. The DPP service is an aggregation and publication layer, not a new master of record.

Figure 3: Event-driven publication. PLM, MES and ERP emit events; the DPP service validates required fields, registers the identifier and publishes only a complete passport.

This is where a clean digital thread pays off. If your PLM maintains a versioned bill of materials linked to as-built records, populating the passport is a mapping exercise. If it does not, you are reconciling spreadsheets under regulatory pressure. The conversion from engineering to manufacturing structures matters here too; our guide to EBOM to MBOM transformation explains where those structures diverge, and substance data usually rides on the compliance model described in the RoHS, REACH and SCIP substance tracking post.

Event-driven beats point-to-point

The integration topology matters more than the connector brand. Wiring each plant’s MES and ERP directly to the DPP service yields N times M links that break independently whenever a schema moves. The better pattern is event-driven. Production systems publish well-defined events such as unit built, batch closed and supplier lot consumed onto a shared backbone, and the DPP service subscribes. A unified namespace gives multi-plant manufacturers a consistent place to do that.

A worked example: a unit’s passport needs four facts at build time. The model’s attribute version comes from PLM, the batch and site from MES, the supplier lot genealogy from ERP, and the serialised identifier is minted at the line. If those arrive as four events keyed by the same item identifier, the DPP service assembles the passport deterministically. If they arrive as four nightly file drops in different formats, you have a reconciliation project and a class of silent mismatches.

Validate, then publish

Treat the mapping from internal fields and units to the category schema as code under version control, with tests and review. A failed or partial mapping must surface as a publication error that blocks the passport from going live with missing required fields. An incomplete passport is a compliance gap, not a cosmetic one. Idempotency matters as well: events can be redelivered, so the same unit-built event must never mint a second identifier or a duplicate registration. Key every write by item identifier and event identifier, and make registration calls safe to retry.

Supplier data and the weakest link

Most of a passport’s content about materials and origin comes from suppliers, and supplier data quality is the single biggest delivery risk. Plan for partial data: capture a completeness status per field and a provenance record for each value (who supplied it, when, under what document). Where a supplier cannot yet provide a field, the passport pipeline should hold the unit in a draft state rather than publish a guess. Link, do not copy, where a supplier operates its own passport, so the supplier remains the steward of its data and your passport inherits updates through the reference.

Field-Level Access Control

Not every field is for everyone. ESPR contemplates public data alongside data restricted to authorities, repairers, recyclers and other actors, including for commercial confidentiality. The DPP service must therefore enforce field-level tiers, not document-level ones, because one passport mixes them.

Tier	Typical audience	Example fields	Authentication
Public	Consumers, general web	Model identity, care and use, recycled-content claim, recycling guidance	None
Restricted	Authorities, repairers, recyclers	Detailed bill of materials, substances of concern, dismantling sequence, spare-part references	Verified role credential
Private	OEM and named partners	Supplier identity, cost-sensitive composition, internal lot genealogy	Operator-issued token

The tier names are an illustrative design pattern, not terms mandated by law; the actual access rights per field will be set by each delegated act.

Figure 4: Access decision on every request. No credential or an untrusted issuer yields the public projection; a validated role claim widens it; only an operator token unlocks private fields.

Figure 4 runs on every read. An unauthenticated caller receives the public projection. A caller presenting a verifiable role credential, validated against a trusted issuer, receives the restricted projection. Only an operator-issued token opens private fields. CIRPASS-2 describes this model: verifiable credentials for organisational identity and roles, role credentials issued or guaranteed by trusted bodies, and public and role-specific datasets deliverable as linked JSON-LD verifiable credentials.

Enforce on the server, before serialisation

The recurring real-world breach is simple. The restricted bill of materials ships in the JSON payload and a private flag only dims it in the UI, so anyone reading the raw response sees everything. The projection must be chosen before serialisation, by selecting which fields to emit, never by returning the full record and hiding fields client-side. Test it: issue the same request under each role and assert the exact field sets returned. Because the decision runs on every request, keep it cheap: a claims check and an allowlist lookup, not a per-field database round trip.

Log access events as well. Regulators may want evidence that restricted data reached only entitled parties, and your own security team will want anomaly detection on scraping of the public tier. If the passport service is also an internet-facing product with a digital element, its cyber obligations apply too; see our mapping of the Cyber Resilience Act, NIS2 and IEC 62443.

Machine-Readable Content and Exchange

The content itself should be machine-readable and linkable. The standards trackers report that EN 18223 covers machine-readable content with JSON-LD, and CIRPASS-2 names JSON-LD as the default exchange format with modular, extensible DPP templates and lifecycle APIs based on prEN 18222. The practical advice is to model the passport as a graph of linked documents rather than a monolithic JSON blob: a core identity document, attribute modules per topic (materials, repair, carbon), and event streams referenced by link.

JSON-LD brings two benefits. Semantic keys tie each field to a shared definition, which is what the registry’s semantic repository is for, and compact context files keep payloads small. It also brings a cost: context documents must be versioned and hosted for a decade or more, because a passport whose context URL has vanished is half-unreadable. Pin and mirror contexts, or embed them in a signed bundle.

A minimal illustration of an attribute module, shown as a sketch rather than an official schema:

{
  "@context": "https://example.com/dpp/context/v3.jsonld",
  "id": "https://id.example.com/01/09506000134352/21/A1B2C3",
  "type": "ProductPassport",
  "attributeVersion": "BOM-2026-114",
  "recycledContent": { "value": 18, "unit": "percent" },
  "events": "https://dpp.example.com/events/A1B2C3"
}

For pairing with the Asset Administration Shell world, where submodels already carry units, semantic IDs and lifecycle metadata, see our notes on AAS metamodel 3.2. The two stacks are complementary: AAS is a strong internal model for industrial assets, while the passport is the externally published, regulated view.

Capacity, Cost and Operations

No official sizing guidance exists, so what follows is back-of-envelope reasoning with illustrative numbers, labelled as such. Suppose a manufacturer ships 20 million serialised units a year with a ten-year service life. That is 200 million live item-level passports. Suppose an attribute document averages 20 KB but is shared by model or batch, while per-item events average 2 KB and each item sees five events in its life. Per-item event storage is then roughly 10 KB, or about 2 TB across 200 million items, which is trivial for modern object storage. The attribute store is smaller still because versions are shared.

The real cost drivers are elsewhere. They are availability (the passport must answer a scan at a recycler years later), signing and key management, the compliance workflow for supplier data, and human effort in field mapping. Read traffic is spiky and cache-friendly: the public tier can sit behind a CDN with long TTLs on attribute documents, while event reads are less cacheable. Budget for a standing ten-year retention line, since registry data is retained ten years by default and your own backup obligations will be at least as long.

Operational readiness means rehearsing failure. Run a game day where the primary region is down and confirm that scans fail over to the backup provider with correct access rules. Run another where a supplier restates a substance value and confirm that affected passports get a new version, not an overwrite, and that the change is traceable.

Trade-offs, Gotchas, and What Goes Wrong

Building against an unfinished payload. The largest risk is hard-coding one category’s fields. When the textiles act arrives, a rigid schema breaks. The mitigation is the configuration-driven catalogue described earlier, plus contract tests against each published field list.

Treating the registry as storage. Teams that expect the registry to hold or back up their data will discover it holds pointers and metadata. Backup is your responsibility, via your own copies or a backup-hosting provider.

Identifier churn. Changing the URI scheme or resolver domain after products ship strands every printed code. Own your resolver domain, never tie it to a vendor’s hostname, and plan for the domain to outlive your company name. Where the registry assigns its own registration identifier, store the mapping between it and your Digital Link.

Confidentiality leaks through aggregation. A public field set that looks harmless can reveal a supplier or cost structure when combined across many items. Review public fields in aggregate, not one passport at a time.

Standards in motion. Some standards are cited and some are only published or in draft. Where a standard is not yet cited, no presumption of conformity applies, so treat it as guidance. Build an adapter layer so a change in a carrier encoding or API shape is a localised fix.

Trust and authenticity. A QR code can be copied onto a counterfeit. The registry helps by recording the legitimate steward, and NFC with a signed payload can add item-level proof, but neither is free. Decide per category whether anti-counterfeiting is a requirement or a nice-to-have.

Long-term readability. Ten-plus years is longer than most SaaS vendors, JSON-LD contexts and TLS certificates. Document formats, hosting arrangements and cryptographic suites all need a renewal plan, which is why the standards family includes a dedicated long-term availability standard.

Reading paper as deadline. Dates from the Working Plan are indicative. Planning around them is sensible; contracting around them as if fixed is not.

Practical Recommendations

Begin with the stable layers, and make them boring. Adopt GS1 Digital Link for identifiers now, even before your category’s delegated act lands, because the carrier and resolver design is unlikely to be the part that moves. Own your resolver domain. Build the registry integration as a thin adapter that registers identifiers and stores the returned registration ID next to each passport.

Next, invest in the data foundation. Version your BOM and attribute records so units pin to a build-time version. Hold the field catalogue as configuration and import vocabularies from the registry’s semantic repository. Instrument your PLM to emit change events, and stand up an event backbone so MES and ERP feed the DPP service without point-to-point links.

Then handle the people and contract side. Decide whether you will host the passport yourself or use a recognised service provider, and negotiate exit rights and export formats before you sign. Start supplier data collection early, because it is the long pole. If you make batteries, treat 18 February 2027 as a hard date and work backwards.

A short readiness checklist:

• Identifier scheme chosen, resolver domain owned, QR placement approved by industrial design.
• Model, batch and item identity supported, with link-not-copy for component passports.
• Attribute versions pinned per unit; events stored append-only.
• Field catalogue held as configuration; category projections tested.
• Event-driven feeds from PLM, MES and ERP with idempotent writes.
• Server-side field-level access with per-role response tests and access logging.
• Backup provider and failover rehearsed; exit clause with provider agreed.
• Supplier data completeness and provenance tracked per field.

Frequently Asked Questions

What is a digital product passport?

A digital product passport is a structured, machine-readable record linked to a physical product through a data carrier such as a QR code. It holds identity, composition, sustainability, repair and end-of-life information, with fields exposed selectively to consumers, economic operators and authorities. It is created under the EU Ecodesign for Sustainable Products Regulation, Regulation (EU) 2024/1781, and the battery passport is created by the Batteries Regulation, Regulation (EU) 2023/1542.

When does the digital product passport become mandatory?

It depends on the product group. For batteries, the Commission states 18 February 2027 for the relevant categories. For other groups the obligation arrives with each ESPR delegated act, and the Working Plan dates are indicative: secondary trackers put iron and steel around 2026 for the act and textiles around 2027. As of late August 2026 one tracker reported no further delegated acts adopted. Check each group individually.

Does the EU DPP registry store the passport data?

No. The registry stores registration identifiers, metadata, hosting references and references to backup providers, plus supporting services such as a semantic repository and logs. The passport content stays with the responsible economic operator or its service provider. Registration data is retained for ten years by default unless other EU law provides otherwise, and registration is possible through a web interface or API.

Which identifier and data carrier should I use?

The standards direction is a unique product identifier built on GS1 keys and expressed as a GS1 Digital Link URI, carried primarily by a QR code, with NFC or RFID as secondary options. Secondary trackers attribute this to EN 18219 and EN 18220. Choose QR error-correction level Q or H, own your resolver domain, and use the same identifier across all carriers.

How does a digital product passport connect to PLM and ERP?

The DPP service is a publication layer, not a system of record. PLM supplies design-time data such as materials and dismantling instructions; MES and ERP supply batch, site and supplier lot data. The cleanest pattern is event-driven: systems publish events keyed by item identifier, the service validates required fields, registers the identifier and publishes only a complete passport.

How should access to passport data be controlled?

Enforce access at field level on the server, choosing which fields to serialise per requester rather than hiding them in the client. A common pattern is public, restricted and private tiers, with restricted access granted through verifiable role credentials validated against a trusted issuer. Log access events, test each role’s exact response, and remember that actual access rights per field will be set by delegated acts.

Further Reading

Related posts on this site:

• Digital product passport data model with GS1 and AAS
• Battery passport and EU regulation for PLM
• Asset Administration Shell architecture
• Digital thread PLM architecture
• Unified namespace architecture for industrial IoT

External references:

• European Commission: Digital product passport for batteries
• EUR-Lex: Implementing Regulation (EU) 2026/1778 on the DPP registry
• CIRPASS project: DPP system architecture deliverable
• GS1 standards enabling the EU digital product passport

Disclosure: details attributed to secondary summaries (registry contents, EN 18216 to 18223 and EN 18239/18246 roles and citation dates, Working Plan date table) were not verified against the full primary texts at the time of writing. Sizing numbers are illustrative. This is architecture analysis, not legal advice.

By Riju — about