
🇮🇹🇩🇪🇫🇷🇪🇸🇵🇹🇳🇱🇵🇱🇸🇪🇩🇰🇫🇮🇨🇿🇷🇴🇭🇺🇬🇷🇧🇬🇭🇷🇸🇰🇸🇮🇪🇪🇱🇹🇱🇻🇮🇪🇲🇹🇸🇦🇨🇳🇯🇵🇰🇷🇮🇳🇹🇷🇻🇳🇮🇩
The Digital Product Passport market has been organized around a structural misunderstanding. Vendors communicate ESPR compatibility as if the regulation were a document format — a digital product sheet with multiple fields. It is not. ESPR is an enforcement framework: it defines who has access rights, with what technical standards, for how long, and with what granularity. The distance between these two interpretations is where the real operational risk for today’s buyers is concentrated.
The carrier problem is not the problem
The industry’s business narrative has invested heavily in RFID and QR codes as proof of “DPP readiness.” The carrier is necessary but not sufficient. ESPR requires that the passport contain specific attributes — durability, recycled content, presence of hazardous substances, reparability — structured in a machine-readable and interoperable manner. The reference technical specification is GS1 Digital Link combined with EPCIS 2.0 for the traceability of supply chain events.
Thanks for reading! Subscribe for free to receive new posts and support my work.
I verified the technical output of seven providers active in the fashion and textile segment. No one exposes GS1 Digital Link-compliant structured data in the form required for automated queries by surveillance systems. All of them expose web portals with dashboards. A dashboard is not an enforcement API.
Lifecycle persistence: the SLA that no one publishes
Article 9 of the ESPR Regulation states that passport information must remain accessible for a minimum period of 10 years from the date of placing on the market of the last example of that model. Not from the end of the contract with the provider. Not from the closure of the client company.
This distinction has severe architectural implications. The passport must survive the commercial relationship between brand and vendor. It means that the data must be deposited on a register with independent governance, or that there is a certified escrow mechanism, or that the provider publishes retention SLAs verifiable by a third-party auditor.
I have explicitly asked three providers for this documentation during technical demos in recent months. In two cases, the answer was that “data continuity is contractually guaranteed.” A B2B contract is not a public enforcement mechanism. In the third case, the question remained unanswered in the email follow-up.
If you’re considering a DPP provider, this is the first question to ask: show me your data retention architecture for the event that your company goes out of business in 2029. The answer will tell you everything you need to know.
Market surveillance: closed access by definition
ESPR assumes that market surveillance authorities (MSAs) — in Italy the Ministry of Enterprise and Made in Italy, customs, delegated regional bodies — can access passport information in a standardized way, not mediated by the brand or vendor. This is the pillar of the enforcement system.
The current model of DPP providers is incompatible with this architectural requirement. Data resides in proprietary systems. Access is mediated by credentials provided by the customer (the brand). A customs inspector scanning a garment in Rotterdam has no way of querying the register directly: he has to go through the brand portal, which may be inactive, restructured, or simply unresponsive.
The EU centralized register — still in the technical definition phase by EISMEA — should solve this problem. But the deployment timeline is not aligned with the first ESPR obligations for textiles, scheduled to start in 2026–2027. In the meantime, providers sell solutions that will be backwards compatible “when the registry is ready.” This is an architectural risk, not an implementation detail. The UNTP (UN Transparency Protocol) is the only interoperability standard currently designed to close this gap.
Error governance: the process that does not exist
An attribute in the passport is incorrect. It happens: a supplier certifies a percentage of organic cotton that subsequently fails a second-party audit. The data in the passport must be correct. The previous version must be kept with timestamp and reason for the change. The audit trail must be unalterable.
This is the operational governance of errors. I have not found a single provider that publicly describes — in technical documentation, not in marketing material — the amendment process, the versioning model, and the guarantees of non-alterability of the audit trail.
The problem is not technical in the strict sense: versioning systems exist and are mature. The problem is that no one has yet designed it as a binding operational requirement for the DPP. The market treats the passport as a static document. ESPR treats it as a living record with auditable history.
Thanks for reading! Subscribe for free to receive new posts and support my work.