The ESPR framework: regulation → delegated → implementing acts
Key insight: ESPR is the legal foundation, but it delegates the what to delegated acts, the how to implementing acts, and the exact formats to EN standards. An implementer who understands this hierarchy knows where each requirement lives and when it can change.
1. Regulation vs. directive — why it matters for architecture
ESPR (Regulation (EU) 2024/1781) is a regulation, not a directive. A directive requires each member state to transpose it into national law; a regulation applies directly in all member states with uniform effect. For DPP architecture, that removes a whole class of per-country variation in the core functionality: data carriers, access rules, persistence, and interoperability are the same everywhere.
The one place member states still matter is market surveillance and enforcement — which national authority you report to, and in what language the consumer-facing interface must appear. Core data logic is uniform; the edges are national.
| Level | What it does | DPP example |
|---|---|---|
| Regulation (ESPR) | General obligations, applies directly | DPP required; data carrier; accessibility; persistence |
| Delegated act | Product-category specifics | battery fields, textile fields, timelines |
| Implementing act | Technical/procedural detail | DPP Registry rules, restricted-data access |
| EN standard | Voluntary technical specification | EN 18216–18223 (identifiers, carriers, APIs…) |
| National implementation | Surveillance & enforcement | reporting to authority, consumer language |
Why does 'ESPR is a regulation, not a directive' matter for a DPP system architect?
2. Delegated acts: category-specific requirements
The Commission adopts delegated acts that make ESPR concrete per product category. A delegated act specifies the data fields, lifecycle stages, compliance timeline, and verification rules for that category. The first delegated acts under ESPR target iron and steel (2026); textiles, tyres, and aluminium follow (2027); furniture (2028); mattresses and ICT (2029). Batteries run under their own regulation (2023/1542), with the first passports operational February 2027.
To see what a delegated act actually contains, take a hypothetical textile act. It would enumerate:
- the mandatory data fields (fibre composition, recycled content, country of production, care instructions);
- the lifecycle stages that must be recorded (fibre → yarn → fabric → garment → retail → end-of-life);
- the compliance timeline (from date of application to full obligation);
- the verification rules (how claims must be evidenced and checked).
That is why delegated acts force a core + extensions design: a category-agnostic core (identifiers, carriers, APIs) plus category-specific extension modules. Hard-coding "battery fields" into the core is the classic mistake — the next delegated act would require a re-architecture.
Why do delegated acts force a core-plus-extensions architecture rather than one big data model?
3. Implementing acts: the operational layer
Implementing acts define how the system operates technically: the DPP Registry's registration workflow, data formats, protocols, and testing. A key one is the DPP Registry implementing act (2026/1778); the restricted-data-access act is expected late 2026. These are where an implementer finds concrete, must-follow procedure — enrolment via qualified electronic signatures/seals, registry API behaviour, and access-rights rules.
The distinction is practical. A delegated act tells you which fields a battery passport must contain; an implementing act tells you how to register that passport in the Registry and who may access which fields. Confusing the two is how you build the right data model against the wrong workflow.
Which pair correctly contrasts delegated acts and implementing acts?
4. EN standards: the voluntary but de facto binding layer
The EN 182xx family (published May 2026) is formally voluntary, but conforming to them gives presumption of conformity with ESPR Articles 10 and 11. In practice that makes them the de facto specification every implementation follows:
| Standard | What it specifies |
|---|---|
| EN 18216 | Data exchange protocols — how passport data moves between systems |
| EN 18219 | Unique identifiers — UPI, UOI, UFI and how to construct them |
| EN 18220 | Data carriers — QR, Data Matrix, NFC, RFID and how a carrier encodes the identifier |
| EN 18221 | Storage, archiving and persistence — retention and integrity over decades |
| EN 18222 | APIs for lifecycle management and searchability |
| EN 18223 | System interoperability across implementations |
| prEN 18239 | Access rights, security and confidentiality (under vote) |
| prEN 18246 | Data authentication, reliability and integrity (under vote) |
The full family is covered in Module 2. Here the point is the layering: regulation sets obligations, standards set technique.
The EN 182xx standards are formally voluntary. Why are they still treated as the de facto specification?
5. Designing for regulatory change
The hierarchy is not static: delegated acts arrive over time, standards get revised, and national guidance evolves. A resilient DPP architecture therefore has:
- a regulatory abstraction layer — a stable internal interface that hides ESPR specifics, so a standards revision changes one adapter, not the whole system;
- category extensions — pluggable modules for each delegated act;
- config-driven requirements — field lists and validation rules as data, not code;
- a change-management process — impact analysis before any regulatory update ships.
A concrete illustration: when EN 18219's identifier rules are revised, a well-layered system updates its identifier adapter behind a stable interface. A badly-layered system edits identifier logic scattered across registration, validation, and API code — three places to break. The abstraction layer is what turns "compliance" from a recurring fire drill into a maintenance task.
A new delegated act adds a 'durability rating' field to the textile DPP. Which design decision lets you support it without re-architecting the core?
Key points
- ESPR is a regulation — core requirements apply uniformly; only enforcement varies nationally.
- Delegated acts add category-specific fields, timelines, and verification.
- Implementing acts define operational detail (Registry workflow, access rules).
- EN 182xx standards provide the de facto technical specification and presumption of conformity.
- Design for change: abstraction layer, category extensions, config-driven requirements.
Key takeaway: Requirements live at five layers. Know which layer a requirement comes from, and you'll know how stable it is and how to architect for it.