# Who Checks DPP Information? Registry, Conformity and Market Surveillance

Source: https://activatedigital.ai/knowledge/evidence/who-checks-dpp-information
Last verified: 3 September 2026
Summary: Understand who checks Digital Product Passport information and the difference between Registry validation, evidence, conformity assessment and market surveillance.

## In 60 seconds

There is no single universal “DPP verifier”. Different checks answer different questions.

- Commission Implementing Regulation (EU) 2026/1778 Article 8 sets the Registry's automated checks. Passing them is not proof of compliance.
- Article 9 proof of registration evidences only that the registration obligation for that DPP has been fulfilled.
- Article 19 keeps the verified economic operator responsible for the accuracy and completeness of what it submits.
- There is no universal requirement for third-party certification or conformity assessment of all DPP information.
- ESPR Article 41 gives a presumption of conformity with Articles 10 and 11 to DPPs meeting harmonised standards published in the Official Journal, within those standards' coverage.
The EU Registry performs defined registration checks. Proof of registration shows that the registration obligation for that passport has been fulfilled. Evidence supports the facts you publish. Product-specific law can require a conformity-assessment procedure. Market-surveillance authorities check compliance under the applicable law. A successful Registry submission is not certification of every product claim in the passport.

## The four checks people keep calling “verification”

| Layer | Question it answers | What it does not prove |
|---|---|---|
| **Registry checks** | Can this DPP registration be accepted against the Registry’s defined checks? | That every product fact is substantively true or that the product is compliant in every respect |
| **Evidence / substantiation** | What supports this product fact and does the evidence cover this product and scope? | That a formal conformity procedure has been completed unless that evidence is part of one |
| **Conformity assessment** | Has the product’s compliance with applicable ecodesign requirements been assessed using the procedure specified for that product rule? | That every future DPP regime uses the same procedure or a third party |
| **Market surveillance** | Does the product/economic operator comply with applicable Union rules, and is corrective action needed? | That a vendor, Registry or QR code has taken over the authority’s role |

Keep these four states separate in your system.

## 1. The Registry checks the registration, not the whole product

Commission Implementing Regulation (EU) 2026/1778 sets out the DPP Registry’s operational rules. Article 8 describes automated checks around matters including semantic conformity, coherence of mandatory Registry data where relevant, the required model/batch/item granularity, commodity-code validity where relevant and the backup-provider link where relevant.

Those are meaningful checks, but they don't prove that a recycled-content percentage, carbon value, test result or repairability claim is substantively correct.

The Regulation itself draws that boundary. Its Registry framework says successful automated checks should not be treated as proof of compliance with the requirements applicable to the product.

If your internal system has a status called `verified`, split it. Useful states are more specific:

- `registry_accepted`
- `evidence_supported`
- `conformity_assessed`
- `market_surveillance_checked`
Those states are not interchangeable.

For the operational registration workflow, use the Registry pages in our Knowledge library.

## 2. Proof of registration proves registration

Article 9 of the Registry Implementing Regulation gives proof of registration a narrow purpose: it serves as evidence that the registration obligation for that DPP has been fulfilled.

That is useful commercial evidence. It can show a buyer, internal audit team or other third party that the required registration event happened.

It should not be renamed “DPP compliance certificate”. It is not a certificate that every field is correct and it is not a substitute for product evidence or a required conformity-assessment procedure.

