> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # How Digital Product Passports Will Be Enforced > How Digital Product Passport obligations move from an applicable legal requirement through market surveillance, checks, findings, operator response, corrective or restrictive measures and penalties, why enforcement sits substantially with Member State authorities, and what enforcement readiness means in practice. ## Executive Summary Most explanations of the [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) stop at the point where the passport is published. That is where the regulatory question actually begins. A passport is not a submission to a regulator, and publishing one is not an act of compliance in itself. It is a set of information that must be correct, available and supportable for as long as the applicable requirement says it must be, and that may be examined by a competent authority at any point during that period. This article explains how that examination works, and what may follow from it. It covers the path from an applicable legal requirement, through [market surveillance](/docs/knowledge-base/glossary/market-surveillance) and product or documentary checks, to a compliance finding, an operator response, and where necessary corrective or restrictive measures and penalties. It also covers the part most organisations skip: establishing whether a requirement actually applies to a given product on a given date before any enforcement question can be asked at all. Three points shape everything that follows. The first is that enforcement is substantially national. Under the current EU framework, EU legislation establishes common requirements, and market surveillance and enforcement functions are exercised largely by competent authorities designated by Member States, supported by Union mechanisms for cooperation, information exchange and coordination. The European Commission is not a product inspectorate. It does not examine individual passports or issue fines to individual companies for passport defects. The second is that a requirement must apply before it can be enforced. The [Ecodesign for Sustainable Products Regulation](/docs/knowledge-base/regulations/what-is-the-ecodesign-for-sustainable-products-regulation-espr) (ESPR) has applied since 18 July 2024, but it is a framework. For most product groups the product-specific passport requirement arrives in a [delegated act](/docs/knowledge-base/glossary/delegated-act) that has not yet been adopted. "The regulation exists" and "this obligation applies to this product today" are different statements, and conflating them produces both false urgency and false comfort. The third is that a data defect is not automatically a product defect. An incorrect value in a passport may be a publication error, an evidence problem, or a signal of substantive non-compliance in the product itself. Which of those it is determines the proportionate regulatory response, and that determination is made by investigation, not by the presence of the error. This article introduces the DPP Enforcement Lifecycle, a tieback educational model of eight stages running from applicable requirement to follow-up. It is a way of reasoning about enforcement logic. It is not a statutory procedure, and no EU instrument defines these eight stages. * Enforcement under the current EU framework is exercised substantially by competent Member State authorities, not by the European Commission. - No enforcement question can be answered before the applicable requirement, the applicable date and the applicable product-specific measure have been established. - Market surveillance, conformity assessment and enforcement are three distinct concepts that interact but are not interchangeable. - A passport can make required information more accessible to authorised users, but an accessible passport is not evidence that the information in it is correct or that the product complies. - Information non-compliance and substantive product non-compliance are different problems with materially different proportionate responses. - Correcting the published passport does not necessarily resolve the underlying compliance issue, and may not discharge the obligation. - Penalties are established within the framework set by the applicable EU legislation but are largely a matter of national law, so they differ across Member States. - Enforcement readiness is enterprise practice, not a regulatory certification: it is the ability to retrieve, explain, evidence and correct. This is the fifth article in the Regulations section, and it begins where [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory) leaves off. Framework TBF-038 The DPP Enforcement Lifecycle An educational model of how Digital Product Passport obligations move from an applicable legal requirement to supervision and, where necessary, enforcement, in eight stages: applicable requirement, market surveillance, information and product check, compliance assessment and finding, economic operator response, corrective or restrictive action, penalties and formal enforcement where applicable, and follow-up and continuing compliance. It is preceded by a legal applicability band distinguishing adoption, publication in the Official Journal, entry into force, date of application, transitional provisions, product-specific application, amendment, corrigendum and guidance, on the principle that no enforcement analysis is possible without an applicable requirement. It separates information non-compliance from substantive product non-compliance as educational categories, distinguishes corrective action from withdrawal and recall, distinguishes penalties from corrective measures, and treats market surveillance, conformity assessment and enforcement as distinct interacting concepts. It records that under the current EU framework common requirements are established by Union legislation while surveillance and enforcement are exercised substantially by competent authorities designated by Member States, supported by Union cooperation and information-exchange mechanisms. No EU instrument defines these eight stages and actual procedures depend on the applicable instrument, the product-specific measure, the product, the operator, the Member State, the nature and severity of the non-compliance and the powers available. It begins where the ESPR framework model TBF-005 and the delegated act lifecycle TBF-006 end, uses the product category rollout model TBF-007 and the compliance timeline TBF-008 to establish stage one, treats enterprise validation TBF-033 as distinct from market surveillance, draws on the evidence lifecycle TBF-034 where evidence validity or expiry becomes relevant, positions the assurance model TBF-035 as pre-emptive internal detection rather than enforcement, hands findings and data defects to the operating model TBF-036 as operational events, and relies on the programme governance model TBF-037 for internal authority over material regulatory responses without implying any influence over the powers of authorities. > **Educational scope** > > This article provides general educational information about EU product regulation concepts. It > does not determine the enforcement outcome for any particular organisation, product or market, and > it is not legal advice. How an authority acts in a specific case depends on facts, national > practice and the applicable legislation. ## Table of Contents * [Definition](#definition) * [From Legal Requirement to Enforcement](#from-legal-requirement-to-enforcement) * [When Does a DPP Requirement Become Enforceable?](#when-does-a-dpp-requirement-become-enforceable) * [Adoption, Publication, Entry into Force and Application](#adoption-publication-entry-into-force-and-application) * [The DPP Enforcement Lifecycle](#the-dpp-enforcement-lifecycle) * [Stage 1, Applicable Requirement](#stage-1--applicable-requirement) * [Stage 2, Market Surveillance](#stage-2--market-surveillance) * [Stage 3, Information and Product Check](#stage-3--information-and-product-check) * [The DPP as a Market-Surveillance Interface](#the-dpp-as-a-market-surveillance-interface) * [Stage 4, Compliance Assessment and Finding](#stage-4--compliance-assessment-and-finding) * [Stage 5, Economic Operator Response](#stage-5--economic-operator-response) * [Stage 6, Corrective or Restrictive Action](#stage-6--corrective-or-restrictive-action) * [Corrective Action vs Withdrawal vs Recall](#corrective-action-vs-withdrawal-vs-recall) * [Stage 7, Penalties and Formal Enforcement](#stage-7--penalties-and-formal-enforcement) * [Member State Competence](#member-state-competence) * [Cross-Border Market Surveillance](#cross-border-market-surveillance) * [Stage 8, Follow-Up and Continuing Compliance](#stage-8--follow-up-and-continuing-compliance) * [DPP Information Problems](#dpp-information-problems) * [Data Error vs Product Non-Compliance](#data-error-vs-product-non-compliance) * [Market-Surveillance Access to DPP Information](#market-surveillance-access-to-dpp-information) * [Evidence and Auditability](#evidence-and-auditability) * [Building Enforcement Readiness](#building-enforcement-readiness) * [Practical Example](#practical-example) * [Common Mistakes](#common-mistakes) * [Frequently Asked Questions](#frequently-asked-questions) * [Key Takeaways](#key-takeaways) * [Related Articles](#related-articles) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) * [About This Article](#about-this-article) ## Definition The use of powers and measures available under applicable EU and national law to address non-compliance with requirements that apply to a product placed or made available on the market, including requirements relating to product information such as a Digital Product Passport. Under the current EU framework these powers are exercised substantially by competent authorities designated by Member States, within the framework established by the applicable Union legislation. Three terms are used throughout this article and are frequently, and unhelpfully, treated as synonyms. **Market surveillance** is the activity through which competent authorities monitor and assess whether products placed or made available on the market comply with applicable requirements. It is an ongoing supervisory activity carried out after a product reaches the market. **[Conformity assessment](/docs/knowledge-base/glossary/conformity-assessment)** is the process used to demonstrate whether specified requirements relating to a product have been fulfilled. It is carried out in relation to the product itself, generally before it is placed on the market, and it is the responsibility of the relevant economic operator rather than of an authority. **Enforcement** is what may follow when surveillance identifies that requirements have not been fulfilled. It is the application of available legal measures. These interact. Conformity assessment produces the documentation and declarations that surveillance may examine. Surveillance may produce the finding that enforcement responds to. But they are not the same activity, they are not performed by the same parties, and they do not occur at the same point in a product's life. A deeper treatment of conformity assessment, [technical documentation](/docs/knowledge-base/glossary/technical-documentation), declarations, [harmonised standards](/docs/knowledge-base/glossary/harmonised-standard) and presumption of conformity is planned as a separate article in this pillar and is deliberately not attempted here. ## From Legal Requirement to Enforcement The regulatory journey has a shape that is easy to state and easy to skip. A legal instrument establishes a framework. A product-specific measure makes particular requirements applicable to particular products from a particular date. A product carrying those requirements is placed on the market. An authority, acting under national and Union law, may examine that product, its information or its documentation. That examination may produce a finding. The finding may require a response from the relevant [economic operator](/docs/knowledge-base/glossary/economic-operator). Depending on the nature and severity of the issue, and the powers available, measures may follow. And after measures, there is normally a follow-up question about whether the underlying cause has been addressed. Every step in that chain is conditional on the one before it. This matters more than it sounds, because the most common analytical error in this area is to start in the middle. Organisations ask "what is the penalty for a wrong passport value?" before establishing whether a passport requirement applies to that product at all, which authority would have competence, what the requirement actually demands, and whether the wrong value is an information defect or a symptom of something else. > **Start at the top of the chain, every time** > > When a question arrives about enforcement exposure, resist answering it directly. Establish the > applicable instrument, the applicable product-specific measure, the applicable date and the > applicable requirement first. In a large proportion of cases today the analysis stops there, > because no product-specific passport requirement is yet applicable to the product concerned. ## When Does a DPP Requirement Become Enforceable? A requirement can only be enforced as an obligation once it applies. That statement is trivial and constantly ignored. Under the current ESPR framework, ESPR itself establishes the power to require a Digital Product Passport, sets out what such a passport must be capable of doing, and provides the machinery through which requirements are set and supervised. For most product groups it does not, by itself, impose a passport obligation on any individual product. That step happens in a delegated act adopted for a specific product group, as explained in [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts). Each such act carries its own scope, its own requirements and its own date of application. Separately, some product-specific regimes exist outside ESPR and carry their own timing. The battery passport under Regulation (EU) 2023/1542 applies to the battery categories that regulation names from 18 February 2027. Construction products have their own regime under Regulation (EU) 2024/3110 with its own phasing. These are separate instruments with separate enforcement contexts, not subsets of ESPR. The practical consequence is that "is this enforceable?" is not a question about DPPs in general. It is a question about one product, one requirement, one instrument and one date. Two products in the same catalogue may have entirely different answers on the same day. Establishes the framework for setting ecodesign requirements, including the power to require a Digital Product Passport for specified product groups. For most product groups the product-level passport obligation, its content and its date of application are set in a subsequent delegated act. The application of ESPR itself does not create a passport obligation for an individual product. ## Adoption, Publication, Entry into Force and Application EU legal texts pass through several distinct moments, each with a different legal consequence. Treating them as one moment is the most reliable way to reach a wrong conclusion about exposure. | Moment | What it means | What it does not mean | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | | Adoption | The institutions have agreed the text | That the text is yet in the legal order, or that anything is due | | Publication | The text appears in the Official Journal of the European Union, establishing the authentic version and the clock | That obligations have begun | | Entry into force | The act becomes part of the Union legal order, commonly a set number of days after publication as stated in the act | That the obligations in it must yet be met | | Date of application | The date from which obligations must actually be met, which may be later than entry into force and may vary by provision | That every provision in the act starts on the same date, unless the act says so | | Transitional provisions | Arrangements moderating the change, for example for products already placed on the market | That every product benefits from them, or that they exist at all in a given act | | Product-specific application | The point at which a particular product group is brought into a requirement by the measure covering it | That neighbouring product groups are covered | | Amendment | A later act changes the text of an earlier one | That the consolidated version you are reading is itself the authentic legal text | | Corrigendum | A correction to a published text, which can change wording, cross-references or dates | That the version downloaded before the corrigendum is still accurate | | Guidance | Explanatory material issued to aid interpretation and application | That it is binding law, or that following it is a substitute for compliance with the act | Two of these are worth dwelling on because the audit of this library found them under-treated. **[Entry into force](/docs/knowledge-base/glossary/entry-into-force) is not the date of application.** Entry into force places the act in the legal order. The date of application is when the duty bites. For framework instruments the gap is deliberate and is the preparation period. Reading the first date as the second produces panic; reading the second as the first produces complacency. **Corrigenda exist and matter.** A published legal text can be corrected after publication, and the correction can touch operative wording, cross-references and dates. An organisation that downloaded a PDF at adoption and built a compliance interpretation on it may be working from a superseded text. Working from the consolidated version on EUR-Lex, and re-checking it before relying on a specific provision, is the only safe practice. The consolidated version is itself a documentation tool rather than the authentic text, which remains the version published in the Official Journal. #### Guidance is not law Commission guidance, FAQs, standardisation request documents and stakeholder materials are useful and often the clearest available explanation of intent. They do not create, extend or narrow legal obligations. Where guidance and the operative text of an act appear to diverge, the act governs. This distinction becomes acutely practical in an enforcement conversation, where "the guidance said we could" is not a defence to a requirement the act imposes. ## The DPP Enforcement Lifecycle The DPP Enforcement Lifecycle is a tieback educational model. It describes the logic by which an applicable requirement becomes a supervised requirement, and how a supervised requirement can become an enforced one. It is presented in eight stages. No EU instrument defines these eight stages. Actual procedures depend on the applicable legal instrument, the product-specific measure, the product, the economic operator, the Member State, the nature and severity of the non-compliance, and the powers available under applicable EU and national law. There is no single universal enforcement procedure applying identically to every future Digital Product Passport, and this article does not assert one. The stages are: 1. **Applicable requirement**, establishing that a requirement genuinely applies 2. **Market surveillance**, the supervisory activity of competent authorities 3. **Information and product check**, what may actually be examined 4. **Compliance assessment and finding**, what the examination concludes 5. **Operator response**, what the relevant economic operator provides or does 6. **Corrective or restrictive action**, measures where legally available and proportionate 7. **Penalties and formal enforcement where applicable**, consequences under national law within the Union framework 8. **Follow-up and continuing compliance**, confirmation, remediation and continued supervision tieback educational model, TBF-038 The DPP Enforcement Lifecycle From an applicable requirement, through surveillance and finding, to proportionate measures and continuing supervision. Not a statutory procedure. Legal applicability band, a requirement must apply before it can be enforced 1. Adoption 2. Official Journal 3. Entry into force 4. Date of application 5. Product-specific measure 6. Stage 1 Applicable requirement Competence Union legislation establishes common requirements. Designated Member State competent authorities exercise surveillance and enforcement. Union mechanisms support cooperation and information exchange. Market-surveillance authority track 1. Stage 2 Market surveillance Risk-based and reactive activity, online and offline 2. Stage 3 Information and product check Documentary check, information request, physical check 3. Stage 4 Compliance assessment and finding Compliant, further information required, or non-compliance identified Economic operator track 1. Stage 5 Operator response Provide information, explain, evidence, cooperate 2. Stage 6 Corrective or restrictive action Where legally available and proportionate Educational categories of finding, not formal universal statutory categories Information non-compliance Required information missing, incorrect, stale, inconsistent, inaccessible or wrongly classified for access Substantive product non-compliance The product itself does not meet an applicable requirement, whatever the passport says Proportionate measures, depend on instrument, severity, risk and powers * Correction of information * Bringing into compliance * Restriction of availability * Prohibition * Withdrawal * Recall * Stage 7 Penalties and formal enforcement, under national law within the Union framework Stage 8 Follow-up and continuing compliance, confirmation of remediation, corrected information, additional evidence, checks across affected product populations, continued monitoring. Returns to the applicable requirement: supervision does not end when an immediate issue is closed. Educational model. No EU instrument defines these eight stages. Actual procedures, findings and measures depend on the applicable legal instrument, the product-specific measure, the product, the economic operator, the Member State, the nature and severity of the non-compliance, and the powers available under applicable EU and national law. ## Stage 1, Applicable Requirement Nothing in the remaining seven stages can be reasoned about until this one is settled. The governing principle is simple: **no enforcement analysis without an applicable requirement.** Establishing applicability means answering, for a specific product, a specific set of questions. * **Which legislation applies?** ESPR, a sector instrument such as the batteries regulation, the construction products regime, or a combination. Different instruments create different obligations and different supervision contexts. * **Is the product within scope?** Scope is set in the instrument and, for ESPR, principally in the product-specific measure. The analysis in [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport) covers how product groups are prioritised and brought into scope; it is not repeated here. * **Which economic operator is concerned?** Placing on the market, making available, importing and distributing are different acts with different consequences. This article does not allocate responsibility between manufacturer, importer, distributor and [authorised representative](/docs/knowledge-base/glossary/authorised-representative); a dedicated treatment of legal responsibility is planned separately in this pillar. * **What exactly does the requirement demand?** A passport obligation is not monolithic. It may concern which information is included, how it is structured, who may access which parts, how it is linked to the product, and how long it remains available. * **From what date?** Established through the legal-effect analysis above and in [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory). * **Are there transitional provisions?** These may affect products already placed on the market before the date of application, and their treatment is set by the act concerned. * **Which delegated or implementing measures are relevant?** Under the current ESPR framework, product-specific requirements and certain technical arrangements are set through subsequent measures. Where those have not been adopted, the corresponding obligations do not yet apply. * **Have there been amendments or corrigenda?** Check the consolidated text and the corrigenda history before relying on a specific provision. #### Record the applicability determination, not just the conclusion Organisations routinely record "in scope" or "not in scope" against a product without recording which instrument, which measure, which provision and which date produced that answer. When an authority asks why a product was treated as it was, the conclusion is worthless without the reasoning. Treat the applicability determination as a governed record with an owner, a date and a review trigger, in the same way as any other regulatory decision. ## Stage 2, Market Surveillance Market surveillance is how competent authorities monitor and assess whether products on the market comply with applicable requirements. It is the ordinary supervisory background against which all product law operates, and it exists independently of whether any complaint has been made. The general Union framework for market surveillance of products covered by harmonisation legislation is set out in Regulation (EU) 2019/1020 on market surveillance and compliance of products. That regulation establishes, among other things, obligations on Member States to organise and carry out market surveillance, arrangements for the designation of [market surveillance authorities](/docs/knowledge-base/glossary/market-surveillance-authority) and single liaison offices, powers that authorities are to have available, cooperation mechanisms between authorities and between Member States, and arrangements concerning controls on products entering the Union market. Its application to any particular product depends on the Union harmonisation legislation covering that product, and ESPR sits within that landscape rather than replacing it. The practical shape of surveillance activity typically includes several distinct modes. **Risk-based programming.** Authorities operate with finite resources and generally plan activity using risk criteria, prioritising product categories, operators or channels where the likelihood or consequence of non-compliance is higher. The consequence for organisations is that supervision is not random in the way it is often assumed to be. A category with known compliance problems attracts attention. **Documentary checks.** Examination of information and documentation associated with a product, which may include information a passport is required to make available, without necessarily examining the physical product. **Physical product checks.** Examination of the product itself, which may extend to sampling and testing where the applicable rules and available powers provide for it. **Information requests.** Requests to economic operators for information or documentation. Where the applicable legislation provides for it, an operator may be required to provide specified information within a specified period. **Online market activity.** Products offered for sale online, including from outside the Union, raise supervision questions that authorities address through arrangements available under the applicable framework. This is an area of active development, and the specific mechanisms available depend on the applicable legislation. **Cooperation.** Between authorities within a Member State with different sectoral competences, between Member States, and with customs authorities in the context of products entering the Union market. > **Surveillance is continuous, not a one-off gate** > > A passport is not approved at publication and then left alone. Where information is required to > remain available and accurate for a defined period, the supervision window is that whole period. > This is why the operational disciplines described in the [DPP Operating Model](/docs/knowledge-base/implementation/how-to-operate-a-digital-product-passport-programme) > matter more than the launch project: the obligation outlives the implementation. ## Stage 3, Information and Product Check What an authority may examine depends on the applicable legislation and the powers available. The list below describes areas that may be relevant, not a checklist that every check follows. Most checks are narrow. Very few examine everything. * **Required product information.** Whatever the applicable requirement specifies must be provided. * **DPP information.** Where a passport requirement applies, the information the passport is required to carry, in the form and structure required. * **Identifiers.** Whether the required [product identifiers](/docs/knowledge-base/glossary/product-identifier) are present, correctly formed and correctly associated with the product concerned. * **[Data carrier](/docs/knowledge-base/glossary/data-carrier).** Whether the required carrier is present, physically durable as required, and resolves as required. * **Technical documentation.** The documentation the applicable legislation requires to be held and made available on request. * **Declarations.** Where a declaration is required, its presence, currency and consistency with the product and documentation. * **Supporting evidence.** Material substantiating claims and values, where the applicable rules require it to be held or provided. * **Conformity information.** Information relating to how conformity was assessed and demonstrated. * **Economic operator information.** Identification of the responsible operator and contact details where required. * **Access to required information.** Whether required information is actually accessible to those entitled to it, in the manner required. * **Consistency.** Whether the product, its markings, its passport information and its documentation tell the same story. The last of these is where problems are most often surfaced in practice. Individual artefacts are frequently defensible on their own and contradict each other when placed side by side. An authority does not need to prove a value wrong from first principles if the organisation's own documents disagree about it. #### The passport does not replace technical documentation A Digital Product Passport and technical documentation are different things with different purposes and different audiences. A passport makes specified information available to specified users, including in some cases the public. Technical documentation is the detailed body of material demonstrating how conformity was established, held and provided under conditions the applicable legislation sets. Publishing a passport does not discharge a technical documentation obligation, and a passport is not a complete technical file. ## The DPP as a Market-Surveillance Interface This concept deserves its own treatment because it is where enthusiasm most often outruns the law. A well-implemented passport can genuinely make supervision easier. Required information becomes structured rather than scattered across PDFs, product pages and email attachments. It becomes retrievable by identifier rather than by correspondence. Where the applicable requirement provides for differentiated access, it can be made available to the right categories of user, which may include authorities where the applicable legislation so provides. That is a real improvement over a world in which an authority's first step is a letter asking a company to find its own records. But four things must be stated plainly, because each is a live misconception. **A DPP is not an enforcement system.** It is a source of information that may be examined. It does not perform checks, reach conclusions or impose consequences. Nothing about publishing a passport places an organisation in a supervisory relationship it was not already in. **A DPP is not conformity assessment.** The passport may carry information about conformity. It does not establish conformity, and its existence says nothing about whether the assessment behind it was correct or even performed. **A DPP is not a complete technical file.** As above. The passport is a defined subset of information made available in a defined way. **A DPP is not proof that its contents are correct.** This is the most important of the four. A passport can be technically flawless, resolvable, well-structured, complete against the required field list, correctly access-controlled, and contain a value that is wrong. Technical accessibility is a property of the delivery mechanism. Accuracy is a property of the information, and it comes from the data governance, validation and evidence disciplines upstream. The converse is also true and is regularly forgotten: a product may have compliance problems that are not discoverable from the passport at all. A substantive product failure sits in the product, not in the record describing it. An organisation that treats passport quality as its compliance programme has confused the window for the room. #### Two products, opposite profiles Product A has an exemplary passport: every required field present, evidence linked, carrier durable, access tiers correctly configured. One recycled-content figure was carried over from a superseded supplier declaration and is overstated. The passport is excellent and the information is wrong. Product B has a clumsy passport with awkward formatting and a slow resolver, and every value in it is correct and fully evidenced. The passport is poor and the information is sound. A documentary check may well raise questions about B's presentation. A substantive check is far more likely to create a problem for A. ## Stage 4, Compliance Assessment and Finding Where a check has taken place, an authority reaches some conclusion. The categories below are descriptive and educational. They are not universal statutory classifications, and the findings available, their names and their consequences depend on the applicable legislation and national procedure. * **Compliant.** The matters examined met the applicable requirements, so far as examined. This is not a certificate and does not extend to matters not examined. * **Further information required.** The check could not be concluded on the material available. Frequently this is not an allegation of anything; it is a request. * **Documentary deficiency.** Required documentation or information was absent, incomplete or not provided in the required form. * **Incorrect or inconsistent information.** Information provided does not match the product, does not match other documentation, or is internally inconsistent. * **Unavailable required information.** Information that should have been available was not, whether because it was never created, was not retained, or could not be produced. * **Inaccessible required information.** The information exists but could not be reached by those entitled to reach it, for example because a carrier does not resolve or an access configuration is wrong. * **Suspected substantive product non-compliance.** Indications that the product itself does not meet an applicable requirement, which typically triggers a materially different and more serious path. * **Other non-compliance under applicable rules.** Anything else the applicable legislation recognises. An important nuance: the boundary between "further information required" and "non-compliance identified" is often determined by the operator's own response speed and quality. A request answered promptly, completely and coherently frequently ends the matter. The same request answered late, in fragments, with internally inconsistent attachments, tends to widen it. ## Stage 5, Economic Operator Response Depending on the legal basis, the procedure and the powers available, the relevant economic operator may be required, or invited, to do some combination of the following. * Provide specified information within a specified period * Provide documentation, including technical documentation where the applicable rules require it * Explain discrepancies between the product, its information and its documentation * Correct information that is wrong, incomplete or out of date * Demonstrate that applicable requirements have been fulfilled * Cooperate with the authority on measures to address identified non-compliance * Take corrective action Whether any given item in that list is a legal requirement or a practical request in a specific case depends on the applicable legislation, the powers of the authority concerned, and the national procedure. Those distinctions matter legally, and this article does not flatten them. What this article deliberately does not do is allocate these duties between manufacturer, importer, distributor, authorised representative, fulfilment service provider and online marketplace. That allocation is a substantial legal topic in its own right, it varies by instrument and by the act the operator performs, and it is the subject of a planned separate article in this pillar. The relevant point here is that **somebody has to be able to answer**, and that organisations frequently discover during a live request that they had not decided in advance who that is. #### Decide the response path before you need it The single most valuable preparation for Stage 5 is unglamorous: a named accountable owner, a defined internal route for an incoming authority request, a known location for each category of required information and evidence, and an agreed escalation threshold. The [DPP Programme Governance Model](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme) covers how internal decision authority for material regulatory responses should be established. It determines who inside the organisation decides. It has no bearing on the powers of the authority. ## Stage 6, Corrective or Restrictive Action Where non-compliance is identified, a response may follow. What response is available depends entirely on the applicable legislation, and what response is appropriate depends on the facts. The measures below appear across EU product legislation in various forms. Their availability, precise definition and procedural conditions are set by the applicable instrument, and the summaries here are high-level rather than statutory. * **Correction of information.** Where the defect is in required information, correcting it may be the proportionate response, sometimes combined with confirmation of the correction and evidence of its basis. * **Bringing the product into compliance.** Action to make the product itself meet the applicable requirement, where that is possible. * **Restricting availability.** Limiting the making available of the product on the market, pending resolution or otherwise. * **Prohibition.** Preventing the product being made available on the market. * **Withdrawal.** Measures aimed at preventing a product in the supply chain from being made available on the market. * **Recall.** Measures aimed at achieving the return of a product that has already been made available to the end user. The determinants of which measure, if any, is appropriate are consistent across the framework: * the applicable legislation and the powers it provides * the nature of the non-compliance, particularly whether it is informational or substantive * the severity of the non-compliance * the risk presented, including any risk to health, safety or the environment * the number and distribution of affected products * the operator's response, including speed, completeness and cooperation * the powers available to the authority concerned, including under national law **A DPP data error does not automatically produce a recall.** This is the single most damaging misconception in this area, and it distorts internal risk conversations badly. Recall is a serious measure aimed at products already with end users, generally reserved for situations where the severity and risk justify it. A stale recycled-content percentage in a published passport is, on its face, an information problem. It may become more than that if investigation shows the underlying product does not meet an applicable requirement, but the escalation comes from the investigation, not from the existence of the error. ## Corrective Action vs Withdrawal vs Recall These three terms are used interchangeably in ordinary business language and are not interchangeable in product law. At a high level, and subject to the definitions in the applicable instrument: | Term | What it generally concerns | Where the product is | Typical trigger | | --------------------- | -------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **Corrective action** | Action taken to address identified non-compliance | Anywhere, including still in the operator's control | Any identified non-compliance, informational or substantive | | **Withdrawal** | Measures aimed at preventing a product in the supply chain from being made available on the market | In the supply chain, not yet with end users | Non-compliance where continued availability is not acceptable | | **Recall** | Measures aimed at achieving the return of a product that has already been made available to the end user | With end users | Non-compliance where leaving products in use is not acceptable, typically involving risk | Two observations follow. **[Corrective action](/docs/knowledge-base/glossary/corrective-action) is the broad category; [withdrawal](/docs/knowledge-base/glossary/withdrawal) and [recall](/docs/knowledge-base/glossary/recall) are specific measures.** Every withdrawal and every recall involves corrective action. The reverse is emphatically not true, and the great majority of corrective action involves neither. **The distinction between withdrawal and recall is essentially about where the product has reached.** Withdrawal operates on the supply chain. Recall operates on products already made available to end users, which is why it is more disruptive, more expensive and more consequential, and why it is generally reserved for correspondingly serious situations. The definitions in the applicable instrument govern in any real case. These summaries are orientation, not legal definitions, and should not be quoted as such. ## Stage 7, Penalties and Formal Enforcement Penalties for infringements of EU product legislation are generally a matter for Member States, within the framework the applicable Union legislation establishes. A common pattern in Union product law is a requirement that Member States lay down rules on penalties applicable to infringements and take the measures necessary to ensure they are implemented, with those penalties required to be effective, proportionate and dissuasive. Where the applicable legislation contains such a provision, that formulation, and any additional criteria the instrument sets, governs. Several consequences follow, and each corrects a common assumption. **There is no single EU-wide fine for DPP non-compliance.** The amounts, the mechanisms, the procedures and the appeal routes are established in national law. Two Member States can respond to comparable facts with materially different consequences. **This article does not state penalty amounts.** Any figure quoted generically for "DPP non-compliance" across the EU should be treated as unreliable. The applicable amounts, where they exist, are found in the national implementing law of the Member State concerned. **A penalty and a corrective measure are not the same thing.** A corrective measure addresses the non-compliance: fix the information, bring the product into compliance, withdraw it. A penalty is a sanction for the infringement. A case may involve corrective action without any monetary penalty. It may involve a penalty in addition to corrective action. It may, depending on applicable law and the facts, involve other enforcement consequences entirely. These are separate questions decided on separate bases. **Commercial consequences frequently precede legal ones.** A retailer delisting a product, a customs control at the border, a platform removing a listing or a customer invoking a contractual compliance warranty can each impose costs long before any formal penalty process concludes. In practice these are often the consequences organisations actually experience. #### Not every non-compliance results in a fine Enforcement is not a vending machine in which an error produces a penalty. Authorities operate with limited resources, proportionality obligations and, generally, an interest in achieving compliance rather than in collecting sanctions. A first, minor, promptly corrected informational defect from a cooperative operator sits at a very different point on that spectrum from a substantive product failure, a repeated pattern, or an operator who cannot produce the information at all. ## Member State Competence This is the structural fact that most explanations of DPP enforcement omit, and it changes how the whole topic should be understood. **EU legislation establishes common requirements.** Regulations apply across the Union and create a common substantive standard. That is the purpose of a single market: the same product requirement applies whether the product is placed on the market in Lisbon or Tallinn. **Member States designate competent authorities.** Under the applicable framework, Member States are responsible for organising and carrying out market surveillance, and for designating the authorities that perform it, along with arrangements such as single liaison offices where the applicable legislation provides for them. Which authority is competent for a given product may depend on the sector, and a single Member State may have several. **Surveillance and enforcement occur through those authorities.** They plan and conduct checks, reach findings, engage with operators and apply measures available to them. This is where the actual supervisory relationship exists. **National procedures and penalties may be relevant.** Administrative procedure, notification requirements, response deadlines, rights of appeal, evidentiary standards and sanctions are substantially matters of national law. They differ. **Union mechanisms support coordination and information exchange.** The framework provides for cooperation between authorities and Member States, mechanisms for sharing information about non-compliant products and measures taken, and structures supporting a consistent approach. These support national enforcement rather than substituting for it. Two errors follow from ignoring this. The first is imagining a European inspectorate that examines passports centrally: it does not exist, and the Commission does not perform that role. The second is the opposite error of assuming that because enforcement is national, twenty-seven identical processes exist. They do not. The substantive requirement is common; the machinery around it is not. > **Map your competent authorities before you need them** > > An organisation placing products on the market in several Member States has several potential > supervisory relationships, not one. Knowing which authority is competent for which product > category in which market, and what the national response expectations are, is a small piece of > preparation that is extremely awkward to perform for the first time under a deadline in a language > the compliance team does not read. ## Cross-Border Market Surveillance Products and economic operators move across the single market; supervisory competence does not move with them. A product manufactured in one Member State, imported through a second, warehoused in a third and sold online into a fourth creates an obvious coordination problem, and the framework addresses it through cooperation rather than centralisation. At a high level, and subject to the applicable legislation: **Cooperation between authorities.** Authorities in different Member States are provided with arrangements for mutual assistance and cooperation, so that an authority encountering a problem is not limited to what it can do alone within its own territory. **Information sharing.** The framework provides for the exchange of information about non-compliant products and about measures taken, so that a finding in one Member State can inform activity in others. The practical consequence for organisations is significant: a problem identified in one market may become visible in several. **Cross-border cases.** Where the responsible operator, the product and the supervising authority are in different Member States, arrangements exist for handling the case across borders. The specifics depend on the applicable legislation and the nature of the issue. **Products entering the Union market.** Controls at the external border, and cooperation between market surveillance authorities and customs authorities, form part of the framework under Regulation (EU) 2019/1020. For products manufactured outside the Union this is a meaningful supervision point, and one where missing or unverifiable information has immediate practical consequences. **Products offered online across borders.** Distance selling, including from outside the Union, raises specific questions that the framework addresses through the arrangements available under the applicable legislation. This area continues to develop, and the mechanisms available depend on the applicable instruments. The framework is designed to reduce the incentive to treat the least active supervisory environment as the effective standard. It should not be described as centralised enforcement, because it is not. ## Stage 8, Follow-Up and Continuing Compliance Enforcement does not necessarily end when the immediate issue is corrected. Depending on the applicable legislation, the measure taken and the authority's approach, follow-up may involve: * **Confirmation of remediation.** Evidence that what was required has actually been done, not an assertion that it has. * **Updated information.** Where information was wrong, the corrected information and, where relevant, its basis. * **A corrected passport.** Where the passport carried the defect, the published information brought into line with reality, noting that under a snapshot model, correcting the published artefact may require a fresh publication rather than an in-place edit. * **Additional evidence.** Substantiation for the corrected position, which is frequently the harder part. * **Continued monitoring.** An operator or product category that has produced a finding may attract further attention. * **Checks across affected product populations.** If one product had the defect, the obvious question is how many others share its root cause. This question is asked internally by any competent programme and may also be asked externally. * **Supplier remediation.** Where the defect originated upstream, addressing it at source rather than at publication. * **Process changes.** Where the defect was systemic, changing the process that produced it. * **Assurance.** Establishing that the change worked. * **Operational monitoring.** Detecting recurrence. The internal disciplines that make follow-up survivable are described elsewhere in this library and are not recreated here. [Data validation](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data) determines whether information is suitable for use before it is published. [Evidence management](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports) determines whether a published claim can be substantiated when asked, and whether its supporting evidence is still valid. [Assurance](/docs/knowledge-base/implementation/how-to-test-and-assure-a-digital-product-passport) determines whether the organisation finds its own problems before anyone else does. The [operating model](/docs/knowledge-base/implementation/how-to-operate-a-digital-product-passport-programme) determines whether findings, evidence expiries and data defects are handled as routine operational events rather than as crises. And [programme governance](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme) determines who inside the organisation has authority to accept risk, approve a material regulatory response and escalate. None of these is enforcement. All of them determine how badly enforcement goes. ## DPP Information Problems The categories below are tieback educational categories, not statutory classifications. No EU instrument defines them. They are useful because they separate problems that look identical on a dashboard and behave completely differently under examination. For each, the regulatory significance depends entirely on the applicable requirement and the context. The same defect can be trivial in one product group and serious in another. **1. Missing information.** A required element is absent. Significance depends on whether the element is required by the applicable measure, and whether its absence prevents a required function. An absent optional attribute and an absent mandatory attribute are not comparable. **2. Incorrect information.** A value is present but wrong. Significance depends on what the value is and what turns on it. An incorrect contact email and an incorrect substance-of-concern declaration occupy opposite ends of the range. **3. Stale information.** The value was correct when published and is no longer. Significance depends on whether the applicable requirement expects the information to reflect current reality, and on whether the underlying evidence remains valid. Staleness is the failure mode most often missed, because nothing in the system changed, the world did. **4. Inconsistent information.** The same fact appears differently in the passport, the technical documentation, the label and the product page. Significance is often higher than the individual values suggest, because inconsistency undermines confidence in everything else and invites a broader examination. **5. Inaccessible information.** The information exists but cannot be reached by those entitled to reach it: a carrier that does not resolve, a resolver outage, a broken link, an authentication failure. Significance depends on whether the applicable requirement expresses an availability duty, which passport requirements characteristically do. **6. Incorrect access classification.** Information is exposed to a category of user that should not see it, or withheld from a category that should. Both directions are defects. Over-exposure can create commercial and legal problems beyond product law; under-exposure can constitute failure to make required information available. **7. Unsupported claim.** The value may well be correct, but the organisation cannot substantiate it, because the evidence has expired, was never obtained, or cannot be located. This is distinct from incorrectness, and it is the category that most often converts a routine request into a serious problem. **8. Identifier or association error.** The information is correct but attached to the wrong thing: the wrong batch, the wrong variant, the wrong serial. Significance is frequently high, because it means the correct information for the product in front of the authority is not what they are looking at, and it typically indicates a systemic problem rather than an isolated one. > **Classify before you escalate** > > These eight categories are worth building into internal triage. The internal response to a stale > value, an unsupported claim and an identifier association error should be quite different, and > organisations that treat all data defects as one queue consistently over-react to cosmetic > problems and under-react to structural ones. ## Data Error vs Product Non-Compliance A defect in passport information can indicate several quite different underlying situations, and the distinction is central to a proportionate response. **An information-compliance issue.** The information required to be provided was not provided correctly. The product may be entirely compliant. The defect is in the record. **A process failure.** The information is wrong because the process that produced it is unreliable: a manual re-keying step, an unmapped supplier field, a publication pipeline that picked up a draft value. The immediate product may be fine and the process will produce the same error again. **An underlying product-compliance issue.** The information is wrong because the product does not have the property claimed. Here the record is accurately reporting the wrong reality, or inaccurately concealing it. These are not automatically identical, and treating them as identical is expensive in both directions. #### One value, three different situations A passport states 42 percent recycled content. Investigation could establish any of the following. First, the correct figure is 42 percent and the supporting declaration simply expired and needs renewing, an evidence problem, with the value intact. Second, the correct figure is 38 percent and 42 was transposed from a different variant during publication, an information and process problem, with the product unaffected. Third, the material specification changed at the supplier eighteen months ago and actual recycled content is now 12 percent, which may be a substantive compliance problem if the applicable requirement sets a threshold, and which the passport was concealing rather than causing. The published symptom is identical in all three. The proportionate regulatory response is not. The operational implication is direct: an organisation that responds to a data finding by correcting the value and closing the ticket has, in two of those three cases, done nothing about the actual problem. Investigation determines which case applies, and the investigation is the work. ## Market-Surveillance Access to DPP Information Where an applicable requirement provides for authorities to have access to specified passport information, the architecture has to support that access as a designed capability rather than as an accident of implementation. The relevant architectural properties are covered in depth in [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture) and are summarised here only in their enforcement aspect. **Access differentiation.** Where the applicable requirement distinguishes categories of user and what each may see, that distinction must be implemented, testable and auditable. An organisation should be able to demonstrate what a given category of user sees, not assert it. **Resolution reliability.** If a carrier does not resolve when scanned, required information is not available, whatever exists in the underlying systems. Availability is an obligation characteristic of passport requirements, and availability is an operational property. **Identifier integrity.** Access begins with an identifier. If the identifier resolves to the wrong product, batch or variant, everything downstream is wrong in a way that is difficult to detect and serious when detected. The material in [What is a Product Identifier?](/docs/knowledge-base/standards-and-technology/what-is-a-product-identifier) and [What is a Data Carrier?](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) covers the underlying mechanics. **Traceability.** [Product traceability](/docs/knowledge-base/glossary/product-traceability) supports the question that follows almost every finding: which other products are affected? **Retention and historical access.** Where information must remain available for a period, historical states may matter as much as the current one. A passport regime that only ever exposes the latest version may be unable to answer what a product's information said at the time it was placed on the market. One caution on standards. GS1 identification standards and GS1 Digital Link are widely used, are well suited to this problem, and are discussed at length in the Standards and Technology section of this library. They are industry standards, not law. Neither GS1 nor GS1 Digital Link is automatically mandatory for a Digital Product Passport. A specific applicable legal measure would have to require a particular approach for it to be obligatory, and whether any given measure does so is a question to answer from the text of that measure. Choosing a widely adopted standard is usually a sound engineering decision; describing it as a legal requirement, absent a measure that says so, is not accurate. ## Evidence and Auditability Enforcement readiness depends on far more than the published view of a passport. The published view is a rendering. What matters under examination is whether the organisation can account for it. For a given value in a given passport, an organisation may need to demonstrate: * **Source.** Where the value came from, whether an internal system, a supplier declaration, a test report or a calculation. * **Ownership.** Who is accountable for the value being right. * **Evidence.** What substantiates it, and where that evidence is. * **Validity.** Whether the evidence was valid at the relevant time and whether it remains valid now. * **Version.** Which version of the value applied at which point. * **History.** What the value was previously and when it changed. * **Decision.** Who approved publication, on what basis and under what authority. * **Correction.** What was corrected, when, why and by whom. * **Publication state.** What was actually published and visible, to whom, at a given time. The library covers each of the underlying disciplines separately: [product data governance](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance) for ownership and decision rights, [system of record](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record) and [authoritative source](/docs/knowledge-base/glossary/authoritative-source) for provenance, [data validation](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data) for fitness before publication, the [evidence lifecycle](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports) for substantiation and expiry, the [assurance model](/docs/knowledge-base/implementation/how-to-test-and-assure-a-digital-product-passport) for pre-emptive detection, the [operating model](/docs/knowledge-base/implementation/how-to-operate-a-digital-product-passport-programme) for handling findings as routine events, and [programme governance](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme) for internal authority. None of them is recreated here. The point for enforcement purposes is narrower and blunter: an organisation that can produce this account quickly is in an entirely different position from one that cannot, even when the underlying facts are identical. ## Building Enforcement Readiness Enforcement readiness is enterprise practice. It is not a regulatory certification, no authority awards it, and claiming to be "enforcement ready" has no legal standing whatsoever. It is simply the capability to respond appropriately when an authority examines a product or requests information. In practice it comprises: * **Knowing applicable requirements.** For each product, which instrument, which measure, which requirement, from which date, recorded, owned and reviewed rather than assumed. * **Knowing accountable operators.** Who, legally and internally, is answerable for each product in each market. * **Retrieving required information.** Producing the required information for a specific product quickly, without a reconstruction project. * **Retrieving supporting documentation and evidence.** The harder half of the previous point. * **Demonstrating provenance.** Showing where a value came from and who owns it. * **Explaining decisions.** Accounting for why the organisation treated a product, a requirement or a value as it did. * **Correcting problems.** A controlled path from identified defect to corrected published state, with the correction itself evidenced. * **Controlling publication.** Knowing exactly what is published, to whom, and being able to change it deliberately rather than accidentally. * **Escalating material findings.** A defined threshold and route, decided in advance. * **Retaining appropriate records.** For the period the applicable requirement expects, including historical states. #### Rehearse a request The most informative exercise available to a DPP programme costs almost nothing: pick a product at random, and give the team a realistic information request with a realistic deadline. Most organisations discover that the information exists, the evidence is somewhere, and nobody can assemble the two into a coherent answer inside the time available. That discovery is far cheaper in a rehearsal than in a live request. ## Practical Example A manufacturer places a product on the EU market that is subject to an applicable product-specific Digital Product Passport requirement. The example assumes that requirement applies, which, as Stage 1 establishes, is the first thing to verify and is not true for most product groups today. **Applicable requirement.** The product-specific measure covering this product group applies from a date now passed. The measure requires specified sustainability attributes to be included in the passport and to be available to specified categories of user. The organisation has recorded the applicability determination, the measure and the date. **Market surveillance.** A competent authority in a Member State where the product is made available includes the product category in a planned activity. The selection is risk-based rather than prompted by a complaint. **DPP and documentary check.** The authority scans the carrier. The passport resolves. The required attributes are present and the structure matches the requirement. On its face this is a good result. The authority then requests substantiation for one attribute: a recycled-content figure. **Discrepancy identified.** The supporting declaration underpinning that figure expired fourteen months ago. The published value has continued to be displayed since. The value may still be correct; it is currently unsupported. In the classification above this is an unsupported claim, potentially combined with staleness. **Operator response.** The manufacturer acknowledges the request within the period given, identifies the accountable owner, and states clearly what it can and cannot currently substantiate. It does not assert the figure is fine, and it does not silently edit the published passport while the request is open. **Evidence and source investigation.** Internally the organisation traces the value to its source. Three questions are asked. Is the figure still accurate? Has the material specification changed at the supplier? Why did an expiring declaration not trigger a review before it lapsed? The third question is the important one, because it determines how many other products share the defect. Suppose the investigation establishes that the material specification did not change, the figure remains accurate, a current supplier declaration can be obtained, and the expiry was missed because evidence validity was not monitored, a control gap affecting an identified population of products. **Corrective response.** The manufacturer obtains a current declaration, confirms the value, identifies the other products exposed to the same control gap, and implements evidence-expiry monitoring so the failure mode does not recur. **Passport information updated or other action as appropriate.** The published passport is re-published so that the visible information rests on current evidence. Under a snapshot model this is a new publication rather than an in-place edit, and the correction is itself recorded. **Validation and assurance.** The corrected information passes validation before publication, and assurance confirms both that the specific product is now sound and that the control gap has actually been closed across the affected population. **Follow-up.** The manufacturer provides the authority with the substantiation and an account of the corrective action. The authority may accept that as resolving the matter, may seek confirmation of the wider remediation, or may include the operator in future activity. **What did not happen.** No recall. No fine. No withdrawal. The defect was informational, the value proved accurate, the operator responded promptly, and the response was proportionate. That outcome is not guaranteed, it depends on applicable law, on the authority and on the facts, but the assumption that any passport defect ends in recall or penalty is not how proportionality works. #### Contrast: a substantive finding Change one fact. Investigation establishes that the supplier changed the material specification eighteen months ago, actual recycled content is materially below the published figure, and the applicable requirement sets a minimum threshold the product does not meet. This is no longer an information problem. The passport was accurately formatted and substantively wrong, and the product itself may not meet an applicable requirement. The affected population is every unit produced since the specification changed, some of which are with end users. Correcting the published value now makes the passport accurate and makes the compliance position worse, because it documents a product that does not meet the threshold. The proportionate response here could extend well beyond correction, potentially to restriction of availability, withdrawal, or where severity and risk justify it recall, alongside penalties under national law. Same starting symptom. Entirely different regulatory situation. Only investigation distinguished them. ## Common Mistakes #### The European Commission checks every DPP It does not, and it is not structured to. Under the current framework the Commission's role concerns the legal framework, product-specific measures, coordination and cooperation. Market surveillance and enforcement are exercised substantially by competent authorities designated by Member States. Expecting a central inspectorate leads organisations to prepare for the wrong relationship and to overlook the national authorities that actually matter to them. #### A QR-code scan automatically determines compliance Scanning a carrier retrieves information. It does not evaluate that information against a requirement, verify it against reality, or reach a conclusion. The scan is the beginning of a check, not the check. #### If a DPP is accessible, the product is compliant Accessibility is a property of the delivery mechanism. Compliance is a property of the product and of the information. A perfectly accessible passport can carry incorrect information about a non-compliant product. #### A DPP replaces technical documentation They are different obligations with different scopes and different audiences. A passport makes specified information available in a specified way. Technical documentation demonstrates how conformity was established. Neither discharges the other. #### Every DPP data error means the product must be recalled Recall is a specific measure aimed at products already with end users, and it is generally reserved for situations whose severity and risk justify it. Most information defects are addressed by correction. Escalation depends on the nature and severity of the non-compliance, the risk, the affected population and the operator's response. #### Every non-compliance results in a fine Corrective measures and penalties are separate. A case may involve corrective action with no monetary penalty, a penalty in addition to corrective action, or other consequences depending on applicable national law and the facts. #### All Member States use exactly the same enforcement process The substantive requirement is common across the Union; the machinery around it is not. Administrative procedure, deadlines, evidentiary expectations, appeal routes and penalties are substantially matters of national law and differ between Member States. #### Market surveillance and conformity assessment are the same Conformity assessment demonstrates that specified requirements relating to a product have been fulfilled, is generally performed before placing on the market, and is the operator's responsibility. Market surveillance is authority activity monitoring products already on the market. Different actors, different timing, different purpose. #### If a regulation has entered into force, every product-specific DPP requirement already applies Entry into force places an act in the legal order. The date of application determines when obligations must be met, and under the current ESPR framework most product-level passport obligations depend on a product-specific measure that must itself be adopted and apply. The framework applying is not the obligation applying. #### A working plan creates an immediate product obligation A [working plan](/docs/knowledge-base/glossary/working-plan) sets a rule-making agenda. It signals that work is scheduled for a product group. It is not an obligation, it does not set a compliance date, and it cannot be enforced against a product. #### Guidance is the same as law Guidance explains and aids application. It does not create, extend or narrow legal obligations, and where it appears to diverge from the operative text of an act, the act governs. #### GS1 Digital Link is automatically mandatory for every DPP GS1 standards, including GS1 Digital Link, are industry standards. They are widely used and well suited to this problem, and they are not automatically legally mandatory. A specific applicable legal measure would have to require a particular approach, and whether one does is a question to answer from that measure's text. #### Correcting the public DPP always resolves the underlying compliance issue Correcting the published value addresses the symptom. If the value was wrong because evidence had lapsed, because a process is unreliable, or because the product does not have the property claimed, the correction leaves the actual problem untouched, and in the last case may document a non-compliant product more clearly than before. Investigation determines what the correction is actually correcting. ## Frequently Asked Questions #### Who enforces Digital Product Passport requirements? Under the current EU framework, enforcement is exercised substantially by competent authorities designated by Member States, operating within the framework established by the applicable Union legislation, including Regulation (EU) 2019/1020 on market surveillance and compliance of products for the products it covers. Which authority is competent depends on the Member State and frequently on the product sector. Customs authorities also play a role in relation to products entering the Union market. #### Will the European Commission inspect individual DPPs? That is not how the framework is structured. The Commission's role concerns the legal framework, the adoption of product-specific measures, and coordination and cooperation between Member States. It does not operate as a product inspectorate examining individual passports or issuing penalties to individual companies for passport defects. #### Can market-surveillance authorities access DPP information? Where the applicable requirement provides for it, yes, and the design intent of a passport regime includes making specified information available to specified categories of user, which can include authorities. The specifics of what must be accessible to whom are set by the applicable legislation and the relevant product-specific measure, so the answer for a given product comes from that measure rather than from a general principle. #### What happens if DPP information is wrong? It depends on what "wrong" means and what turns on it. An incorrect or unsupported value may lead to an information request, an opportunity to explain and correct, and corrective action. Where the defect indicates that the product itself does not meet an applicable requirement, the situation is materially more serious and a wider range of measures may be available. The first step in practice is investigation to determine which situation applies. #### Can a product be recalled because of an incorrect DPP? Recall is a measure aimed at achieving the return of products already made available to end users, and it is generally reserved for situations whose severity and risk justify it. An isolated informational defect, promptly corrected, is not the typical route to recall. Where a passport defect reveals substantive product non-compliance presenting real risk, the range of available measures is much wider. The trigger is the underlying situation, not the existence of a data error. #### Are there fines for DPP non-compliance? Penalties for infringements are generally established by Member States within the framework the applicable Union legislation sets, commonly with a requirement that they be effective, proportionate and dissuasive. There is no single EU-wide fine for DPP non-compliance, and the applicable amounts and mechanisms are found in the national law of the Member State concerned. Any generic pan-EU figure quoted for "DPP fines" should be treated with suspicion. #### Are penalties the same across all EU Member States? No. The substantive product requirement is common across the Union, but penalties, administrative procedures, deadlines and appeal routes are substantially matters of national law and differ. An organisation active in several Member States should expect several different enforcement environments applied to the same underlying requirement. #### What is the difference between market surveillance and conformity assessment? Conformity assessment is the process used to demonstrate that specified requirements relating to a product have been fulfilled; it is the operator's responsibility and generally happens before the product is placed on the market. Market surveillance is the activity by which competent authorities monitor and assess whether products on the market comply. One produces the evidence; the other examines it. A dedicated article on conformity assessment is planned for this pillar. #### Does a DPP replace technical documentation? No. They are distinct obligations serving distinct purposes. A passport makes specified information available to specified users. Technical documentation is the body of material demonstrating how conformity was established, retained and provided under the conditions the applicable legislation sets. Producing one does not discharge the other. #### Does entry into force mean a DPP requirement immediately applies? No. Entry into force places an act in the Union legal order. The date of application is when obligations must be met, and it is often later. Under the current ESPR framework, most product-level passport obligations additionally depend on a product-specific delegated act, which must itself be adopted, enter into force and reach its own date of application. #### Can authorities check products sold online? Products offered for sale online, including from outside the Union, are within the concern of the market surveillance framework, and arrangements exist for addressing them. The specific mechanisms available depend on the applicable legislation, and this is an area that continues to develop. The practical point for organisations is that an online sales channel is not outside supervision. #### What should an organisation do if an authority identifies a DPP problem? Acknowledge within the period given; identify the accountable owner; establish precisely what is being asked and on what legal basis; investigate the underlying cause rather than only the published symptom; be candid about what can and cannot currently be substantiated; avoid silently editing published information while a request is open; take corrective action through a controlled and evidenced path; and consider the affected population beyond the single product examined. Internal authority for material responses should already be established through programme governance rather than improvised. ## Key Takeaways * Enforcement under the current EU framework is exercised substantially by competent Member State authorities. The European Commission is not a product inspectorate and does not examine individual passports. - No enforcement analysis is possible until an applicable requirement is established: the instrument, the product-specific measure, the scope, the requirement and the date. - Adoption, publication, entry into force and date of application are four different moments with four different consequences, and corrigenda can change a published text after the fact. - Market surveillance, conformity assessment and enforcement are distinct concepts performed by different parties at different times. - A passport can be a useful surveillance interface, but it is not an enforcement system, not conformity assessment, not a technical file, and not proof that its contents are correct. - Information non-compliance and substantive product non-compliance are materially different problems, and only investigation distinguishes them. - Corrective action is the broad category; withdrawal concerns products in the supply chain and recall concerns products already with end users. A data error does not automatically produce a recall. - Penalties are largely national within the framework Union legislation sets, so they differ by Member State, and a penalty is not the same thing as a corrective measure. - Enforcement readiness is enterprise practice, not a certification: retrieve, explain, evidence, correct, and know who decides. ## Related Articles * [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory) * [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts) * [Who Is Legally Responsible for a Digital Product Passport?](/docs/knowledge-base/regulations/who-is-legally-responsible-for-a-digital-product-passport) * [How Conformity Assessment Works for Digital Product Passports](/docs/knowledge-base/regulations/how-conformity-assessment-works-for-digital-product-passports) * [What is the Ecodesign for Sustainable Products Regulation (ESPR)?](/docs/knowledge-base/regulations/what-is-the-ecodesign-for-sustainable-products-regulation-espr) * [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport) * [Corrective Action](/docs/knowledge-base/glossary/corrective-action) * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) ## Related Glossary Terms Definitions of record for the terms used above live in the [glossary](/docs/knowledge-base/glossary/overview). * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [ESPR](/docs/knowledge-base/glossary/espr) * [Delegated Act](/docs/knowledge-base/glossary/delegated-act) * [Economic Operator](/docs/knowledge-base/glossary/economic-operator) * [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance) * [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [Data Carrier](/docs/knowledge-base/glossary/data-carrier) * [Product Traceability](/docs/knowledge-base/glossary/product-traceability) * [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle) * [Product Data](/docs/knowledge-base/glossary/product-data) * [Data Quality](/docs/knowledge-base/glossary/data-quality) * [Data Governance](/docs/knowledge-base/glossary/data-governance) * [Authoritative Source](/docs/knowledge-base/glossary/authoritative-source) * [System of Record](/docs/knowledge-base/glossary/system-of-record) * [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data) ## References * Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) * Regulation (EU) 2019/1020 on market surveillance and compliance of products, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2019/1020/oj](https://eur-lex.europa.eu/eli/reg/2019/1020/oj) * Regulation (EU) 2023/1542 concerning batteries and waste batteries, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2023/1542/oj](https://eur-lex.europa.eu/eli/reg/2023/1542/oj) * Regulation (EU) 2024/3110 laying down harmonised rules for the marketing of construction products, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/3110/oj](https://eur-lex.europa.eu/eli/reg/2024/3110/oj) * Regulation (EC) No 765/2008 setting out the requirements for accreditation, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2008/765/oj](https://eur-lex.europa.eu/eli/reg/2008/765/oj) * Decision No 768/2008/EC on a common framework for the marketing of products, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/dec/2008/768/oj](https://eur-lex.europa.eu/eli/dec/2008/768/oj) * Regulation (EU) 2023/988 on general product safety, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2023/988/oj](https://eur-lex.europa.eu/eli/reg/2023/988/oj) * European Commission, ESPR working plan 2025 to 2030, COM(2025) 187: [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025DC0187) * European Commission, market surveillance and product compliance policy pages: [https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance\_en](https://single-market-economy.ec.europa.eu/single-market/goods/building-blocks/market-surveillance_en) * Treaty on the Functioning of the European Union, Article 290, delegated acts: [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A12012E%2FTXT](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A12012E%2FTXT) ## About This Article About This Article
Last Reviewed
2026-08-09
Next Scheduled Review
2027-08-09
Article Version
1.0
tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve. ## Related Docs * [Regulations](/docs/knowledge-base/regulations/overview) * [What is the Ecodesign for Sustainable Products Regulation (ESPR)?](/docs/knowledge-base/regulations/what-is-the-ecodesign-for-sustainable-products-regulation-espr) * [What Are Delegated Acts?](/docs/knowledge-base/regulations/what-are-delegated-acts) * [Which Products Will Require a Digital Product Passport?](/docs/knowledge-base/regulations/which-products-will-require-a-digital-product-passport) * [When Will Digital Product Passports Become Mandatory?](/docs/knowledge-base/regulations/when-will-digital-product-passports-become-mandatory) * [Who Needs a Digital Product Passport?](/docs/knowledge-base/digital-product-passports/who-needs-a-digital-product-passport) * [How Will Digital Product Passports Change Product Compliance?](/docs/knowledge-base/standards-and-technology/how-will-digital-product-passports-change-product-compliance) * [How to Manage Evidence for Digital Product Passports](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports) * [How to Govern a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme)