"Traditional product passport" is a descriptive term on this page, not a legal category in ESPR. It covers company-controlled labels, PDFs, certificate packs, web pages, and internal product records. For a product group covered by an ESPR delegated act, those materials can supply evidence or data, but the regulated (DPP) must also meet the rule for passport content, data carriers, identifiers, access rights, registry records, availability, and any applicable customs checks.
Comparison matrix
Regulated EU DPP vs paper, PDF, web, and internal product passports
A regulated DPP adds a technical and legal access layer for product data. A traditional passport is usually evidence or communication material controlled inside one organisation.
A DPP required under ESPR product-specific rules must be accurate, complete, up to date, accessible through a data carrier, linked to identifiers, interoperable, and searchable or usable according to defined access rights.
Second framework
Traditional product passports
Paper files, PDFs, web pages, certificate packs, and internal product records can still be useful, but they do not by themselves create the ESPR DPP data carrier, identifier, registry, access-rights, or customs-control layer.
Regulated EU DPP vs paper, PDF, web, and internal product passports
For a covered product group, ESPR information requirements provide that products can be placed on the market or put into service only when a DPP is available under the applicable delegated act.
Article 9 makes DPP availability a condition for covered products under product-specific delegated acts.
only be placed on the market or put into service
A paper passport, PDF, website, or evidence record can support product information management, but it is not automatically the regulated DPP unless it satisfies the delegated act and ESPR technical requirements.
ESPR treats labels, manuals, websites, and other non-digital channels as complements rather than replacements for a required DPP.
complemented by non-digital forms
Do not treat an existing product data pack as DPP-ready until it has been mapped to the applicable delegated act, DPP data fields, identifier level, data carrier, access rights, and availability period.
A regulated DPP must provide free and easy access to the passport based on access rights for customers, economic operators, repairers, recyclers, market surveillance authorities, customs authorities, and other relevant actors.
Article 11 requires free and easy DPP access according to the access rights set in the applicable delegated act.
based on their respective access rights
Traditional passports often give one audience the same packet of information, or keep sensitive fields inside an internal portal. They usually do not encode stakeholder-specific public, restricted, and authority access in the artifact itself.
ESPR requires differentiated access rights for DPP data and recognises protection of confidential business information.
differentiated access to the data
Separate public fields, restricted supply-chain fields, and authority-visible fields before implementation. A single downloadable PDF is usually too blunt for ESPR-style access control.
A regulated DPP is connected through a data carrier to a persistent unique product identifier, and the delegated act specifies whether data refers to a model, batch, or item.
Articles 9 and 10 connect the DPP to a unique product identifier and model, batch, or item level.
model, batch or item
Traditional product passports may use SKUs, part numbers, batch sheets, or certificate numbers, but those identifiers may be designed for internal control rather than globally reliable and verifiable DPP lookup.
ESPR requires identifier and data-carrier rules that make identifiers reliable, verifiable, globally unique, and interoperable.
reliable, verifiable and unique globally
Choose the passport level deliberately. Model-level records resemble common labels; batch-level records support batch traceability; item-level records are more granular but require stronger data operations.
The DPP must be accessible through one or more data carriers, and the data carrier must be physically present on the product, packaging, or accompanying documentation as specified by the delegated act.
Article 10 requires the data carrier to be present on the product, packaging, or accompanying documentation.
physically present on the product
A traditional passport may sit in a document repository or be printed in a manual. If buyers, customs, repairers, or recyclers cannot reliably find and scan it, it does not provide the same product-linked access path.
ESPR requires delegated acts to specify one or more data carriers and the carrier's layout and positioning.
one or more data carriers
Plan the carrier as part of the product and packaging design: placement, durability, scanability, online-distance-selling access, and fallback documentation all affect whether the passport is usable.
ESPR requires DPP data to be accurate, complete, and up to date. It also restricts who can introduce, modify, or update data according to access rights.
Articles 9 and 11 require up-to-date data and restricted rights to introduce, modify, or update DPP data.
accurate, complete and up to date
A PDF or paper pack can become stale quickly, and internal systems often lack a product-facing update trail for external actors. They may be evidence sources, but they are not enough without controlled update governance.
CIRPASS recommends digitising manuals and certificates to reduce paper documentation, showing why static paperwork is only part of the transition.
reduce paper documentation and waste
Define data owners, update permissions, evidence sources, and change controls for every DPP field. Treat static documents as inputs, not as the live passport.
The regulated DPP model supports different data visibility for different actors, and the Commission registry stores at least unique identifiers plus commodity codes for products released for free circulation.
Articles 13 and 15 connect registry identifiers and commodity codes to customs checks for release for free circulation.
commodity code
Traditional passports often mix consumer information, supplier data, technical documentation, and customs details in separate files or systems. That separation can help confidentiality, but it is not an interoperable access model by itself.
ESPR requires product-specific access rules and registry data for customs-relevant product identifiers and commodity codes.
specific access rights
Build a field-level data matrix: public consumer data, restricted commercial or supply-chain data, authority data, registry identifiers, and customs commodity-code data should not be collapsed into one document.
A DPP must be designed so data authentication, reliability, integrity, security, privacy, and fraud avoidance are addressed. The registry can also support authenticity checks for the passport.
Article 11 requires authentication, reliability, integrity, security, privacy, and fraud avoidance in DPP operation.
data authentication, reliability and integrity
A signed PDF, certificate, or internal approval can support trust, but it usually verifies a document or process rather than the current product-linked passport across all authorised stakeholders.
ESPR requires DPP data to be based on open standards, interoperable formats, machine-readable structure where appropriate, and transferable through an open interoperable data exchange network without vendor lock-in.
Articles 10 and 11 require open standards, interoperability, machine-readable structure where appropriate, and no vendor lock-in.
without vendor lock-in
Traditional passports can be locked into one supplier portal, spreadsheet, PDF template, or internal product information system. That may work internally but can fail when actors need cross-sector or authority access.
CIRPASS recommends interoperable IT systems and avoiding isolated platforms or vendor lock-in.
interoperable IT system
Assess whether the current product-data stack can expose structured, searchable, transferable data and support future standards, rather than only publishing a branded document or portal.
CIRPASS system architecture is used for the implementation risk that DPPs need architecture, identity, and data exchange design beyond document publishing.
The Commission launched the DPP Registry and a testing environment on 20 July 2026. Article 15's automated customs verification applies once the required registry interconnection operates and a covered product is placed under release for free circulation; a positive check of the unique registration identifier and commodity code is then required before release.
Current official source confirming launch of the DPP Registry and testing environment on 20 July 2026.
A traditional passport may be shown to customers or auditors, but it normally does not create the EU registry record or automated customs comparison required by ESPR for covered imported products.
ESPR gives customs authorities access to the registry and requires registry checks for covered products released for free circulation.
customs authorities shall have access
For imports, the passport project must cover registry upload, unique registration identifier handling, commodity-code alignment, and the customs data path in addition to customer-facing content.
Article 15 provides for interconnection with EU CSW-CERTEX for automated customs information exchange.
automated exchange of information
Scope boundary
Regulated EU Digital Product Passport
For a covered product group, ESPR information requirements provide that products can be placed on the market or put into service only when a DPP is available under the applicable delegated act.
Article 9 makes DPP availability a condition for covered products under product-specific delegated acts.
only be placed on the market or put into service
Traditional product passports
A paper passport, PDF, website, or evidence record can support product information management, but it is not automatically the regulated DPP unless it satisfies the delegated act and ESPR technical requirements.
ESPR treats labels, manuals, websites, and other non-digital channels as complements rather than replacements for a required DPP.
complemented by non-digital forms
Operational implication
Do not treat an existing product data pack as DPP-ready until it has been mapped to the applicable delegated act, DPP data fields, identifier level, data carrier, access rights, and availability period.
Article 9 lists the product-specific choices that delegated acts must specify for DPP implementation.
the data to be included
Covered actors
Regulated EU Digital Product Passport
A regulated DPP must provide free and easy access to the passport based on access rights for customers, economic operators, repairers, recyclers, market surveillance authorities, customs authorities, and other relevant actors.
Article 11 requires free and easy DPP access according to the access rights set in the applicable delegated act.
based on their respective access rights
Traditional product passports
Traditional passports often give one audience the same packet of information, or keep sensitive fields inside an internal portal. They usually do not encode stakeholder-specific public, restricted, and authority access in the artifact itself.
ESPR requires differentiated access rights for DPP data and recognises protection of confidential business information.
differentiated access to the data
Operational implication
Separate public fields, restricted supply-chain fields, and authority-visible fields before implementation. A single downloadable PDF is usually too blunt for ESPR-style access control.
Article 9 requires product-specific delegated acts to define which actors have access to which DPP data.
what data they are to have access
Identifiers and passport level
Regulated EU Digital Product Passport
A regulated DPP is connected through a data carrier to a persistent unique product identifier, and the delegated act specifies whether data refers to a model, batch, or item.
Articles 9 and 10 connect the DPP to a unique product identifier and model, batch, or item level.
model, batch or item
Traditional product passports
Traditional product passports may use SKUs, part numbers, batch sheets, or certificate numbers, but those identifiers may be designed for internal control rather than globally reliable and verifiable DPP lookup.
ESPR requires identifier and data-carrier rules that make identifiers reliable, verifiable, globally unique, and interoperable.
reliable, verifiable and unique globally
Operational implication
Choose the passport level deliberately. Model-level records resemble common labels; batch-level records support batch traceability; item-level records are more granular but require stronger data operations.
Article 12 covers rules for the life cycle management of unique identifiers and data carriers.
reliable, verifiable and unique globally
Product-linked access
Regulated EU Digital Product Passport
The DPP must be accessible through one or more data carriers, and the data carrier must be physically present on the product, packaging, or accompanying documentation as specified by the delegated act.
Article 10 requires the data carrier to be present on the product, packaging, or accompanying documentation.
physically present on the product
Traditional product passports
A traditional passport may sit in a document repository or be printed in a manual. If buyers, customs, repairers, or recyclers cannot reliably find and scan it, it does not provide the same product-linked access path.
ESPR requires delegated acts to specify one or more data carriers and the carrier's layout and positioning.
one or more data carriers
Operational implication
Plan the carrier as part of the product and packaging design: placement, durability, scanability, online-distance-selling access, and fallback documentation all affect whether the passport is usable.
Article 9 requires delegated acts to specify carrier layout, positioning, and pre-contract access including distance selling.
layout in which the data carrier is to be presented
Evidence record
Regulated EU Digital Product Passport
ESPR requires DPP data to be accurate, complete, and up to date. It also restricts who can introduce, modify, or update data according to access rights.
Articles 9 and 11 require up-to-date data and restricted rights to introduce, modify, or update DPP data.
accurate, complete and up to date
Traditional product passports
A PDF or paper pack can become stale quickly, and internal systems often lack a product-facing update trail for external actors. They may be evidence sources, but they are not enough without controlled update governance.
CIRPASS recommends digitising manuals and certificates to reduce paper documentation, showing why static paperwork is only part of the transition.
reduce paper documentation and waste
Operational implication
Define data owners, update permissions, evidence sources, and change controls for every DPP field. Treat static documents as inputs, not as the live passport.
Article 11 ties update rights to access-rights rules set in delegated acts.
rights to introduce, modify or update data
Visibility and Registry fields
Regulated EU Digital Product Passport
The regulated DPP model supports different data visibility for different actors, and the Commission registry stores at least unique identifiers plus commodity codes for products released for free circulation.
Articles 13 and 15 connect registry identifiers and commodity codes to customs checks for release for free circulation.
commodity code
Traditional product passports
Traditional passports often mix consumer information, supplier data, technical documentation, and customs details in separate files or systems. That separation can help confidentiality, but it is not an interoperable access model by itself.
ESPR requires product-specific access rules and registry data for customs-relevant product identifiers and commodity codes.
specific access rights
Operational implication
Build a field-level data matrix: public consumer data, restricted commercial or supply-chain data, authority data, registry identifiers, and customs commodity-code data should not be collapsed into one document.
Article 13 requires the economic operator to upload registry data and gives authorities access for Union-law duties.
shall upload, in the registry
Authentication and data integrity
Regulated EU Digital Product Passport
A DPP must be designed so data authentication, reliability, integrity, security, privacy, and fraud avoidance are addressed. The registry can also support authenticity checks for the passport.
Article 11 requires authentication, reliability, integrity, security, privacy, and fraud avoidance in DPP operation.
data authentication, reliability and integrity
Traditional product passports
A signed PDF, certificate, or internal approval can support trust, but it usually verifies a document or process rather than the current product-linked passport across all authorised stakeholders.
Article 13 allows additional registry data where needed to verify DPP authenticity and improve market surveillance or customs controls.
verification of the authenticity
Interoperability and portability
Regulated EU Digital Product Passport
ESPR requires DPP data to be based on open standards, interoperable formats, machine-readable structure where appropriate, and transferable through an open interoperable data exchange network without vendor lock-in.
Articles 10 and 11 require open standards, interoperability, machine-readable structure where appropriate, and no vendor lock-in.
without vendor lock-in
Traditional product passports
Traditional passports can be locked into one supplier portal, spreadsheet, PDF template, or internal product information system. That may work internally but can fail when actors need cross-sector or authority access.
CIRPASS recommends interoperable IT systems and avoiding isolated platforms or vendor lock-in.
interoperable IT system
Operational implication
Assess whether the current product-data stack can expose structured, searchable, transferable data and support future standards, rather than only publishing a branded document or portal.
CIRPASS system architecture is used for the implementation risk that DPPs need architecture, identity, and data exchange design beyond document publishing.
DPP System Architecture
Registry and customs handoff
Regulated EU Digital Product Passport
The Commission launched the DPP Registry and a testing environment on 20 July 2026. Article 15's automated customs verification applies once the required registry interconnection operates and a covered product is placed under release for free circulation; a positive check of the unique registration identifier and commodity code is then required before release.
Current official source confirming launch of the DPP Registry and testing environment on 20 July 2026.
Traditional product passports
A traditional passport may be shown to customers or auditors, but it normally does not create the EU registry record or automated customs comparison required by ESPR for covered imported products.
ESPR gives customs authorities access to the registry and requires registry checks for covered products released for free circulation.
customs authorities shall have access
Operational implication
For imports, the passport project must cover registry upload, unique registration identifier handling, commodity-code alignment, and the customs data path in addition to customer-facing content.
Article 15 provides for interconnection with EU CSW-CERTEX for automated customs information exchange.
automated exchange of information
Practical decision rule
Practical decision rule
Check whether an applicable delegated act requires a DPP for the product and record its passport level, fields, access rights and application date.
Inventory existing labels, PDFs, manuals and product records. For each reusable value, record its product identifier, evidence source, owner, access level and update rule.
List the remaining controls: product-linked carrier, persistent identifier, interoperable publication, restricted access, backup and Registry registration where required. Assign an owner and record the result of each check before release.
1
Section 1
How to reuse existing product passport material
Existing labels, declarations, manuals, certificates, supplier files, and product information management records can feed the DPP. They should be treated as evidence and source systems, not as the regulated passport itself, until they are connected to the required data carrier, persistent identifier, access-rights model, registry obligations, and product-specific delegated act.
Keep paper or PDF material where it remains legally or operationally useful, especially for essential end-user information and technical documentation.
Convert reusable fields into structured DPP data with owner, evidence source, update rule, access level, and identifier level.
Design restricted data separately from public consumer information so confidential business information is not exposed through a one-size-fits-all passport.
Include customs and registry data in the operating model for imported covered products, because a customer-facing page alone does not satisfy the customs control path.
Articles 9-15 provide the DPP requirements for availability, physical and digital information, carriers, identifiers, access rights, registry, web portal, and customs checks.
Primary legal source for ESPR DPP requirements and the distinction between ordinary product information material and regulated passport availability, carriers, identifiers, access rights, registry, web portal, and customs controls.
Articles 9-15 provide the DPP requirements for availability, physical and digital information, carriers, identifiers, access rights, registry, web portal, and customs checks.
Article 9 makes DPP availability a condition for covered products under product-specific delegated acts.
Show 22 more
ESPR treats labels, manuals, websites, and other non-digital channels as complements rather than replacements for a required DPP.
Article 9 lists the product-specific choices that delegated acts must specify for DPP implementation.
Article 11 requires free and easy DPP access according to the access rights set in the applicable delegated act.
ESPR requires differentiated access rights for DPP data and recognises protection of confidential business information.
Article 9 requires product-specific delegated acts to define which actors have access to which DPP data.
Articles 9 and 10 connect the DPP to a unique product identifier and model, batch, or item level.
ESPR requires identifier and data-carrier rules that make identifiers reliable, verifiable, globally unique, and interoperable.
Article 12 covers rules for the life cycle management of unique identifiers and data carriers.
Article 10 requires the data carrier to be present on the product, packaging, or accompanying documentation.
ESPR requires delegated acts to specify one or more data carriers and the carrier's layout and positioning.
Article 9 requires delegated acts to specify carrier layout, positioning, and pre-contract access including distance selling.
Articles 9 and 11 require up-to-date data and restricted rights to introduce, modify, or update DPP data.
Article 11 ties update rights to access-rights rules set in delegated acts.
Articles 13 and 15 connect registry identifiers and commodity codes to customs checks for release for free circulation.
ESPR requires product-specific access rules and registry data for customs-relevant product identifiers and commodity codes.
Article 13 requires the economic operator to upload registry data and gives authorities access for Union-law duties.
Article 11 requires authentication, reliability, integrity, security, privacy, and fraud avoidance in DPP operation.
Article 13 allows additional registry data where needed to verify DPP authenticity and improve market surveillance or customs controls.
Articles 10 and 11 require open standards, interoperability, machine-readable structure where appropriate, and no vendor lock-in.
Articles 13 and 15 define the registry, unique registration identifier, customs access, and customs verification before release.
ESPR gives customs authorities access to the registry and requires registry checks for covered products released for free circulation.
Article 15 provides for interconnection with EU CSW-CERTEX for automated customs information exchange.
"digital product passport"
More quoted passages
"only be placed on the market or put into service"
"complemented by non-digital forms"
"the data to be included"
"based on their respective access rights"
"differentiated access to the data"
"what data they are to have access"
"model, batch or item"
"reliable, verifiable and unique globally"
"physically present on the product"
"one or more data carriers"
"layout in which the data carrier is to be presented"
CIRPASS architecture source used to ground the point that DPP implementation requires architecture and data-exchange design, not only document publication.
CIRPASS system architecture is used for the implementation risk that DPPs need architecture, identity, and data exchange design beyond document publishing.