DPP Series | Part 2: DPP Deep Dive: How Companies Use It, Plan Usage, and Integrate

The Digital Product Passport (DPP) is often introduced as a product information requirement. For companies preparing to sell regulated products in the European Union, that description is incomplete. A workable DPP programme must connect governed product data with product identifiers, accountable organisations, access controls, verifiable submissions and the systems that maintain the record over time.

This second article in the eSign.AI DPP series moves from regulatory awareness to operating design. It explains where companies may use a DPP, how to decide which teams and systems should own each obligation, and where electronic signatures, electronic seals and evidence retention may support a trustworthy process.

Start with the business event, not the QR code

A QR code or another data carrier is the visible entry point to a passport, but it is not the passport operating model. The first design question is what business event creates or changes the product record. Depending on the product and applicable legislation, that event could be placing a product on the EU market, registering an economic operator, issuing a conformity document, updating repair information or recording a lifecycle event.

Each event needs an accountable owner. Product teams may own technical attributes, compliance teams may approve regulated statements, operations teams may manage identifiers, and IT teams may connect source systems. When nobody owns the event, the passport can become a static publishing exercise instead of a maintained compliance record.

The European Commission's ESPR working plan helps companies identify priority product groups, but product-specific delegated acts will determine the detailed data, timing and operating obligations.

Map the four layers of DPP readiness

Companies can structure preparation around four connected layers:

1. Product data: identify required attributes, sources, data owners, update rules and quality controls.
2. Product identity: define the unique product, batch or item identifier and connect it to the correct physical data carrier.
3. Organisation and authority: establish which legal entity submits information, which people or systems may act for it, and how those rights are verified.
4. Trust and continuity: preserve evidence of who approved or submitted information, protect integrity, control access and keep records available for the required period.

This model prevents a common planning mistake: buying a front-end passport tool before confirming whether the company can reliably produce, approve and maintain the underlying information.

Scenario 1: onboarding an economic operator

Before an organisation can submit regulated data, the relevant system may need to establish its legal identity and the authority of the person or system acting for it. The exact path depends on the governing legislation and platform design. It may involve an electronic identification method, an electronic attestation, documentary evidence or a qualified electronic seal backed by a qualified certificate.

The important distinction is between identity and permission. Proving that a company exists does not automatically prove that a specific employee, service account or external representative may submit data for that company. A robust onboarding process records both the organisation identity and the delegation or role that authorises an action.

Commission Implementing Regulation (EU) 2026/1778 provides a concrete example for the EU DPP registry. It sets out identity and access arrangements for economic operators and other actors, including high-assurance paths for natural persons and qualified electronic seals or electronic attestations for legal persons. The verified economic operator remains responsible for the data it submits.

Scenario 2: approving and submitting DPP information

Product information usually originates in several systems: product lifecycle management, enterprise resource planning, manufacturing execution, quality management, supplier portals and document repositories. A DPP workflow should not ask users to manually recreate that information in another interface if an authoritative source already exists.

Instead, the operating design can assemble the required dataset, validate mandatory fields, route exceptions to the correct owner and capture approval before submission. Where a signature or seal is required, the workflow should invoke the appropriate trust service without confusing a business approval with a legally qualified signature or seal.

eSign.AI can support the workflow layer by connecting source systems, routing approval tasks, applying the required signing or sealing path and recording the resulting transaction evidence. Through its Registration Authority service and integration with ANF AC, eSign.AI can provide the QSeal application and issuance path as part of the customer solution rather than leaving the customer to coordinate a separate overseas provider.

Scenario 3: preserving verifiability over time

DPP obligations are not limited to the moment of publication. Product information may need to remain available, intelligible and trustworthy through long product lifecycles, ownership changes and system migrations. Companies should therefore plan for durable evidence rather than treating a successful API response as the end of the process.

Evidence design can include the submitted dataset or its canonical representation, timestamps, signature or seal validation material, signer or operator context, authorization records, delivery receipts, version history and system logs. Retention periods and validation methods must be matched to the applicable product rules and records policy.

