EU Digital Product Passport: requirements, timelines and business obligations

The European framework for digital product passports stems from the regulation on ecodesign for sustainable products (ESPR). The Regulation establishes common rules, but detailed requirements for specific product groups are set out in subsequent acts. Therefore, a business should not copy one checklist for every category.

The DPP is intended to support access to product information in an accurate, complete and up-to-date manner, taking account of the recipient and confidentiality. In practice, this means establishing an identifier, data scope, carrier and access rules before publication. Legal sources and verification dates must be visible in the internal process.

The article How the digital product passport works explains the mechanics of the record. Here, we focus on how to read EU requirements and plan obligations without treating uncertain information as law.

It is established that frameworks should be created in which product information can be made available electronically via an interoperable carrier. It is also established that access should correspond to the recipient's role: consumers, economic operators and supervisory authorities do not necessarily need to see the same data.

Not settled for every industry are, among other things, the exact fields, level of detail, method of linking information to the product, updating rules and application dates. These elements depend on delegated acts and further standardisation work. They should be marked as preparatory, rather than as final obligations.

An internal requirements map should have three columns: currently applicable, preparatory, and requiring legal assessment. This separation allows investment in identifiers and evidence without presenting the project as certification. Also read ESPR and timelines for textiles if you work with clothing.

Role matters. The manufacturer may create product information, the importer is responsible for specific obligations when placing a product on the market, and the distributor needs access to information relevant to its activities. A data supplier may not be the party responsible for the record as a whole. In the process, name the owner of each value and the person approving publication.

A company selling in several countries should check which requirements and languages arise from the target market. Localisation of the text does not change the legal scope, but it affects usability and accessibility. Do not translate the names of entities, identifiers, abbreviations or URLs; translate the explanations and interface.

DPP Grid enables tasks and evidence to be assigned to a product and supplier. This does not mean that the platform itself determines legal status. The decision remains with the entity placing the product on the market, together with its adviser and documentation.

Regulatory deadlines should always come from a current source. It is not enough to copy a date from a presentation, industry article or draft version. Keep the announcement date, verification date and status in the record: in force, planned, indicative, test or undetermined.

If a delegated act is planned, communicate this clearly. A brand may begin preparing to collect materials and evidence, but it should not present the field as a final requirement. An update to the source should trigger a review, rather than a silent change to all passports.

On a public website, it is helpful to include a brief explanation that the timetable may change. The link to official legal basis should lead to the article in the relevant language version, while official sources should remain direct links in the English version.

The greatest value comes from a catalogue of identifiers: model, variant, batch and item. Include materials, origin, facility, supplier, instructions, warnings, documents and the visibility policy. Each field needs an owner, source and date. This structure remains useful even if a specific requirement is subsequently changed.

Prepare export formats and an immutable version record. This makes it possible to change platform or connect the data to a future register without re-entering it manually. DPP Grid provides JSON, JSON-LD, PDF and resolver, but the brand is responsible for the content and the publication decision.

Do not start with the most impressive dashboard. Start with two or three products and check whether the supplier data, document and public value have a consistent scope. This will reveal missing roles and help build the appropriate retention policy.

A DPP should be readable by both people and machines. A clear webpage, JSON and JSON-LD may describe the same record, but they must follow the same visibility policy. Private data must not appear in hidden HTML, client-facing JSON or a public script.

The carrier should work without requiring an app. A QR code on packaging, a label or a document must lead to a persistent address, and changing the language should preserve the product and version. Check the contrast, code size, margin and decoding after printing.

Interoperability requirements do not mean that every integration is active. Public text should distinguish between a ready export, API, sandbox and a service requiring approval. The same applies to a future connection to the EU register.

Product regulations do not allow a general statement to be turned into evidence. Material, recycled content, environmental footprint or durability require a scope, method, unit, date and document. If the evidence is incomplete, publish a preparatory status or do not publish the value.

The team should separate product obligations from voluntary marketing claims. A DPP can store the source and review status, but it should not automatically assign an ‘environmentally friendly’ or ‘compliant’ label. Use language that says what was actually checked.

