How a DPP Requirement Moves from EU Planning to an Applicable Product Rule
Understand when an EU Digital Product Passport requirement becomes applicable: Working Plan, delegated act, adoption, entry into force and application date.
Navigate this page
- Overview
- The short version
- A Working Plan is a programme of work, not a product mandate
- Preparatory work can be useful without being law
- The delegated act is where the ESPR product rule becomes spe
- Adoption is not the same as entry into force
- Entry into force is not necessarily the application date
- The battery passport shows what an adopted product rule look
- Textiles show why the status labels matter
- What is settled and what is not
- What a business can prepare now
- A simple test for any DPP claim you are given
- What would change this page
- Sources and legal basis
- Keep exploring
A product appearing in an EU Working Plan does not by itself mean that a Digital Product Passport is mandatory for that product. Under the ESPR route, the Working Plan identifies products for further work. The product-specific delegated act is the instrument that decides whether the product needs a DPP and, if it does, the key rules for that passport. Adoption, entry into force and the date the requirements apply are separate stages.
The short version
If you are trying to work out whether a DPP requirement is settled enough to build against, ask six questions in order:
| Stage | What it tells you | What it does not tell you |
|---|---|---|
| Working Plan / roadmap | The Commission intends to examine or regulate a product group | That the product already needs a DPP |
| Preparatory study / JRC work | What evidence, options and data requirements are being assessed | The final legal field set or application date |
| Draft delegated act | The rule has entered a concrete legislative drafting stage | That the draft is final or already applies |
| Commission adoption | The Commission has adopted the delegated act | That the act has entered into force or is already applicable |
| Entry into force | The act has become part of the applicable legal framework, subject to its own provisions | That every requirement applies immediately |
| Application date | The point from which the relevant requirement must be followed for products in scope | That the same date applies to every product or every DPP regime |
That distinction matters because most bad readiness plans collapse the first, fourth and sixth rows into one date.
A Working Plan is a programme of work, not a product mandate
The ESPR Working Plan 2025–2030 identifies priority products and gives the Commission an indicative programme for developing requirements. It is important evidence of direction. It is not, by itself, the act that makes a product-group DPP mandatory.
The Commission now says this explicitly in its DPP FAQ: inclusion in the Working Plan does not automatically mean a DPP is mandatory. The in-depth study and impact assessment are part of working out what requirements are appropriate, whether a DPP is the right information tool and what the final binding date should be.
For a business, that means a Working Plan entry is enough to justify preparation, but not enough to hard-code a final field list, access model, granularity or compliance date.
Preparatory work can be useful without being law
The Joint Research Centre has published a methodology for defining DPP data requirements under ESPR. It distinguishes potential information elements and supports impact assessment and delegated-act design. That makes it useful evidence of how future requirements may be designed. It does not turn those proposed classifications into a universal current business checklist.
This is a recurring pattern in DPP work: a source can be official, detailed and highly relevant without being the instrument that creates the duty.
The practical response is to label two things separately:
- What type of source is this? Law, Commission guidance, Working Plan, preparatory research, harmonised standard or something else.
- What is the status of the proposition? Use the current estate vocabulary for the proposition itself — for example applicable now, adopted but applying later, proposed, in official development, indicative, pending an implementing/delegated measure, in transposition/national implementation or not established. If the duty comes from another instrument, record that separately as the requirement basis rather than as a lifecycle status.
That separation is maintained in our DPP methodology and authority matrix.
The delegated act is where the ESPR product rule becomes specific
Article 9 of ESPR makes the product-specific delegated act central to the DPP requirements for a product group. As appropriate for that group, the act can specify:
- the data to be included;
- the data carrier;
- how and where the carrier is presented;
- whether the passport sits at model, batch or item level;
- how customers can access it before purchase;
- which actors can access which data;
- who may create or update information;
- how updates work; and
- how long the passport remains available.
That is why a generic “ESPR field list” is not enough. The framework establishes the system. The product act makes the product-specific choices.
For a detailed anatomy of that instrument, read what an ESPR delegated act decides.
Adoption is not the same as entry into force
A delegated act does not move straight from Commission adoption to “businesses must comply today”. Under ESPR Article 72, Parliament and Council have an objection period. The Commission’s general explainer describes the usual period as two months. If there is no objection, the delegated act can enter into force according to its terms.
For readiness work, keep these as separate database fields:
planned_adoption_datedraft_published_datecommission_adoption_dateentry_into_force_dateapplication_date
Do not store all five under a single field called deadline.
Entry into force is not necessarily the application date
ESPR Article 4 says the date of application of an ESPR delegated act is normally not earlier than 18 months after entry into force, subject to the exceptions written into Article 4(4).
That creates a transition floor. It does not create a universal formula you can use to predict a final deadline before the act exists. The act itself sets its application date and can contain justified exceptions or transitional provisions.
The DPP timeline owns the dates. This page owns what those dates mean.
The battery passport shows what an adopted product rule looks like
Batteries are useful because they do not require us to infer a future DPP duty from the ESPR Working Plan. The Batteries Regulation contains an adopted passport regime and fixes 18 February 2027 for the battery-passport requirement for the covered battery classes.
That date is a product-rule date in adopted law. It is categorically different from a planned adoption window in a Working Plan or Commission roadmap.
This does not mean the battery data model should be copied into textiles, furniture or another ESPR product group. It means batteries are a clean example of the difference between a planned rule and an adopted one.
Textiles show why the status labels matter
Textiles are in official development. The Commission’s textile page says the textile-specific DPP requirements will be defined through the future delegated act. As of 3 September 2026, the Commission’s textile page gives Q4 2027 as planned adoption, while the Commission’s general DPP roadmap shows Q3–Q4 2027. Both presentations are indicative, and neither is an application date for textile businesses.
That small difference between two Commission pages is exactly why an implementation system should store the source and status with the date instead of copying “2027” into a deadline field.
For the category position itself, use the textile DPP requirements page. For the date ledger, use the DPP timeline.
What is settled and what is not
| Proposition | Position on 3 September 2026 |
|---|---|
| ESPR is the framework for product-specific ecodesign requirements and DPP rules | APPLICABLE NOW · LAW / ADOPTED ACT |
| A Working Plan entry automatically creates a DPP duty | No. Not established by the Working Plan; Commission guidance says it does not automatically do so |
| ESPR delegated acts decide key DPP details for product groups | APPLICABLE FRAMEWORK · LAW / ADOPTED ACT |
| An adopted delegated act enters into force immediately on Commission adoption | No. Objection and entry-into-force stages remain distinct |
| ESPR product requirements normally apply at least 18 months after entry into force | Framework rule, subject to Article 4(4) exceptions |
| Final textile DPP field list, access model and granularity | NOT ESTABLISHED |
| Covered battery passport date of 18 February 2027 | ADOPTED — APPLIES LATER |
What a business can prepare now
Preparation is useful when it survives a change in the future act.
Prepare now
- Record which Union instrument could create the DPP duty for each product category.
- Store source type, proposition status and verification date separately.
- Map product facts to evidence and to the level where they are true: model, variant, batch or item.
- Keep data fields configurable so a future delegated act can turn a field on, off or conditional without rebuilding the model.
- Keep the product identity and evidence trail persistent.
- Re-verify the official source before launch, not just when the project starts.
Do not hard-code yet
- a final textile field set;
- a universal QR-only rule;
- a universal public-access model;
- a universal model/batch/item level;
- a planned Commission adoption window as the date a business must comply.
If the next question is “what can I safely do before the act lands?”, the practical sequence is in what to do now, and what to refuse to do now.
A simple test for any DPP claim you are given
When somebody says “the EU requires this in 2027”, ask:
- Which product category?
- Which legal instrument?
- Is the source a Working Plan, guidance, draft or adopted law?
- Is the date adoption, entry into force or application?
- Does the requirement apply to this product, actor and condition?
If those five are not answered, the statement is not ready to become an implementation requirement.
What would change this page
Re-verify this page when:
- a new ESPR product delegated act is adopted;
- the Working Plan is revised;
- the Commission changes its DPP lifecycle guidance;
- Article 4 or Article 72 is amended; or
- a product-specific rule creates an exception that changes how the lifecycle should be explained.
Keep exploring
The questions this page usually raises next.
Does this reach your products?
Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.
Help someone else make sense of product passports.
Sources and legal basis
- Regulation (EU) 2024/1781 (ESPR), especially Articles 4, 9 and 72. Official Journal / EUR-Lex.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1781
- European Commission, Frequently Asked Questions on the Digital Product Passport, especially questions 5–7. Official Commission guidance.
- European Commission, Implementing and delegated acts. Official Commission process explainer.
- Ecodesign for Sustainable Products and Energy Labelling Working Plan 2025–2030, COM(2025) 187 final. Working Plan / programming document.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2025:187:FIN
- JRC145830, Methodology for defining data requirements for the Digital Product Passport under the ESPR framework. Preparatory methodology.
https://publications.jrc.ec.europa.eu/repository/handle/JRC145830
- Regulation (EU) 2023/1542 (Batteries Regulation), Article 77. Product-specific adopted law.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R1542
- European Commission, Textile Apparel and the DPP. Official Commission sector page.
https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/textile-apparel_en
- European Commission, Digital Product Passport roadmap. Official Commission implementation page.
https://single-market-economy.ec.europa.eu/single-market/digital-product-passport_en