The [proof of registration page](https://activatedigital.ai/knowledge/evidence/proof-of-registration) owns the proof document itself. This page explains where that proof sits in the wider checking stack.

## 3. The economic operator still owns the accuracy of what it submits

Registry checks do not transfer responsibility to the Commission. Article 19 of the Registry Implementing Regulation makes the verified economic operator responsible for the accuracy and completeness of information submitted at registration and for keeping Registry information accurate, complete and up to date.

That is a useful control for supplier and vendor arrangements. A third party may perform registration actions where the law allows it, but moving the keystrokes does not automatically move the operator’s responsibility. For what follows when the information is wrong, see [DPP fines and enforcement](https://activatedigital.ai/knowledge/regulation/dpp-non-compliance).

The same principle should shape product evidence. If a supplier document supports a field, keep the supplier document. If a lab report is the source, keep the lab report and its scope. Do not keep only the final number. To see where one product stands, [check what your own data supports](https://activatedigital.ai/dpp-readiness-checker).

For that layer, see [certificates, declarations and test reports](https://activatedigital.ai/knowledge/evidence/documents) and [what a passport field can and cannot prove](https://activatedigital.ai/knowledge/evidence/claims-and-substantiation).

## 4. Conformity assessment is product-specific

ESPR requires product delegated acts to specify the applicable conformity-assessment procedure for the ecodesign requirements concerned. The framework can use internal production control or other conformity-assessment modules depending on the product rule.

The Commission’s DPP FAQ says there is **no universal requirement** for third-party certification or conformity assessment of all DPP information. Future product rules may require third-party involvement for particular product groups or data points where the underlying rule justifies it.

That gives businesses two rules:

- do not promise “independently certified DPP data” unless you can say **what** was certified, **by whom**, **against which requirement** and **for which scope**; and
- do not assume every future DPP field will need a notified body or accredited third party.

## 5. Harmonised standards can support conformity, but only within their coverage

ESPR Article 41 gives harmonised standards a defined legal effect. DPPs that conform to harmonised standards whose references are published in the Official Journal can benefit from a presumption of conformity with Articles 10 and 11 **to the extent those requirements are covered by the standards**.

A harmonised standard can help establish conformity with covered technical requirements. It does not by itself decide which product group needs a DPP, what the product’s mandatory field set is or when a future delegated act applies.

The detailed standards position belongs on the existing standards pages, not here.

## 6. Market surveillance is a different control again

Market-surveillance authorities enforce applicable product rules. ESPR gives authorities powers and provides for corrective action where products or economic operators do not meet applicable requirements. The DPP can make information and documentation easier for authorities to reach, but it does not replace market surveillance with an automated “pass/fail” service.

When building customer-facing status labels, avoid a single green badge called `EU verified` unless the exact basis is displayed beside it.

A more honest design says what happened:

- **Registered in the EU DPP Registry**
- **Source evidence recorded**
- **Conformity assessment completed under [instrument/procedure]**
- **Market-surveillance outcome [if one exists and can lawfully be stated]**
Each is useful. None should impersonate the others.

## Machine verification is another check, not the final verdict

There is now another layer to add to the checking model: **machine verification of the digital record**.

A verifiable credential can let software test whether its cryptographic proof is valid, whether the issuer/controller information resolves as expected and whether the credential is current under its status mechanism. Those checks can make a record much harder to alter silently and can make provenance easier to automate.

They do not answer every question on this page. A valid credential can still contain a weak, mistaken or unsupported claim. The receiving system still has to decide whether the issuer is authoritative for that claim, whether the evidence is sufficient and whether it applies to the product and granularity being checked.

The same boundary applies to the EU DPP Registry. The Registry can run specified automated technical, semantic, coherence and granularity checks. Passing those checks means the submission satisfied those controls. It is not a universal finding that every product claim is factually correct or that the product is substantively compliant with every applicable rule.

UNTP also describes graph validation, where software could evaluate relationships across linked credentials and evidence. That is useful direction, but it remains draft guidance rather than a finished production conformance or compliance-decision regime. Treat it as an emerging automation layer, not as the final verdict.

For the trust boundary behind that machine check, see [what a verifiable credential actually proves](https://activatedigital.ai/knowledge/evidence/verifiable-credentials). For the law-versus-protocol distinction, see [EU DPP vs UNTP DPP](https://activatedigital.ai/knowledge/regulation/eu-dpp-vs-untp).

## Technical conformance is not the same as substantive verification

A live example comes from product-carbon data exchange. PACT's technical conformance process tests whether systems implement the expected exchange behaviour. Its current technical model also represents verification information separately from protocol conformance.

That distinction is deliberate. A system can exchange a product carbon footprint correctly according to the technical protocol without the protocol itself certifying that the footprint calculation is correct, complete or independently assured.

So “conformant”, “cryptographically verified” and “substantively verified” should remain separate states. The first can describe software behaviour. The second can describe the digital record. The third depends on the method, evidence and assurance process behind the claim.

For the detailed product-carbon example, see [how companies exchange Product Carbon Footprint data using PACT, versioning and verification](https://activatedigital.ai/knowledge/product-data/product-carbon-footprint-exchange).

## A worked example: one recycled-content field

Imagine a future product rule requires a recycled-content value.

**Evidence layer:** supplier declarations, chain-of-custody records, calculation method or test evidence support the value. **Conformity layer:** the applicable product act determines the assessment procedure for the requirement. **Registry layer:** the Registry checks the data that the registration rules require and returns a registration identifier after successful verification. **Proof layer:** the operator can generate proof that the DPP registration obligation was fulfilled. **Surveillance layer:** an authority may later test the product, ask for documentation or otherwise assess compliance.

Calling all five “verification” hides the decision a business needs to make.

## What is settled

- Registry registration now has defined operational checks under Implementing Regulation 2026/1778.
- Proof of registration has a defined, narrow evidential purpose.
- The verified economic operator remains responsible for accuracy and completeness of submitted registration information.
- ESPR product delegated acts specify the conformity-assessment procedure for the requirements they create.
- There is no universal current rule requiring third-party certification of all DPP information.

## What remains product-specific

- which conformity-assessment module a future product act will require;
- whether a third party is required for a particular requirement or data point;
- what technical standards create presumption of conformity once references are published and for what coverage; and
- what evidence is sufficient for a specific factual claim in a specific regime.

## What a business can prepare now

**Build separate controls for:**

- source evidence;
- data approval;
- Registry submission;
- proof of registration;
- conformity-assessment records; and
- authority requests or surveillance outcomes.
**Keep provenance:** who supplied a value, what document supported it, its scope, effective date and review status.

**Avoid:**

- “EU verified” as a generic product badge;
- “registration = compliance” logic;
- deleting source evidence after the value is copied into a passport; and
- assuming every field needs third-party certification.

## What would change this page

Re-verify when:

- the Registry verification rules are amended;
- a product delegated act specifies a new conformity-assessment approach;
- Commission FAQ question 25 changes;
- new market-surveillance implementation materially changes the DPP checking model; or
- new harmonised-standard references change the scope of presumption of conformity.

## Keep exploring

The questions this page usually raises next.

- [Another angleThe question this one usually raises nextIf DPP-related data can identify a person, where does GDPR enter the picture?→](https://activatedigital.ai/knowledge/passport/personal-data-and-gdpr)

## Sources and legal basis

- **Commission Implementing Regulation (EU) 2026/1778**, especially Articles 8, 9 and 19.
[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1778](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1778)

- **Regulation (EU) 2024/1781 (ESPR)**, especially Articles 4, 9, 41 and the conformity/enforcement provisions.
[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1781](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1781)

- **European Commission DPP FAQ**, especially question 25.
[https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/explore-our-faqs_en](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/explore-our-faqs_en)