DPP Grid retains the history so that the decision can be reconstructed. If there is a conflict between a supplier and a test report, it is worth suspending publication of the field, asking for an explanation and recording the outcome, rather than choosing a value based on the confidence of the AI model.

The public passport should disclose the minimum needed by the consumer. Supplier data, private addresses, contracts, reviewer comments and private evidence should remain restricted. Permissions are part of the DPP design, not an addition after deployment.

Take care with secure files and links. Store the document in a scanned repository, assign it a hash, and show only a controlled name and status in the public record. The change history must be auditable, but it need not disclose personal details.

Security requirements depend on the role and the data. Implementation guide for businesses shows how to link an access policy to a practical approval process.

For each new act, list the product scope, entities, required information, access, medium, deadline and transitional provision. Also record what the act does not determine. This type of summary allows management to distinguish a decision from an assumption.

Compare the summary with the original. The title of an article or press release may shorten exceptions and conditions. A link to EUR-Lex and the Commission’s website should remain visible in the documentation, and the review date should be reset when the source changes.

Do not turn a deadline into an implementation schedule without an owner. Assign the task to the product, supplier, lawyer or data team, and define a completion criterion. In DPP Grid, you can show the status and next step, but this does not replace the company’s decision.

In the first 30 days, choose the category, owner, models and field dictionary. Map the sources and determine which data should be private. On days 31–60, collect documents, conduct a review and build a test resolver. On days 61–90, publish a small dataset, check scans, exports and questions from users.

Each week, mark statuses as applicable, preparatory or requiring assessment. Do not delete the previous decision. This trail is what makes it possible to explain whether the team was responding to new law or merely to a change in interpretation.

After 90 days, assess the cost of handling suppliers, the percentage of fields with evidence and publication performance. If the process is stable, extend it to another category. If not, fix the source or responsibility before increasing the number of products.

The European register is not an automatic repository of all information about every product. The scope of the data recorded depends on the specific legal act, category and role of the economic operator. In a DPP project, therefore, distinguish between data that must be made available to authorities and data that is meaningful to consumers or for your own supplier management.

Before integration, prepare a field table with four columns: legal source, value owner, recipient and status. If a field is described only in a draft or work plan, mark it as preparatory. Do not build an interface that presents a future capability as an active register feature.

It is also worth planning for changes in scope. When a new legal act appears, add a new version of the map instead of editing the historical decision. This makes it possible to explain why a given model had a different set of fields at the time of publication and who approved the change.

Batteries are a good example of why the DPP timetable is not uniform across all categories. Requirements for batteries are developing under a separate regime, with their own information on composition, capacity, the responsible entity and the life cycle. They must not be transferred directly to textiles, furniture or electronics.

A company can nevertheless use common process elements: a persistent identifier, the source of each value, access control, versioning and a public resolver. This shared layer shortens subsequent implementations, but product fields must remain dependent on the category and the legal act.

In practice, create a separate requirements dictionary for batteries and another for other products. Add the owner responsible for updates and the date of the next review. If the source does not yet settle a detail, show that uncertainty in the team’s work instead of filling the field with an approximation.

DPP requirements affect more than the legal department. Data must flow between design, procurement, production, logistics, sales and after-sales service. Before choosing a tool, map the chain of accountability: who creates the value, who confirms it, who can see it and who corrects it after a change.

A supplier should receive an actionable task, not a general request for “full compliance”. Specify the product, batch, format, supporting document, deadline and question channel. Recording responses and reminders is useful during an internal review, but it should not be disclosed publicly without a basis.

The brand needs a discrepancy procedure. If a supplier document differs from the catalogue, stop publication of the specific field, flag the conflict and appoint an owner for the decision. Such a pause is a better sign of maturity than a record filled with data that nobody can defend.

Dates published in Commission work plans, communications and industry materials have different weight. For each date, record its source, status type and verification date. Distinguish between a legal act in force, an adopted act with a transitional period, a planned step and an indicative announcement.

For each product, decide three things: what must be done now, what is worth preparing and what should not yet be presented as an obligation. The same company may have a different plan for two categories because their legal acts and timetables do not necessarily match.

