As the EU's Digital Product Passport regime moves toward its central registry launch on July 19, 2026, three words in EU Regulation 2024/1781 carry the architectural requirement for certification verification across the union. Open. Non-proprietary. Machine-readable.
Each is a separate test. Each binds independently. The requirement binds at the architecture layer, beneath the user interface, and most existing verification systems do not clear it.
What the regulation says
Article 9 of the Ecodesign for Sustainable Products Regulation (the ESPR, EU Regulation 2024/1781) specifies that Digital Product Passport data must be based on "open standards and interoperable formats" and must be "machine-readable, searchable and structured." The regulation's accompanying technical guidance is more specific: the standards must be "open, non-proprietary international standards," and the technologies underlying DPP infrastructure must operate "without dependence on any commercial technology provider."
These are three distinct requirements. Open and non-proprietary are not synonyms. Machine-readable is a separate test from both. A verification system can clear one and fail the others. Compliance requires all three.
The Commission's 2025-2030 ESPR Working Plan, adopted on April 15, 2025, sets the cadence for the delegated acts that will bind these requirements to specific product groups. Iron and steel delegated acts are scheduled for 2026. Textiles, apparel, tyres, and aluminium follow in 2027. Furniture in 2028. Mattresses in 2029. The first mandatory compliance deadline arrives sooner: under the EU Battery Regulation 2023/1542, batteries become subject to passport requirements in February 2027. The central DPP registry that operationalizes the architecture launches July 19, 2026.
Open
In EU regulatory practice, "open" means built on publicly available, internationally recognized standards. The Commission has signaled that W3C decentralized identifiers, W3C verifiable credentials, GS1 product identifiers, and JSON-LD structured data are the technical primitives most closely aligned with the ESPR's open-standards mandate. The European Interoperability Framework provides the underlying definition of "open standard" that the regulation draws on.
A proprietary internal API powering a public verification page does not satisfy "open." The requirement reaches into the architecture underneath. Open standards have to be present where the data flows, including the layers a user never sees.
Non-proprietary
"Non-proprietary" is a replicability test. The regulation's technical guidance specifies operation "without dependence on any commercial technology provider." In practice, this means a third party with no prior business relationship to the certification body must be able to replicate verification access using publicly documented standards alone.
A platform that requires a vendor-specific SDK, a paid API tier, or a private contract to verify a certificate fails the replicability test. The certification body's ownership of the platform is irrelevant to the test. What matters is whether an independent party could rebuild access using nothing the certification body controls. The CIRPASS project, the EU-funded preparatory work for cross-sector DPP infrastructure, is built on exactly this principle.
Machine-readable
"Machine-readable" is the requirement most often confused with "online." The ESPR specifies data that is "structured and searchable," meaning formats consumable by software without human translation.
A human-readable verification page that returns rendered HTML with the words "Status: Valid" satisfies neither requirement. Practical formats that satisfy machine-readable include JSON, JSON-LD, XML, and verifiable-credentials payloads conforming to the W3C specification. The test is whether a regulator's compliance-monitoring software, an auditor's database tool, or a third-party verification service can retrieve and parse certificate status programmatically. If retrieval requires scraping a webpage or interpreting visual layout, the requirement is not met.
The Four-Question Architectural Test
A compliance team running an ESPR-readiness audit can clear the requirement using four questions:
- Can a third party with no prior relationship to the certification body retrieve verification status programmatically?
- Is the data format documented in a public specification based on internationally recognized open standards?
- Is the access path discoverable without contacting the certification body or its platform operator?
- Could multiple independent clients implement verification against the same architecture using only public documentation?
If the answer to all four is yes, the architecture meets the standard. If any answer is no, it does not. Across the certification industry, compliance teams typically run readiness audits at the user-experience layer. The four-question test surfaces what those audits miss, because the regulatory boundary lives at the architecture.
What compliance actually looks like
The architectural primitives that satisfy the standard are public and documented. W3C verifiable credentials carry the certificate payload. W3C decentralized identifiers tie the credential to the issuing body. JSON-LD provides the structured data format. Well-known URIs make the verification endpoint discoverable. The central DPP registry, launching July 19, 2026, will provide the discovery layer at union scale.
The operational question for certification bodies is implementation. The simplest path is neutral verification infrastructure that sits above existing certification platforms, exposing the required architecture without forcing a system migration. IntegraLayer was built to fill that role: a neutral certificate-layer endpoint that satisfies all three requirements while leaving the certification body's authority, branding, and program intact.
Closer
The first delegated acts under the ESPR will bind in 2026. The central registry launches in July of the same year. The compliance window is measured in months. The misread is correctable. The architecture under the user interface is where the work happens.