The EU framework gives qualified electronic seals a legal presumption of data integrity and correctness of origin, while qualified timestamps can support proof that data existed at a particular time. Only services listed as qualified in an EU national trusted list have qualified status.

Planning note: this Word-source illustration presents a sector and timing roadmap for discussion. It is not a legal schedule for every depicted product. Binding scope, identity paths, proof formats, data requirements and application dates are established by the relevant EU product legislation, product-specific delegated acts and final system design.

Five planning questions for each product line

1. Is the product in scope?

Build a product-to-rule register that identifies the relevant EU legislation, current status, expected delegated act and accountable legal entity. Do not assume that a corporate-level DPP programme means every product follows the same timetable.

2. Who owns each required data element?

Assign a source system and business owner to every mandatory attribute. If a value comes from a supplier, define validation, escalation and change-control rules rather than accepting unverified files by email.

3. How is the product uniquely identified?

Decide whether the rule operates at model, batch or item level. Confirm how identifiers are generated, how duplicates are prevented, and how the physical data carrier remains connected to the correct digital record.

4. Who may approve and submit?

Document the legal entity, responsible role, delegation model and machine credentials involved. Separate internal approval from external submission and from any qualified trust service required by law.

5. What evidence must survive a system change?

Define the evidence package before implementation. The answer determines storage architecture, export formats, validation dependencies and migration controls.

An integration blueprint for practical implementation

A practical architecture normally begins with source systems rather than a new standalone database. A data service retrieves approved product attributes, a workflow service validates completeness and routes exceptions, an identity and authorization layer verifies the actor, and an API layer submits the correct payload to the relevant registry or passport service.

The evidence layer should capture each material event without storing unnecessary personal data. It should also support retrieval by product, transaction, legal entity and time period so compliance teams can respond to audits or disputes efficiently.

Implementation is usually safer in phases. Select one product family, map its data and legal requirements, test the complete workflow with representative users, and then expand. This creates reusable controls while allowing product-specific differences to remain visible.

Two signing tracks in the eSign.AI DPP solution

The first track is economic-operator verification. eSign.AI supports QSeal application, identity-verification coordination and organisation-data matching through its Registration Authority capability and ANF AC integration. This is particularly relevant to non-EU manufacturers that need an EU trusted-list qualified electronic seal for a registry-facing identity process.

The second track is the repeated product-data workflow. eSign.AI supports PAdES for PDF documents and XAdES or JAdES long-term signature profiles for XML and JSON records, including qualified timestamps and evidence retention. The exact format and assurance level should follow the product-specific rule, registry interface and customer's legal assessment; not every DPP event uses the same signature.

For higher volumes, customers can connect through SDK or API rather than signing each record manually. Where the receiving process supports batch submission, one operation can package multiple DPP records while preserving record-level identifiers and evidence. eSign.AI also supports SaaS workflows for teams that need an operational interface before completing system integration.

Where eSign.AI fits

eSign.AI supports electronic signature and digital signature workflows, approval orchestration, API integration and evidence retention. For a DPP programme, these capabilities can help connect business systems to signing or sealing steps, capture operator events and preserve a traceable record of the workflow.

The eSign.AI delivery scope can include QSeal application and issuance support, registry onboarding guidance, PAdES/XAdES/JAdES signing, qualified timestamps, SaaS and API integration, and long-term evidence. Product-data governance remains a customer responsibility, while eSign.AI provides the trust and execution layer needed to move the right data through the right signing path and retain evidence for later verification.

Continue the DPP series

Read Part 1: Why Chinese Exporters Need to Prepare for the EU Digital Product Passport for the regulatory and sector context.

Part 2: DPP Deep Dive: How Companies Use It, Plan Usage, and Integrate (this article)

Continue to Part 3: From eCoC to QSeal: How eSign.AI Supports DPP Readiness for a closer look at trusted workflows, QSeal integration and eSign.AI's role.