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.
⚠️ 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.
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
The DPP infrastructure requires harmonised standards from CEN/CENELEC JTC 24 (Digital Product Passport — Framework and System). As of April 2026:
- The eight horizontal DPP standards are in final voting (FprEN stage)
- None have been formally published as EN standards
- None have been cited in the OJEU (no presumption of conformity yet)
- The standardisation request has been extended to 2028
This means the standards pipeline is progressing but has not delivered usable outputs yet. 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
- 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.