Common Specifications: The EU's Fallback Plan for DPP Standards
What common specifications are, when they apply, how they differ from harmonised standards, and why they matter for the DPP timeline.
Editorial update, 16 July 2026: historical references below to the absence of an Official Journal citation for the six DPP standards are no longer current. Implementing Decision (EU) 2026/1736 published their references on 15 July, so the six standards give a presumption of conformity to the extent that they cover a requirement. Common specifications still matter for gaps outside that package or where a standard does not cover the requirement concerned. Full Decision briefing →
⚠️ Status as of April 2026: The systematic introduction of common specifications across EU product law is part of the Omnibus IV legislative proposal. It is not yet adopted law. The final text is subject to the ordinary legislative procedure and may change.
June 2026 standards status: Six JTC 24 DPP standards were published as EN standards in May 2026. Two remain in progress, and CEN/CENELEC publication still does not by itself mean OJEU citation or presumption of conformity.
What Are Common Specifications
In the Omnibus IV proposal, common specifications (CS) would be technical requirements adopted by the European Commission as implementing acts when harmonised standards do not provide a workable route. They would be intended to provide a legally recognised way to demonstrate compliance with EU product legislation, similar to the role harmonised European standards (hENs) play today.
The mechanism is not new in EU law. It already exists in some sectoral regulations (e.g., medical devices, civil drones). What is new is the proposal to introduce it systematically across product legislation through the Omnibus IV package — Commission proposal COM(2025) 504 (registered by the Council as ST 7242 2026 INIT).
Why This Mechanism Exists
The standard European standardisation process works like this:
- The European Commission issues a standardisation request to CEN, CENELEC, or ETSI.
- The European Standardisation Organisations (ESOs) develop draft harmonised standards.
- After public inquiry and formal vote, the standards are published.
- The Commission cites the standards in the Official Journal of the EU (OJEU).
- From that citation date, the standards give a presumption of conformity.
This process takes time. According to data presented at the IMCO Structured Dialogue of 26 March 2026, the average time from standardisation request to OJEU citation is 6.1 years. For standards based on international references (ISO/IEC), drafting alone takes an average of 4.4 years.
Common specifications address a specific failure mode: what happens when the standardisation process does not deliver on time?
Without CS, companies face a gap: the regulation requires compliance, but the technical standards needed to demonstrate compliance do not yet exist. In that gap, companies either over-invest in custom solutions, under-invest and hope for the best, or wait — all of which create uncertainty.
When Common Specifications Apply
Under the Omnibus IV proposal, CS would be framed as a fallback or last-resort tool where harmonised standards do not provide a usable compliance route. In the operative drafting, this includes situations where no relevant harmonised standard is available in time, where published standards do not adequately solve the compliance problem, and, in some institutional versions, where an urgent compliance concern must be addressed. The exact trigger formula is still part of the legislative process.
| Situation in the text | Practical meaning |
|---|---|
| No usable harmonised standard in time | No OJEU-cited standard covers the requirement, or no such reference is expected soon enough to support compliance |
| Standards do not adequately resolve the compliance issue | Applying the published standard still leaves a regulatory gap or a non-compliance problem |
| Exceptional fallback rather than routine rule | CS are framed as a last resort, not as the new default path for technical product rules |
In that proposal, CS would therefore be best understood as a fallback, not a replacement. The standardisation request remains the primary path.
How CS Differ from Harmonised Standards
At a high level, if the Omnibus IV approach is adopted, the comparison would look like this:
| Aspect | Harmonised Standards (hENs) | Common Specifications (CS) |
|---|---|---|
| Who drafts them | CEN, CENELEC, ETSI (independent bodies) | European Commission (with expert input) |
| Legal basis | Cited in the OJEU after ESO adoption | Adopted as implementing acts |
| Compliance effect | Presumption of conformity after OJEU citation | Intended to provide a comparable recognised compliance route if adopted |
| Voluntary | Yes — companies can choose alternative compliance paths | Yes — same principle applies |
| Revision cycle | Managed by ESOs | Managed by the Commission |
| Industry participation | Through national mirror committees | Through expert groups and consultation |
The key practical difference is institutional: harmonised standards are developed bottom-up (industry experts draft, vote, and publish), while CS would be developed top-down (Commission drafts, consults, and adopts). Under the proposal, both routes are intended to support a recognised compliance pathway.
Safeguards Under Discussion
The Omnibus IV proposal is a legislative proposal, not adopted law. The legislative text and debate already point to several constraints intended to prevent overuse of the CS mechanism:
- Last-resort framing — CS are discussed as an exceptional tool, not a routine shortcut
- Expert-group involvement — technical preparation with stakeholder and expert input appears in the operative drafting
- Greater procedural transparency — the institutions are discussing closer visibility into the drafting and adoption process
- No final safeguard package yet — the exact legal formula is still being negotiated
Why This Matters for the DPP
The connection between CS and the Digital Product Passport is direct:
The current standards gap
CEN/CENELEC JTC 24 is the joint technical committee responsible for horizontal DPP standards — the standards that define how passport infrastructure should work, not which data fields a specific sectoral passport must contain.
This part has been checked against three source layers:
- C(2024)5423 of 31 July 2024 — the adopted standardisation request to CEN, CENELEC and ETSI; originally scoped to the battery passport.
- Draft decision of 23 September 2025 — proposes extending the request to the full ESPR scope and a later finalisation horizon, but as a draft it is not a binding act.
- Commission answer E-000888/2026(ASW) and the CEN/CENELEC JTC 24 standards database — the answer confirms the earlier voting status; the database now shows six published EN standards and two drafts still in progress.
The table below maps the same package to the published EN status now visible in the CEN/CENELEC JTC 24 standards database.
| Publicly confirmed status | Scope from the Commission answer | What it regulates in the DPP |
|---|---|---|
| Published EN 18219:2026 | Unique identifiers | How to identify the product, operator, and passport record unambiguously |
| Published EN 18220:2026 | Data carriers and links between physical product and digital representation | How a code, label, or other carrier resolves to the correct passport |
| Published EN 18223:2026 | Interoperability: technical, semantic, and organisational | How different systems understand data, roles, and processes in the same way |
| Published EN 18216:2026 | Data exchange protocol, data processing, and data formats | How data is transmitted, read, and structured |
| Published EN 18221:2026 | Data storage, archiving, and data persistence | How passport availability is maintained through the product lifecycle |
| Published EN 18222:2026 | APIs for passport lifecycle management and searchability | How systems create, update, find, and operate passport records |
| FprEN 18239 / FprEN 18246 in progress | Access-rights management, information-system security and business confidentiality; data authentication, reliability and integrity | The two remaining package standards are not published EN standards yet. WI JT024009 on dictionary referencing is an additional JTC 24 work item to monitor. |
What does EN publication mean? It is a major CEN/CENELEC milestone, but not the end of the legal route. As of June 2026:
- Six horizontal DPP standards have been formally published as EN standards
- Two standards remain in progress: FprEN 18239 on access-rights management, information-system security and business confidentiality, and FprEN 18246 on data authentication, reliability and integrity
- A further JTC 24 work item, WI JT024009 on dictionary referencing, should also be monitored
- None have been cited in the OJEU (no presumption of conformity yet)
- The full ESPR-scope extension and the 2028 horizon come from the draft decision, not an adopted act; the binding adopted basis remains the battery-passport request
This means the standards pipeline has moved materially forward, but the full package has not yet delivered a presumption-of-conformity route. The first DPP obligation (battery passport) enters into force in February 2027 — less than one year away.
What CS could provide
If adopted, the CS mechanism could allow the Commission to publish technical specifications for parts of the DPP framework before the full harmonised standards are published and cited, but only within the scope and conditions finally agreed in the legislation.
This would not bypass the work of JTC 24. It would provide a bridge: companies could get earlier technical certainty, and JTC 24 standards would replace CS when they are ready.
What CS do not solve
CS address the technical framework (how data is structured, exchanged, and verified). They do not define the data content itself. What data fields a textile DPP requires, or what carbon footprint methodology a battery passport uses — that is defined in sector-specific delegated acts, not in CS.
What Companies Should Do
-
Do not wait for final standards to start structuring data. Whether the eventual framework uses hENs or CS, the data itself (composition, environmental evidence, identifiers, supplier records) remains the same.
-
Monitor the IMCO discussion. The safeguard provisions will determine how broadly CS can be used and how quickly they can be deployed.
-
If you are in a priority sector (batteries, textiles, iron and steel), track both the JTC 24 standards timeline and the Omnibus IV legislative progress. One of these two paths will deliver technical specifications first.
-
Use existing interoperable standards where possible. GTIN where product identifiers are needed, ISO 14067 for carbon footprint, and GS1 Digital Link as a URI structure behind QR-based data carriers — these are defensible choices regardless of whether hENs or CS define the final DPP framework.
Read Next
- Omnibus IV: What the Proposal Actually Contains and What It Means for DPP
- ESPR DPP in March 2026: Standards, Registry and Open Gaps
- ESPR Timeline 2026–2030: Confirmed Dates vs Indicative Signals
- Who Can Operate a DPP? EU Rules for Service Providers
- DPP Data Requirements: What Data You Actually Need
Official Sources
- Commission proposal COM(2025) 504 — Omnibus IV Regulation on digitalisation and common specifications
- Commission proposal COM(2025) 503 — Omnibus IV Directive on digitalisation and common specifications
- ESPR Regulation (EU) 2024/1781
- Commission answer to Parliament E-000888/2026(ASW) — JTC 24 standards and DPP registry status
- CEN/CENELEC JTC 24 standards database — published DPP EN standards
- DG GROW Notification System — adopted and possible future standardisation requests, including C(2024)5423
- DG GROW — draft decision extending the DPP standardisation request, 23 September 2025
- CEN-CENELEC — Ecodesign, labelling and traceability of products
- IMCO Structured Dialogue 26 March 2026 — Standardisation
Want to start building product data records now, regardless of which technical standard emerges? Start free on OriginPass.eu — structured product passports in minutes, not months.