What is verified about the standard
BSI lists BS EN 18219:2026 as current, published on 31 May 2026. Its public scope addresses product, operator and facility identifiers, including persistence and different identification levels.
The reference EN 18219:2026 appears as entry 2 in the Annex to Decision (EU) 2026/1736, published on 15 July 2026. Under ESPR Article 41(2), the associated presumption of conformity extends to covered requirements. Publication is not certification of a particular platform or identifier.
Source: BSI: BS EN 18219:2026, publication status and public scopeSource: European Commission: harmonised standards for Digital Product PassportsSource: Commission Implementing Decision (EU) 2026/1736, Article 1 and AnnexSource: Regulation (EU) 2024/1781: Articles 9–11 and 41
Name the objects before choosing a format
Create an inventory of what your organisation needs to identify: the product object, its manufacturer, a production facility and the published record may be related but are not the same thing. Write a short explanation for each identifier used in an export or on a label. If two teams mean different objects by “product ID”, resolve that before integration.
Keep a stable object identity separate from a record revision. A corrected manual usually changes the information about an object, not the object itself. Likewise, a reseller article number can be a useful alias without becoming the permanent identity shared with every downstream partner.
Compare schemes through operational questions
Our recommendation is to assess candidate identifier schemes through responsibilities and failure modes, not appearance. Ask who allocates values, which namespace prevents overlap, who can retire an identifier and what happens after a supplier or organisational change. A unique column in one database does not demonstrate uniqueness across trading partners.
Check the scheme against applicable legal and standard requirements using the full documents. Do not assume that using a familiar barcode, a UUID or a vendor-generated string settles that assessment. Keep the chosen scheme, its version and the responsible reviewer in a decision record.
- Who can allocate a new identifier, and who reviews exceptions?
- Can two imports from different plants introduce the same value?
- Are leading zeroes, case and punctuation preserved through every exchange?
- What replaces an allocation service if its contract ends?
Test failures that a normal demo misses
Prepare a small set of deliberately awkward records before migration: duplicate supplier numbers, similar values differing only in case, identifiers with leading zeroes and the same article supplied by two sites. Trace each through import, review, export, printing and resolution. Confirm the intended distinction survives every step.
Test repeated submissions and partial failures. A retry should not accidentally create a second identity for the same intended object. Conversely, a system should not silently merge distinct objects because a convenient display name matches. These are proposed engineering tests, not claims about numbered clauses in EN 18219.
Plan continuity before changing systems
List the places where an existing identifier appears: packaging, certificates, customer exports, service records and published links. Decide which legacy values remain aliases and which new values require a distinct record. Keep the reasoning visible so a future team can distinguish a correction from an identity change.
Rehearse a migration with a few real records. Scan an old carrier after moving the backing data and check the intended passport still appears. Review domain ownership and operational handover separately from the data export. An archive that nobody can resolve is insufficient for the user holding a physical label.
Make the decision reviewable in Passvanta
In a Passvanta pilot, keep the product, its source documents and published revisions connected, and verify the resolver address generated for the intended object. Compare that address with the identifier carried through your supplier and customer processes. Review exceptions rather than changing established identities to make an import look tidy.
The acceptance package should identify the chosen scheme, tested scenarios, responsible owner and remaining gaps. This guide has only used public standard metadata and scope; a formal clause-by-clause review needs the complete standard. Neither a generated identifier nor a successful software check establishes complete EN 18219 conformity or EU registry acceptance.