A QR code is not compliance. A verifiable credential is.
Most DPP tools hand you a QR code linked to a PDF. EU customs and market surveillance authorities need to verify cryptographically signed, machine-readable data — not a landing page. PassportLab issues real Digital Product Passports built on the standards regulators actually check against.
This is a real, signed Digital Product Passport
Not a mockup. Open the link below on your phone and scan it like an inspector would.
Every PassportLab passport is a W3C Verifiable Credential, resolvable via a GS1 Digital Link, with a full EPCIS event history and cryptographic proof of who issued it and when. What you see on the phone is exactly what a customs officer or market surveillance authority sees.
- Cryptographically signed Ed25519 signature, verifiable by any third party without contacting PassportLab.
- GS1 Digital Link Resolves from the same QR code printed on the product label.
- Full audit trail Every change to the passport is logged with an immutable, timestamped EPCIS event.
- Registry-ready Structured to the format the live EU DPP Registry expects at submission.
A QR code pointing at a PDF is not what the regulation asks for
ESPR and the Battery Regulation both specify machine-readable, structured, verifiable data — not a static document behind a link.
PDFs disguised as passports
A QR code that opens a PDF or a marketing page satisfies nobody once an inspector actually checks it against the regulation's data model.
No cryptographic proof
Without a signed credential, there's no way to prove the data hasn't been altered after issuance — or who actually issued it.
Dead links at audit time
Passports hosted on throwaway infrastructure or a vendor that shuts down leave you with a broken link exactly when an authority asks for it.
Locked-in data
Some tools won't export your structured data at all, leaving you unable to switch providers or self-host once you've built up your catalogue.
No update path
Delegated acts under ESPR and the Battery Regulation are still being finalized. A static PDF can't absorb a schema change; a versioned passport can.
Four pillars regulators actually check
Every one of these is independently verifiable — by an auditor, a customs system, or a competitor's engineer — without ever talking to PassportLab.
Verifiable identity & signatures
Every passport is a W3C Verifiable Credential 2.0, signed with Ed25519 and tied to a DID:Web identity for your organization. Selective disclosure via SD-JWT lets you share only the fields a given party needs to see.
Open interoperability
Passports resolve via GS1 Digital Link — the same identifier layer customs and retail systems already use — and expose their event history through GS1 EPCIS 2.0, mapped to the UNTP DPP 0.7.0 data model for cross-registry compatibility.
Tamper-evident by design
Every passport version is fingerprinted with a SHA-256 snapshot and written to an immutable audit trail enforced at the database level — not just in application code that can be bypassed.
Full supply chain context
Passports track every economic operator and stakeholder role in the chain, linked to EORI numbers and NANDO-listed conformity bodies where relevant, via EPCIS 2.0 events.
Everything PassportLab issues, checked against a published spec
No proprietary format. Every claim below can be verified independently against the public standard it references.
The passport itself is issued as a W3C Verifiable Credential 2.0 — the same open standard used for digital identity documents and diplomas, not a PassportLab-specific JSON blob.
The QR code on the product resolves through GS1 Digital Link, the identifier standard already used across retail and logistics — no proprietary resolver required.
Every lifecycle event — manufacture, shipment, repair, recycling — is recorded as a GS1 EPCIS 2.0 event, queryable independently of PassportLab's own interface.
The passport's data structure maps to the UN Transparency Protocol's Digital Product Passport specification, keeping it portable across registries beyond the EU.
Sensitive fields — supplier identities, cost data — can be shared selectively using SD-JWT, so a customs check and a retail partner don't see the same payload.
PassportLab issuers are identified through DID:Web, a decentralized identifier anchored to your own domain, not a PassportLab account ID.
Battery passport schemas map directly to Annex XIII of Regulation (EU) 2023/1542, ahead of the 18 February 2027 enforcement date.
Non-battery product passports are built against the Ecodesign for Sustainable Products Regulation (EU) 2024/1781, versioned for delegated acts still being finalized.
The 5 questions that separate a real DPP from a QR code
These are the exact questions we'd want answered if we were buying a compliance tool instead of building one.
Is the passport a signed credential, or a link to a hosted page?
Can I export my structured data and leave, at any time?
What happens when the delegated acts change the schema?
Does the passport track the full supply chain, or just my product?
Is the audit trail enforced at the database level, or just in the app?
Features by role
Compliance & legal teams
- Guided data collection mapped to Annex XIII and DIN DKE SPEC 99100 fields
- Gap reports showing exactly what's missing before a submission
- Audit-ready export of every passport version and change
- Regulatory update tracking as delegated acts are finalized
Engineering & IT teams
- REST API and webhooks for ERP and PLM integration
- Standards-native output — W3C VC, GS1 EPCIS 2.0, UNTP — no proprietary SDK to learn
- Role-based access control and stakeholder API keys
- Sandbox environment for testing before go-live
Supply chain & operations
- Supplier data request templates that cite the exact regulation article
- Stakeholder roles for manufacturers, importers, and recyclers
- GS1 Digital Link QR codes ready for label printing
- EU DPP Registry submission and proof-of-registration
What it actually takes to do this in-house
Most teams underestimate this by months, not weeks.
| Requirement | PassportLab | In-house build |
|---|---|---|
| Signed, verifiable credentials | Included — W3C VC 2.0 out of the box | Requires implementing a PKI and credential-issuance stack |
| GS1 Digital Link & EPCIS 2.0 | Included, pre-mapped | Requires a GS1 integration project, typically months |
| EU DPP Registry submission | Guided registration and proof-of-registration | Manual integration against the Registry API |
| Schema updates for delegated acts | Applied centrally, passports update automatically | Manual redevelopment each time a delegated act is adopted |
| Data ingestion from messy sources | Human-reviewed mapping from PDFs, spreadsheets, ERP exports | Custom ETL pipeline your team has to build and maintain |
| Time to first compliant passport | Weeks, not quarters | Typically 6–12 months for a first working pipeline |
| Ongoing regulatory monitoring | Included via retainer | Requires a dedicated compliance hire or consultant |
Grounded in the process, not just the regulation text
We track the standards bodies and registries directly, not just the headline deadlines.
EU DPP Registry
Live since 20 July 2026. PassportLab passports are structured to its registration format and API from day one.
DIN DKE SPEC 99100
Our battery passport schema maps explicitly to all seven data clusters — the working basis for the coming delegated acts.
CEN/CLC JTC 24
Built against the six EN standards recognised in July 2026, including EN 18222 for the interface and API layer.
BatteryPass-Ready (Fraunhofer IPK)
Our JSON exports are tested against the 11 BatteryPass-Ready scenarios for EV, LMT, and stationary storage batteries.
Frequently asked
Do I need a technical team to use PassportLab?
No. The platform is designed for compliance and operations teams. For messy source data — PDFs, spreadsheets, ERP exports — our team handles the mapping directly rather than asking you to self-serve a data model you don't have.
What happens if the delegated acts change after I've issued passports?
Passports are versioned documents. When a schema updates, your existing passports update behind the same QR code — you never need to reprint labels.
Is my data locked into PassportLab?
No. Full structured export (JSON/CSV) of every product and passport is available on demand, with no lock-in.
How is this different from a QR-code generator?
A QR-code generator points at a hosted page. PassportLab issues a signed, standards-based Verifiable Credential with a full audit trail — the format regulators and market surveillance authorities are built to check.
Can this cover multiple product categories?
Yes. The schema is built per product category — batteries, textiles, electronics, iron & steel — each mapped to its own regulatory basis and deadline.
See your product's passport, not a mockup
Book a 20-minute call, or start with a free demo passport — no account required.
Standards notice: Standards status: EN 18216:2026–EN 18223:2026 — including the data-carrier standard EN 18220 and the data-persistence standard EN 18221 — were published by CEN/CENELEC on 27 May 2026. In July 2026, CEN/CLC JTC 24 formally recognised six of these EN standards, including EN 18222 (interface/API layer). They are not yet cited in the Official Journal of the EU, so they do not yet confer formal presumption of conformity. EN 18239 (access rights) and EN 18246 (data authentication) remain in draft, expected late 2026. ESPR (EU 2024/1781) delegated acts and per-category Annex I requirements are still being finalised. CBAM Reg. 2023/956 obligations continue to evolve under Commission guidance. Results are a readiness indication based on the latest available standards and drafts, and do not constitute legal advice.