Is this post for you?

You run operations, compliance, or product data at a Swiss manufacturer with real exposure to the EU market. You have seen "Digital Product Passport" in enough briefings to know it is coming, but you are not yet convinced it is yours to solve. You suspect that if you hand it to your compliance team, they will produce a technically correct answer that costs you more over the next three years than it should.

If that is your situation, this post is for you.

Bottom line up front: The Digital Product Passport is the first broad, consumer- and regulator-facing product passport Swiss manufacturers have had to produce, and it will not be the last. If scoped purely as a compliance project, you might clear the first deadline and hit problems at the next. If approached as the first use of a governed, machine-readable information backbone, you will have a good foundation that delivers the DPP and every regulated machine-readable scenario that follows.

The framing that makes this expensive

Most Swiss manufacturers first met the DPP in a briefing that framed it as a compliance requirement with a calendar attached. Batteries first, from early 2027. Textiles, iron and steel, and further categories phased across 2027 and 2028. More still through the end of the decade.

Framed that way, the response is obvious. Assign a compliance lead, scope a project for whichever category lands first, produce a passport-shaped output by the deadline, and move on.

That response works for the first deadline and fails at the second, because the compliance framing treats the DPP as a reporting task - producing structured output about a product for a regulator. The regulation is written differently, focusing on interoperable, machine-readable records about a product to be available across the product's life, with contributions from multiple sources, read by several systems, and verifiable by regulators, market surveillance authorities, and commercial partners downstream. A report is a one-way flow, while a DPP is a shared record that many parties keep over a product's life. Those are different architectures, and the second one cannot be reached by improving the first.

Why the second deadline breaks the first solution

Picture a manufacturer that treats its first DPP category as a self-contained compliance project. Product data is exported from existing systems, transformed into the required schema, published to an endpoint, and paired with a code on the physical product. The system works, the audit passes, and the deadline is met.

Some months later, a second product line comes into scope under a different delegated act. The passport format is largely common - that is the point of the EU's harmonized standards - but the requirements around it are not: different data fields, different lifecycle information, different downstream consumers. The first system still cannot be reused, because it was built to transform source data into one category's output, with no shared representation underneath it. A second project is scoped. Then a third category arrives, and a third project with it.

By the end of the decade, the manufacturer is running several parallel DPP systems, each maintained by a different team, each with its own vendor, each pulling from the same underlying enterprise systems and transforming that data a different way. Each needs its own maintenance as its target regulation evolves. Each audit trail stands alone.

I have watched this pattern play out across sectors and geographies for a decade - point solutions built regulation by regulation multiply, where a shared foundation would have consolidated them. Every organization that takes this path eventually rebuilds from a common backbone, and the rebuild costs more than getting the backbone right the first time.

The Swiss position: exporter, and in some categories not even that

There is a version of this trap that Swiss manufacturers could fall into more readily than their EU counterparts.

Switzerland is not an EU member state, so for most categories the DPP does not directly apply to a company selling only within Switzerland. That invites a natural move: treat the DPP as an EU export problem, hand it to the export division, and scope it apart from the rest of product data operations.

Two facts make that move a mistake. The first is the scale of the exposure. The EU is Switzerland's largest export market by a wide margin, and any product placed on the EU market from 2027 onward will need a compliant DPP - which pulls Swiss battery, textile, steel, and industrial suppliers into the same deadlines as their EU competitors. The second is that the domestic exemption is already partial: for construction products and toys, the DPP requirement is set to apply to products placed on the Swiss market as well, with only a slight delay behind the EU. The idea that this is purely an export concern does not survive contact with the actual scope.

Even where export is the trigger, the data that fills a DPP originates upstream - in engineering, sourcing, manufacturing, and quality - not at the border. A manufacturer that treats the passport as an export-step transformation will find that the information it needs was never captured at source and cannot be reconstructed on the way out. The DPP is a product data problem that happens to arrive first through the EU market. The response has to start inside the product data, not at the export interface.

What the DPP actually requires

The regulation asks for three things that change how product data has to be managed. None is optional, and none is met by adding a publishing step on top of existing systems.

It requires structured, machine-readable data with governed meaning - data a receiving system can act on without interpreting what each field means. The passport has to be open, interoperable, and machine-readable, connected to a unique product identifier through a data carrier, so that a regulator's verification tool, a customer's system, and a recycler's scanner all read the same data the same way. That is what the emerging technical standards, built on identifiers like GS1 Digital Link and formats like JSON-LD, exist to guarantee. Getting there takes governed reference data, shared classifications, and explicit relationships between concepts, so that "material" in your data means the same thing everywhere it is read. Most manufacturers still manage material definitions inconsistently across departments, and that inconsistency does not survive contact with a machine-readable mandate.

