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 22 July 2026: Council and Parliament reached a provisional political agreement on 9 June 2026 on the Omnibus IV digitalisation and common-specifications files. The agreement confirms that common specifications are to remain an exceptional fallback where harmonised standards are unavailable or insufficient. It is not yet adopted law: formal endorsement, legal-linguistic revision and adoption are still required.
July 2026 standards status: Decision (EU) 2026/1736 published six JTC 24 DPP standard references in the Official Journal on 15 July, so they now support a presumption of conformity to the extent covered. Two standards remain outside that package. Decision C(2025) 8024 also adopted the full-ESPR-scope amendment to the standardisation request; the September 2025 draft is historical context, not the current legal status.
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. The provisional agreement confirms that fallback principle for situations in which harmonised standards are unavailable or insufficient. The definitive trigger wording should be taken from the formally adopted and legally revised text once published.
| 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 in the Provisional Agreement
Omnibus IV is not yet adopted law, but the provisional agreement already confirms 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
- Final legal wording still pending: the political direction is agreed, but the legally revised text must still be endorsed and adopted
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 the following source layers:
- C(2024)5423 of 31 July 2024: the adopted standardisation request to CEN, CENELEC and ETSI; originally scoped to the battery passport.
- Decision C(2025) 8024: adopted the amendment extending the request beyond the original battery-only scope. The draft of 23 September 2025 is useful history, not the current status.
- Decision (EU) 2026/1736 and the CEN/CENELEC JTC 24 standards database: the Decision cites six standards in the Official Journal; the database shows two further standards 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. |
The six cited standards have now completed both the EN-publication and Official-Journal-reference steps. As of 18 July 2026:
- Six horizontal DPP standards have been formally published and cited in the OJEU, giving a presumption of conformity to the extent covered
- 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
- The full-ESPR-scope amendment is adopted through Decision C(2025) 8024; any historical draft dates should not be used as if they were current binding deadlines
This means a horizontal presumption-of-conformity route now exists for the areas covered by the six cited standards, but the remaining security, access-rights and data-integrity work is unfinished. The battery-passport obligation becomes applicable on 18 February 2027 for the categories covered by Article 77.
What CS could provide
If adopted, the CS mechanism could allow the Commission to publish technical specifications for remaining gaps where harmonised standards do not provide a usable route, 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. The required fields for a textile DPP and the carbon-footprint methodology for a battery passport are 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), use the six cited standards where they cover your requirements and track the remaining JTC 24 work, product-specific acts and Omnibus IV separately. The six-standard route now exists; the unresolved question concerns gaps, not the whole DPP framework.
-
Use existing interoperable standards where appropriate. GTIN/GS1 Digital Link and ISO 14067 can be useful candidates in some implementations, but they are not universal safe harbours: the applicable product law, prescribed calculation method and cited standards must be checked before selecting them.
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
- Council and Parliament provisional agreement on Omnibus IV, 9 June 2026
- ESPR Regulation (EU) 2024/1781
- Commission Implementing Decision (EU) 2026/1736: six DPP harmonised standards
- Commission answer to Parliament E-000888/2026(ASW): JTC 24 standards and DPP registry status
- CEN-CENELEC: first DPP standards and their status in the EU Official Journal
- 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
- Commission page: DPP harmonised standards and Decision (EU) 2026/1736
- 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.