DPP vs SCIP: Does a Digital Product Passport Replace a SCIP Notification?

No. On the official sources reviewed, a Digital Product Passport does not automatically replace a SCIP notification. SCIP is an ECHA database created for information on articles containing Candidate List substances above 0.1% weight by weight under the Waste Framework Directive. A DPP is a product-information framework whose required content, access and granularity are set by the EU rule that makes a passport applicable to that product group. Those are different legal jobs.¹²³ That does not mean the underlying data must be collected twice. Product identifiers, classification data and some substance facts may be reusable if they describe the same object at the same level and retain the evidence needed for the target system. What must remain separate is the legal record itself: a SCIP notification is still a SCIP notification, and a DPP is still a DPP. If you only need the textile-field treatment of the SCIP reference itself, use what a SCIP reference is. This page answers the wider cross-system question.

The two systems do different jobs

The distinction matters because two records can contain the same string without making them equivalent. A GTIN may help both systems identify an object. It does not turn the SCIP notification into the DPP or the DPP into the SCIP notification.

What SCIP actually records

ECHA describes the SCIP obligation as applying to articles placed on the EU market that contain a Candidate List substance in a concentration above 0.1% weight by weight, subject to the duty-holder rules. Its guidance identifies EU producers and assemblers, importers, distributors and other supply-chain actors placing qualifying articles on the market, with an exclusion for retailers and others supplying articles directly and exclusively to consumers.²

The data model goes beyond a single reference number. It can include:

• the article or complex-object identity
• identifiers such as EAN, GTIN, catalogue number or part number
• article category based on CN/TARIC classification
• the Candidate List substance identity
• a concentration range
• the material or mixture category in which the substance is present
• safe-use information where required
• the hierarchy connecting a complex object to the relevant component articles.¹²

ECHA publishes the SCIP data format separately. As at this article's verification date, the current format page lists SCIP format version 6.10, April 2026, and describes the format as XML-based and compatible with IUCLID.⁴

That is why a SCIP record cannot safely be reduced to a field called scip_number. The reference identifies a regulatory record. The record has its own object model, data structure and lifecycle behind it.

What the DPP requires instead

The Ecodesign for Sustainable Products Regulation establishes the horizontal DPP framework. Article 9 says the applicable product rules specify what data belongs in the passport and whether the passport is established at model, batch or item level. The DPP data must be accurate, complete and up to date.³

The DPP Registry is also narrower than many businesses assume. The Commission's July 2026 launch material says substantive product data is stored in a decentralised manner, while economic operators register each DPP's unique identifier and associated metadata in the central Registry.⁵

The July 2026 Registry implementing regulation adds an important piece for data reuse: its semantic repository is intended to be an authoritative machine-readable source for DPP data models, semantic definitions and vocabularies, including links between DPP attributes and underlying evidence.⁶

That creates a better technical route for reuse. It still does not create a legal shortcut from one obligation into another.

Which data can be reused?

The right question is not "is this field in both systems?" It is "is this the same fact about the same regulated object, with the same meaning and evidence?"

A useful rule is simple: reuse the underlying fact when it is genuinely equivalent, but keep the system-specific record, identifier and submission state separate.

For the broader mapping test, see what does not map cleanly into a DPP.

Granularity is where false equivalence usually appears

SCIP and DPPs can divide the product world differently.

A DPP may sit at model, batch or individual-item level depending on the applicable product rule. SCIP is built around articles and complex objects, including component relationships where a qualifying substance sits in one part of a larger object.¹³

That means a statement can be true in SCIP and still be wrong if copied flat into a DPP.

Imagine a product with five components and only one component contains a Candidate List substance above the relevant threshold. The substance fact belongs to that article in the component hierarchy. Copying the substance name into a whole-product field without retaining where it applies has changed the claim.

The same problem appears when businesses flatten model, variant and SKU data. Model, variant and SKU facts covers that hierarchy in more detail.

Evidence and provenance must travel with the value

A reusable value should not travel alone.

At minimum, keep:

1. the value itself
2. the object it describes, including component or product hierarchy
3. the source system and source record ID
4. the source document or supplier statement, where one supports the value
5. the applicable rule or data-model version
6. the date observed or verified
7. the actor who supplied or asserted it
8. the transformation applied before it was rendered into another system
9. the target-system record ID once submitted or registered.

