The EU Digital Product Passport is already established as a framework, but a framework does not give every lighting product the same immediate passport obligation. For a specific lamp or luminaire, the binding scope, required fields, data level, access rights, carrier placement and application date depend on the applicable product rules adopted under the Ecodesign for Sustainable Products Regulation (ESPR).
Lighting manufacturers and importers should therefore separate two questions: “What is legally required for this product now?” and “Which data controls should we build before a product-specific rule arrives?” The second question can be acted on today without describing a QR code or online datasheet as proof of DPP compliance.
Confirm applicability before building a passport
The European Union’s Regulation (EU) 2024/1781 creates the DPP architecture. Article 9 connects the passport obligation to applicable delegated acts, while Articles 10 and 11 set requirements for data carriers, identifiers, access and interoperability. The European Commission’s 2025–2030 working plan identifies priority work, but a work-plan entry is not itself the final product requirement.
Create a dated applicability record for each product family. It should cite the current source, describe the product and intended market, identify the owner of the decision and state what would trigger review. Avoid family-wide conclusions when different models may fall under different product categories or delegated acts.
| Gate | Question to answer | Evidence to retain |
|---|---|---|
| Framework | Which ESPR provisions govern the DPP architecture? | Regulation version and relevant articles |
| Priority work | Is the product group under preparation or review? | Commission work plan and study status |
| Product rule | Has an applicable delegated act been adopted? | Scope, data fields, access rules and dates |
| SKU decision | Does this exact configuration fall within scope? | Dated classification and product identity |
The LED product compliance document checklist can be used to separate regulations, declarations, reports, labels and instructions while the DPP-specific rule set develops.
Build a stable model identity
A passport cannot be more reliable than the identity behind it. One selling name often covers different powers, drivers, optics, dimensions or market variants. If those differences are hidden, a passport may point to evidence that does not represent the shipped product.
Define model, family, variant, batch and item levels before assigning identifiers. Record which level controls each data field. A dimension may be model-specific, a material declaration may follow a component revision, and a test report may represent only named variants.
The EU ErP Class A LED filament bulb illustrates why an efficiency-oriented product description is only one part of the record. The exact configuration, verified performance, components, declarations, instructions and market data still need controlled identifiers and revisions.
Define a field-level data model
Do not begin by uploading PDFs to a portal. Begin with a field dictionary. Each field should have a definition, unit, format, source, responsible owner, review rule, access level and retention period. This exposes conflicts that a document folder can hide.
| Data group | Example fields | Primary control |
|---|---|---|
| Identity | Model, GTIN, variant, batch and responsible operator | Unique values and hierarchy |
| Technical | Dimensions, power, output, controls and replaceable parts | Unit, method and configuration |
| Compliance | Market scope, declarations, reports and label data | Applicability and document revision |
| Materials | Component composition and substances information | Supplier source and coverage |
| Service | Installation, maintenance, repair and end-of-life data | Audience, language and version |
| Governance | Owner, source, access class, approval and retention | Audit trail and change trigger |
Use controlled units and enumerated values where possible. Do not store “same as previous model” as a value. A machine-readable field needs an explicit relationship, not an informal note.
Assign evidence ownership across the supply chain
The luminaire manufacturer may own the final product identity, while driver, LED, housing or packaging data originate elsewhere. A laboratory can verify a tested sample but does not control later production changes. The importer may be responsible for market information that is absent from the factory file.
For every field, name the source and the party that approves its use. When supplier evidence is reused across models, document the coverage conditions. The supplier evaluation guide explains why a complete-looking document package does not by itself prove mass-production consistency or effective change control.
Separate public, restricted and operational information
ESPR allows product-specific rules to define which actors can access which data. A consumer, installer, repairer, recycler, customs authority and market-surveillance authority may not need the same view. Confidential supplier data should not be made public merely because it supports an internal conclusion.
| Access class | Typical purpose | Design question |
|---|---|---|
| Public | Product identity, use and selected sustainability information | Can a customer understand the field without internal context? |
| Role-restricted | Compliance, repair or supply-chain information | How is the actor authenticated and authorized? |
| Operational | Source records, reviews and internal calculations | Can the published value be reconstructed and audited? |
Access design must not break traceability. A public value should still resolve internally to its approved source, even when the source document is restricted.
For project-oriented luminaires, the commercial and retail lighting solutions page provides an application context for deciding which installation, control and service fields buyers may need alongside product-level records.
Connect engineering change control to data updates
Component substitutions, current-setting changes, optical revisions, firmware updates, packaging changes and supplier transitions can alter several fields at once. The data process should identify affected models and evidence before publication.
Do not overwrite the previous state. Retain the effective date, production boundary and superseded record so a buyer or authority can identify which data applied to a particular unit or batch. The US general service lamp readiness guide addresses a different jurisdiction, but its model-identity and change-control method shows how evidence can remain tied to production.
Run a representative data pilot
Select one family with several meaningful variants and at least one realistic component change. The pilot should test whether the team can answer five questions without manual reconstruction:
- Which configuration does this identifier represent?
- Which source supports each published field?
- Who approved the field and on what date?
- What changes require review or republication?
- Can the previous state be retrieved for an earlier batch?
Use the pilot to compare systems only after the identity and governance rules are clear. A platform can distribute data; it cannot resolve undefined model relationships or unsupported values. New Lights’ factory and manufacturing overview provides context for discussing model files, production revisions and inspection controls, while the download centre is the practical destination for currently released product documents.
Frequently Asked Questions
Do all lighting products already require an EU Digital Product Passport?
No. ESPR establishes the framework, but the obligation for a specific product depends on the applicable delegated act, its scope and its application date. Check the current legal position for the exact product.
Is a QR code the same as a compliant DPP?
No. A QR code is only a possible data carrier. Compliance also depends on the applicable fields, identity level, access rights, accuracy, availability, interoperability and other requirements in the relevant rules.
Should every technical document be public?
Not automatically. Product-specific rules may define different access rights. Build field-level access classes while preserving an internal evidence trail for every published value.
What should a lighting supplier prepare first?
Start with controlled model identity, a field dictionary, source ownership and change management. These controls remain useful even while product-specific DPP requirements are still being developed.
Prepare data that can survive a rule change
For a lighting data-readiness review, contact New Lights with the intended EU product families, market variants, current identifiers, available declarations and document sources. The useful first output is a controlled data map with gaps and owners—not a generic “DPP-ready” label.