When a deadline changes, retain the previous record and add an explanation. The history helps the team and advisers reconstruct the basis for the decision. Do not retrospectively alter public content so that it appears that earlier information had always been consistent with the later state of the law.

The board should be able to answer several straightforward questions: which products are covered by the initial scope, who is the responsible economic operator, which sources substantiate the data, which information is private, and how the brand will withdraw a version containing an error. The answers should identify people and decisions, not just tools.

Check whether the budget covers maintenance after publication: source updates, requests to suppliers, translations, consumer support, QR testing and backups. A DPP is an operational process, so the cost of the first import does not describe the entire undertaking.

Finally, establish a stop criterion. If evidence has expired, the resolver does not work or the role of an economic operator has changed, the appropriate person must be able to suspend a field or the entire version. A clear withdrawal mechanism is part of a credible DPP, not a project failure.

A DPP should be usable without disclosing personal data. In the public view, the brand, product, approved materials, origin at the required level and instructions for the next life will usually be sufficient. An employee's name, private address, reviewer's comment or a supplier's full document should remain outside the public view.

Before publication, map fields to audiences: consumer, partner, supplier, supervisory authority and internal operator. For each audience, define the purpose, basis for access and retention period. This map helps avoid situations in which a convenient JSON export accidentally contains private values.

Translation should not change the visibility policy. A localised label may be different, but the data scope remains the same. When ownership changes or a product is transferred, update permissions and retain the event rather than copying the data into a new, uncontrolled record.

Interoperability means being able to read and transfer data in an agreed format, not automatic recognition that a product meets the requirements. Establish field names, units, identifiers and the schema version. Always retain the source and indicate whether the value is approved.

An export in JSON, JSON-LD or PDF should lead to the same record and clearly describe its scope. If a partner needs an additional field, add a mapping or an extension version. Do not change the meaning of an existing field simply because another system uses a similar name.

Before integration, carry out a small exchange test: send one product, check diacritics, dates, units, the resolver link and the handling of missing values. Record the test result as technical evidence. Do not call it certification or approval by an authority if no such decision has been issued.

A lengthy legal act only becomes useful when it can be translated into tasks. For each requirement, list the field, source, owner, audience, evidence, review date and publication criterion. If a requirement does not yet have details, create an observation task rather than an empty field that creates a false impression of certainty.

Link tasks to a specific category and model. A single rule may apply only to some products or depend on the market. With this assignment, the team does not burden every catalogue with the same set of documents and can more easily explain differences between variants.

Finally, check the path from the task to the public text. The user should see the result, while the operator sees the source, decision and version. This separation makes it possible to communicate progress without creating promises that are not supported by legislation or product data.

Every claim about an obligation should point to a current official source. Record the title of the act, its number, the verification date and the passage on which the decision is based. Industry material may help with interpretation, but should not replace EUR-Lex, the Commission website or another appropriate official publication.

When the source is unclear, flag the question for further assessment. Do not change a preparatory status to a required one merely because the information is repeated in several articles. A well-documented ‘not yet determined’ status is more useful than certainty without a basis.

In DPP Grid, the source, date and decision can be linked to a specific field. This means that a later change to the act triggers a review of the relevant products, rather than a manual search through the entire catalogue. Keep the history so that the team knows what has changed since the previous publication.

The ESPR creates the framework, while product-specific legislation clarifies the data and timelines.

Source → verification → role assessment → preparation → deadline review.

Each value has an owner and a status, but the platform does not transfer legal responsibility.

No. ESPR establishes the framework, while detailed requirements and dates depend on the product and subsequent acts.

The plan provides information about ongoing work and may change. Confirm any obligation in the current legal act.

Responsibility depends on the entity's role and the specific requirement. The platform does not transfer that responsibility.

No. Access should be limited according to the purpose, role and approved visibility policy.

Yes, provided that preparatory data are not presented as a final obligation or certification.

Yes. The interface and content can be localised, while retaining identifiers, sources and URLs.

A signature confirms the integrity of a specific version, not certification or compliance of the physical product.

Assign an owner for the sources, a date for the next review and a procedure for updating versions.