It requires information that stays available and current across the product's life. The DPP is designed to keep relevant product data accessible from the point a product is placed on the market through to end-of-life, rather than as a snapshot produced once and filed. The precise data fields and update obligations arrive category by category through delegated acts, most of which are still to come, but the direction is fixed, and responsibility sits with the economic operator placing the product on the market. That operator cannot discharge the obligation with a one-time export, and product data held as a static record, produced once and never maintained, does not meet it.

It requires verifiability and persistence. The passport data has to be accurate, complete, and current, because customs and market surveillance authorities can check it, and different actors - consumers, repairers, recyclers, regulators - are entitled to see defined parts of it, with the specific access rights set per category in the delegated acts. The regulation also requires the data to outlast any single platform: an independent third-party operator must hold a backup, and a central EU registry links products to their passports through their identifiers. Records assembled at query time from scattered sources, with no persistent, traceable source of truth behind them, do not hold up against that.

Each of these reads as a technical detail. Each is an architectural decision that has to be made before the first passport is authored. Deferred, every one of them becomes expensive to retrofit.

What "getting the foundation right" means

The pattern is consistent across manufacturers with complex product portfolios. The data exists, but it is scattered. Composition and specification data sit in one system. Batch and manufacturing data sit in another. Supplier certifications sit in procurement documents or portals. Regulatory data sits in compliance tools. Each system holds a piece of the truth about a product, and no system holds the whole of it. What is missing is the connective foundation that unifies those sources into one governed representation of each product.

That foundation is the information backbone: the governed, machine-readable representation of your products, the substances they contain, the systems they belong to, and the regulatory context they sit in, shared across the systems that author it and consume it. It is not a data lake, a reporting store, or a set of interfaces bolted onto existing systems, but the source of truth for what your products are, in a form both humans and machines can rely on. Every regulatory disclosure and every DPP is a projection of it. Every downstream tool - a compliance platform, an AI system, a supplier portal - plugs in through a defined interface and stays interchangeable.

At Data Graphs we have built information backbones for regulated and high-trust industries for over a decade. Data Graphs was selected by CropLife Europe for the AgriGuide platform, and is live across 27 EU member states and 24 languages with a complex, regularly updated machine readable information backbone. The information it holds serves machine-readable digital product labels today, and the same information will serve DPP requirements as ESPR extends. There is no parallel system and no second architecture to maintain - that is the operational payoff.

The Swiss resources that make this easier

Swiss manufacturers do not have to navigate this alone. GS1 Switzerland has organized support around the DPP transition - guidance, events and working sessions, pilot implementations, and a solution partner network built around GS1 standards and the underlying data infrastructure. Bringing that community in early, at the scoping stage rather than after a vendor is chosen, is one of the cheapest ways to avoid the common early mistakes.

The deeper reason to act now is architectural. Product data spread across separate systems - specification in one, manufacturing in another, supplier and regulatory data in others - is easier to unify under a governed backbone than to force out of a single platform that was never built for machine-readable disclosure. A distributed estate is not the obstacle it looks like, provided the backbone goes in above it rather than as another system beside it.

The manufacturers that treat this as an architecture decision in 2026 will meet the DPP as a publishing step. The ones that wait will be staffing compliance projects in 2027.

Simple Steps for COOs

1. Question the compliance framing before you sign the first project scope. If the DPP is being scoped in isolation from product data operations, ask whether the underlying data foundation is being addressed or merely built around. The answer tells you whether you are solving one deadline or building for every regulation that follows it.
2. Evaluate platforms against backbone characteristics, not passport output. Before you buy anything that produces a DPP, ask whether it is model-centric, exposes governed meaning through open-standard APIs, governs its reference data, and can take on a new regulation as an easy model change rather than a new build - because those are the properties that make one foundation serve the DPP and what comes after it.
3. Engage GS1 Switzerland and its solution partner network before the RFP, not after. The Swiss standards community has moved further and faster on DPP coordination than most. Involving them at the scoping stage produces better decisions and avoids the most common early mistakes.

This article is by Matt Shearer, COO at Data Graphs. Based in Zurich, Switzerland, Data Graphs is a knowledge graph platform and GS1 Switzerland Solution Partner. We help manufacturers build information backbones that provide Digital Product Passports. To discuss your DPP roadmap, contact us.