May 28, 2026
Introduction
The EU Digital Product Passport (DPP) is moving from policy discussion into operational preparation. For manufacturers, suppliers, brands, importers, and exporters, DPP is not simply a QR-code product page. It is a compliance workflow for product data, supplier evidence, declarations, access rules, verification records, and traceable responsibility.
Imagine a battery or textile supplier being asked by an EU customer to prepare for DPP requirements. The first question is not what the webpage should look like. The real questions are: Which fields are required? Where does each data point come from? Which supplier document supports it? Who is authorised to confirm it? Is the declaration signed? Can later versions be traced? Can the company prove the source of the data if a customer, platform, TIC body, or authority asks?
This guide explains DPP in the order most cross-border teams need it: what DPP is, why the 2026-2027 window matters, what data and evidence companies should prepare, where e-signatures, e-seals, timestamps, and proof of registration appear in the DPP Registry draft, and how companies can design a practical supplier declaration and evidence workflow now.
DPP Is Not a QR Code
The European Commission describes the Digital Product Passport under the Ecodesign for Sustainable Products Regulation as digital product identity information that supports sustainability, circularity, repair, recycling, and legal compliance. A QR code, NFC tag, or RFID chip can provide access to DPP data, but the data carrier is not the passport itself.
In practice, a DPP has at least four layers.
| Layer | What companies need to understand | Typical examples |
|---|---|---|
| Product data | The structured information included in or linked to the passport | Product identifier, model, batch, material composition, repair information, recycling information, compliance status |
| Supporting evidence | Documents proving where the data came from | Supplier declarations, test reports, declarations of conformity, certificates, LCA/PCF documents, internal approvals |
| Access rules | Who can view which information | Consumer-facing data, authority access, repairer access, commercially sensitive information |
| Traceability records | Who submitted, confirmed, changed, or approved the information | Signing records, e-seals, timestamps, hashes, audit logs, version history |
The fourth layer is easy to underestimate. A DPP platform may host the passport data, but the company still needs to prove that critical information was sourced, reviewed, authorised, and updated in a controlled way.
Why 2026 and 2027 Matter
The policy direction is clear, while detailed product rules will continue to arrive through delegated acts, implementing rules, standards, and technical specifications. Companies should not wait until every detail is final before they start preparing supplier data and evidence workflows.
| Timing | Regulatory meaning | What companies should do |
|---|---|---|
| 18 July 2024 | ESPR entered into force | Treat DPP as part of EU product compliance, supply-chain compliance, and data governance |
| April 2025 | ESPR and Energy Labelling Working Plan 2025-2030 was adopted and published | Track priority product groups and the delegated-act pipeline |
| 2026 | Registry design, product-group rules, data models, and system interfaces become more concrete | Map product scope, data sources, supplier documents, signer authority, and evidence retention |
| 18 February 2027 | Battery passport milestone under the EU Battery Regulation | Battery, EV battery, industrial battery, and battery supply-chain businesses should move first |
| 2026-2030 | More product groups are expected to move through ESPR implementation | Track textiles, tyres, furniture, metals, electronics, and other priority sectors |
Batteries are the clearest early case. Textiles are also important for Asian supply chains because data often sits across brands, garment factories, fabric mills, dyeing houses, material suppliers, and trading companies. In both sectors, supplier declarations and evidence versioning can become a bottleneck before the final platform decision is made.
Who Should Prepare First
Not every company needs to buy a full DPP platform immediately. The following teams should start with a DPP readiness check.
| Company type | Trigger signal | First action |
|---|---|---|
| EU-market manufacturer or exporter | EU customers begin asking for DPP, material origin, carbon footprint, repair, or recycling information | Map EU-bound SKUs, models, batches, and supplier data sources |
| Supplier | Brands request material declarations, compliance declarations, test reports, or sustainability data | Prepare signed, versioned, traceable supplier declaration templates |
| EU brand or importer | The company must ensure product information is accurate and available for products placed on the EU market | Separate data confirmed internally from data sourced from suppliers or third parties |
| TIC or testing body | Customers ask for DPP readiness, evidence packs, or supplier data validation | Connect testing, certification, and audit outputs to reusable evidence packs |
| DPP platform or consulting firm | Clients lack fields, documents, and supplier evidence before platform implementation | Add evidence readiness and signing records before or during implementation |
The first paying customers are unlikely to be every manufacturer. They are more likely to be companies already facing EU customer pressure, companies with ESG or compliance work but scattered evidence, and teams that have selected a DPP platform but still lack supplier data and proof documents.
What Data and Evidence Companies Need
For practical work, separate the DPP field matrix from the evidence pack. The field matrix defines what data may be required. The evidence pack shows which file, declaration, report, approval, or signed record supports each field.
| DPP data category | Possible data | Evidence to retain |
|---|---|---|
| Product identity | GTIN, SKU, model, batch, serial number, manufacturer information | Product master-data approval, model/batch mapping rules |
| Material composition | Material type, weight, recycled content, substances of concern | Supplier material declaration, BOM, test report, raw-material certificate |
| Environmental data | Carbon footprint, LCA, energy use, water use, recycling rate | LCA/PCF report, calculation method, third-party verification where applicable |
| Compliance data | CE, DoC, REACH, RoHS, Battery Regulation, Toy Safety, sector rules | Compliance declaration, test report, certificate, internal review record |
| Supply-chain data | Supplier, factory, origin, batch, logistics information | Supplier declaration, purchase record, factory qualification, batch document |
| Use and repair | Repair instructions, spare parts, durability, care information | Product manual, repair document, quality validation record |
| Circularity and recycling | Disassembly, reuse, waste treatment, recycling information | Recycling instruction, disassembly guide, recycler information |
| Trust evidence | Who submitted, who confirmed, when it was confirmed, whether it changed | Signing record, e-seal record, timestamp, hash, audit log |
Companies should not only ask whether a DPP platform can display the data. They should ask whether they can prove the source, authority, integrity, and version of each critical data point.
Where E-Signatures, E-Seals, and Timestamps Appear in the DPP Registry Draft
The clearest current DPP document related to electronic signatures and seals is the DPP Registry Draft Implementing Regulation, Ares(2026)4424976. It is still a draft and should not be treated as final law.
The draft does not simply say that every DPP field, JSON payload, or supporting file uploaded by a company must be signed. Its more relevant direction is that the registry process introduces identity checks, qualified electronic seals, qualified electronic signatures, qualified timestamps, proof of registration, semantic validation, and automated checks.
The registry flow can be understood like this.
This section also lists several issues that need attention.
| Question | Current reading |
|---|---|
| Who issues proof of registration? | Under the draft logic, it is generated on the Registry / Commission system side, not created as an ordinary company document. |
| Who is responsible for the qualified eSeal or timestamp on proof of registration? | The focus is the government registry system or its designated mechanism for proving authenticity and timing of the registration proof. |
| Must companies sign every DPP data upload? | The draft does not clearly state that every field, JSON payload, or supporting file uploaded by a company must be signed. The exact signed object still depends on future Registry APIs, implementing details, and semantic repository specifications. |
| What can companies prepare now? | Supplier declarations, authority confirmations, Evidence Pack Manifests, version hashes, timestamps, approval records, and audit logs. |
| Why does automated verification matter? | Future registries, platforms, TIC bodies, or customers may check certificates, seals, timestamps, hashes, data formats, and consistency automatically rather than reviewing files manually. |
This means companies should avoid two mistakes. One is assuming that all DPP-related documents simply need to be signed once. The other is assuming that because the registry issues proof of registration, the company does not need enterprise-side evidence. A better design separates government registration proof, DPP platform data, enterprise evidence packs, and supplier declarations.
How to Design Enterprise-Side Signed Evidence
The enterprise-side workflow should start with supplier and internal accountability. When DPP data comes from external suppliers, the manufacturer, brand, or importer needs to know who provided the data, who signed for the supplier, which model or batch the declaration covers, which file version supports it, and how later changes are handled.
| Record type | What to lock down | Why it matters |
|---|---|---|
| Supplier declaration | Supplier name, signer identity, authority scope, declared content, applicable model or batch | Proves data origin and supplier accountability |
| Authority confirmation | Company representative, authorised representative, signing authority, business scope | Prevents uncertainty over who can confirm DPP-related information |
| Evidence Pack Manifest | Field list, evidence file list, version number, hash, update time | Turns scattered files into a traceable evidence package |
| Data change record | Changed field, reason, approver, timestamp, reference to old version | Explains later updates to DPP data |
| Third-party verification result | TIC, testing body, LCA/PCF provider, or platform feedback | Supports customer review, platform onboarding, and regulatory inquiry |
The signing level should not be one-size-fits-all. Lightweight e-signing and audit records may be enough for routine internal confirmations. Supplier accountability statements, key compliance declarations, cross-border authority documents, and important version confirmations may require stronger identity verification, certificate-backed digital signatures, e-seals, or timestamps. Where a customer, platform, or regulation explicitly requires a qualified electronic seal or qualified electronic signature, companies should use a qualified trust service provider under the eIDAS Regulation or an appropriate partner route.
A Practical DPP Readiness Checklist
Companies can start with evidence readiness before committing to heavy DPP software.
- Confirm product scope: EU-bound SKUs, models, batches, and product lines.
- Check regulatory triggers: battery passport, ESPR priority product group, EU customer request, or platform requirement.
- Build a field matrix: product identity, material, environmental, compliance, supply-chain, repair, and recycling data.
- Build an evidence matrix: source file, responsible party, verification status, and missing evidence for each field.
- Create supplier declaration templates: supplier, signer, authority, declared content, model or batch coverage.
- Define version rules: every field update, evidence update, and declaration update should be traceable.
- Define signing and sealing rules: routine confirmation, company declaration, critical compliance confirmation, high-risk file, and customer-mandated file should not be treated the same.
- Select partners: DPP platform for hosting and access, TIC for testing and verification, LCA tools for carbon and lifecycle data, trust services for signatures, e-seals, timestamps, and verification.
After this preparation, platform selection becomes easier. Without it, teams often discover during implementation that fields have no owner, supplier documents are missing, file versions are unclear, and signing authority cannot be proven.
Turning DPP Preparation Into a Signing and Evidence Workflow
For a cross-border signing platform such as Nota Sign, the practical DPP entry point is the enterprise evidence workflow. It should not be positioned as a replacement for DPP platforms, TIC bodies, or the EU Registry.
Nota Sign electronic signature supports contract, declaration, authority, and high-trust signing scenarios. Nota Sign Identify supports identity verification. The Nota Sign Trust Center explains Nota Sign's approach to legal frameworks, security, and trusted signing. In DPP preparation, the natural application areas are supplier declarations, authority confirmations, Evidence Pack Manifests, file version confirmations, audit trails, and workflow integration with partner systems.
The division of work should stay clear. DPP platforms manage passport creation, hosting, access control, and display. TIC and testing bodies manage testing, certification, audit, and verification. The EU Registry manages the registration system and proof of registration. Enterprise signing and evidence workflows help companies organise source documents, declarations, authorisations, versions, and audit records before and during partner delivery.
| DPP preparation task | Best-fit owner | Notes |
|---|---|---|
| DPP hosting and display | DPP platform | Passport pages, access permissions, data-carrier linkage |
| Testing, certification, verification | TIC or testing body | Product compliance, material evidence, carbon, supplier audits |
| LCA / PCF calculation | LCA tool or specialist provider | Environmental calculation should not be replaced by signing software |
| Registry proof of registration | EU Registry / government system | Under the draft, registration proof is a system-side mechanism |
| Supplier declaration and authority signing | Enterprise signing workflow | Proves source, signer identity, authority, and version |
| Evidence Pack retention | Company, consultant, platform, and signing workflow together | Organises fields, files, signing status, hashes, timestamps, and audit logs |
For many exporters and suppliers, the most realistic first step is not a full DPP platform rollout. It is a DPP readiness check, a supplier declaration process, and a structured evidence pack that can later connect to the selected platform, TIC partner, or consulting team.
Next Step
If your company has already received DPP-related requests from EU customers, start with one product line or one battery/textile sample. Build the field matrix, supplier declaration template, and Evidence Pack Manifest first. Then evaluate how DPP platforms, TIC verification, LCA tools, and signing or e-seal workflows should work together.
Teams that need to manage cross-border supplier declarations, authority confirmations, evidence pack signing, and audit trails can contact Nota Sign to review the right signed-evidence workflow.