That is an operating recommendation, not a statutory SCIP field list. It is the minimum structure that lets a business answer a later question: why did this passport say this, and which regulatory record did it come from?

The same provenance principle is used across technical files to governed product data and owning a published field.

One fact can have more than one record owner

A business does not need to choose one database to "own everything".

A practical architecture separates four things:

• Business fact owner: the controlled value you maintain internally, such as a GTIN or component substance fact
• Evidence owner: the document, supplier statement, lab result or authoritative source supporting the value
• Regulatory record owner: the SCIP notification, DPP Registry entry or other formal record created for a specific obligation
• Published representation: the version rendered into the DPP for the audience and access rules the product legislation requires.

This is the same distinction developed in which system should own each product fact.

A practical operating model for SCIP and DPP together

For a business that may need both systems, the low-regret sequence is:

1. Resolve the regulated object first

Identify whether the fact describes a product, model, component article, material or another object. Do not start by copying fields between exports.

2. Govern reusable identities once

Keep stable identifiers such as GTIN, catalogue number and classification in controlled product data, with their schemes and versions.

3. Keep the component and substance hierarchy intact

If a SCIP fact belongs to one component article, preserve that relationship. Do not flatten it just because the DPP renderer expects a convenient table.

4. Keep the SCIP record as its own record

Store the SCIP notification/reference and its lifecycle as a regulatory artefact. A DPP may link to or reuse facts from it if the applicable DPP rules support that. It should not silently absorb its legal identity.

5. Map into the DPP only against the applicable DPP definition

Use the actual product-specific DPP requirements and, where available, the Commission semantic repository. A same-sounding label is not enough.

6. Record the transformation

If SCIP concentration range becomes a DPP substance statement, record exactly how, at what component level and under which rule that transformation occurred.

7. Update each system on its own trigger

A Candidate List change, composition change, SCIP format change or DPP delegated-act change can create different update work. Do not assume one update propagates legally just because your software can propagate a value technically.

The common misconception

"If the DPP contains the same substance information, the SCIP notification becomes redundant."

That is not what the official sources reviewed establish.

The safer statement is narrower: some underlying data may be reusable between SCIP and a DPP when the definitions, object, granularity, evidence and currentness match. The legal records remain separate unless EU law explicitly makes one system satisfy the other.

That distinction matters beyond SCIP. The same test applies when a business tries to reuse EPREL, EUDR, EPR, customs, technical-file or packaging data in a passport. The matrix is on Product Data Across EU Systems.

Direct answers

Does a DPP replace SCIP?

No automatic replacement is established by the official sources reviewed. If your business has a SCIP notification obligation, treat it as a separate legal record unless a later binding rule expressly changes that position.

Can SCIP data be used in a DPP?

Potentially, yes. Identifiers and substance facts can be candidates for reuse. The target DPP rule still has to require or permit that information and the object, definition, granularity and evidence must match.

Is the SCIP reference number a DPP field?

Not universally. A SCIP reference can be a useful cross-reference, but DPP fields are determined by the applicable product-specific legislation and data model. Do not hard-code it as a universal DPP requirement.

Can I use the same GTIN in SCIP and a DPP?

Where the same GTIN genuinely identifies the same regulated object, reusing that identifier is sensible. Keep the identifier scheme and the object level with it.

Should SCIP be my source of truth for substance data?

Not by default. SCIP is a regulatory record. Your governed substance evidence may originate elsewhere and feed both SCIP and a DPP. The source of truth depends on what fact is being governed, not which database is most visible.

Primary official sources

• ECHA, SCIP database - article/complex-object identity, identifiers, Candidate List information and SCIP scope

  View official source

• ECHA, Suppliers of articles - duty holders, threshold, date and information to collect

  View official source

• Regulation (EU) 2024/1781 (ESPR), Articles 9-13 - DPP content, granularity, identifiers and Registry framework

  View official source

• ECHA, SCIP format - XML/IUCLID format and current version

  View official source

• European Commission, DPP Registry now live, 20 July 2026 - decentralised data and central registration metadata

  View official source

• Commission Implementing Regulation (EU) 2026/1778, Article 12 - DPP semantic repository and evidence links

  View official source