As the EU's Digital Product Passport regime moves toward its central registry launch on July 19, 2026, EU Regulation 2024/1781 binds five architectural requirements on every certification verification system referenced in a DPP. Open and non-proprietary. Machine-readable. Real-time. Independently verifiable. Persistent and durable for the lifetime of the product.
Two of these requirements govern the format of the data. Three govern the behavior of the verification path. Each binds independently. Most existing systems clear one or two. Compliance requires all five.
What the regulation says
Article 9 of the Ecodesign for Sustainable Products Regulation (the ESPR), with related provisions in Articles 10 and 11, sets the architectural requirements for the verification path referenced in any Digital Product Passport.
Two govern the data format. The standards must be "open, non-proprietary international standards." The output must be "machine-readable, searchable and structured."
Three govern the behavior of the verification path. The data must be "accurate, complete and up to date." Ecodesign requirements must be "verifiable" through public, Commission-identified means. The passport must remain accessible "even in the event of insolvency or if the responsible party ceases operations within the EU," for at least the typical lifetime of the product plus ten years.
A verification system can clear two of these and fail three. Compliance requires all five.
The Commission's 2025-2030 ESPR Working Plan, adopted on April 15, 2025, sets the cadence for the delegated acts that 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. 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 launches July 19, 2026.
Open and non-proprietary
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" the regulation draws on.
"Non-proprietary" is a replicability test. The regulation's technical guidance specifies operation "without dependence on any commercial technology provider." 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.
Together, these two requirements test the architecture beneath the user interface. A proprietary internal API powering a public verification page does not satisfy them. Open standards have to be present where the data flows, including the layers a user never sees.
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.
Real-time
Article 10 specifies that DPP data must be "accurate, complete and up to date." For certification verification, the verification path must reflect the certificate's current status at the moment of the check. A static record showing a status from the date of issuance does not satisfy the requirement once the certificate has been updated, suspended, or revoked.
The practical implication for certification bodies: any change in a certificate's status, including revocation, expiration, scope change, or suspension pending review, must propagate to the verification path within an interval short enough that a downstream user querying the path receives the current state. The regulation does not specify a maximum latency. The operational floor is the time it takes for a regulator to act in error against a stale "valid" status. Most existing certification portals update on batch cycles measured in days or weeks. The ESPR moves the floor.
Independently verifiable
The ESPR requires ecodesign requirements to be "verifiable" through means the Commission identifies, including direct checks of the product or technical documentation. The architectural implication: a third party with no relationship to the certification body must be able to verify a certificate's status through public documentation and standards alone, without needing the certification body to confirm or assist.
The practical test is the disappearance check. If the certification body's customer service team, sales contacts, and account managers were unavailable, could a regulator still verify a certificate against the public verification path? The verification must hold without human intervention from the issuing organization.
Persistent and durable
Article 11 requires the DPP to "remain accessible" for at least the typical lifetime of the product plus an additional period the Commission sets through delegated acts. EU guidance currently anchors that period at five to ten years post-product-placement, with the regulation explicit that accessibility must continue "even in the event of insolvency or if the responsible party ceases operations within the EU."
For certification verification specifically, the verification path cannot collapse if the certification body restructures, changes vendor, or ceases operations. The verification record must persist independently of any single commercial entity's continued existence, including the certification body itself. This is the requirement that most clearly forces neutral, independently-hosted infrastructure into the architecture.
The Five-Question Architectural Test
A compliance team running an ESPR-readiness audit can clear the requirements using five questions:
- Can a third party with no prior relationship to the certification body retrieve verification status programmatically, using only publicly documented standards?
- Is the data format machine-readable and structured (JSON, JSON-LD, XML, or W3C verifiable-credentials), addressable through a discoverable endpoint?
- Does the verification path reflect the certificate's current status in real time, including revocation, expiration, and scope change?
- Can the verification be completed without any contact, confirmation, or assistance from the certification body or its platform operator?
- Will the verification path remain accessible for the lifetime of the product plus the regulatory minimum period, even if the certification body or its platform operator ceases operations?
If the answer to all five 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 five-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. Real-time status propagation is handled through revocation registries and timestamped records. Persistence is handled through neutral, independently-hosted infrastructure that does not depend on any single commercial entity's continued existence. 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 five 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.