QR vs NFC vs RFID vs DataMatrix
The carrier decision is made once and paid for on every unit. It is driven by where the product is read and by who is holding it, not by which technology sounds most advanced.
QR vs NFC vs RFID vs DataMatrix| Carrier | Unit cost | Read range | Survives | Best for |
|---|
| QR code | Effectively zero when printed | Line of sight, one at a time | Printing and normal handling | Consumer-facing products, packaging, care labels |
| DataMatrix | Zero when direct-part marked | Line of sight, very small area | Disassembly and abrasion | Circuit boards, moulded housings, small components |
| NFC tag | Cents to a euro per unit | Touch | Laundering and flexing | High-value goods where authentication matters |
| UHF RFID | Cents per unit | Metres, many at once | Dirt, speed and bulk handling | Steel coil, tyres, pallets, anything read in motion |
RecommendationDefault to QR and justify anything else. It costs nothing to add, every phone reads it, and the regulation names it explicitly for batteries. Add NFC only where authentication earns the unit cost, and use RFID where nobody will stop to aim a camera.
Digital Product Passport vs product carbon footprint
These are routinely conflated in procurement conversations, usually because both arrive as a sustainability request. They answer different questions and one contains the other.
Digital Product Passport vs product carbon footprint| Dimension | Digital Product Passport | Product carbon footprint |
|---|
| Question answered | What is this product, made of what, handled how | What did one unit emit |
| Scope | Materials, origin, chemistry, repair, end of life, and carbon | Greenhouse gases only |
| Legal driver | ESPR and the Battery Regulation | CSRD, customer requirement, and specific product rules |
| Audience | Consumers, recyclers, regulators, trading partners | Customers, auditors, disclosure |
| Lifespan | The product’s whole life, updated as facts change | A calculation with a stated boundary and vintage |
RecommendationTreat the footprint as one attribute inside the passport rather than a parallel project. Companies that run them separately end up with two different carbon numbers for the same product and no way to say which is correct.
Distributed ledger vs conventional database for passport data
The most consequential architecture decision in the category, and the one most often made on the basis of what sounds credible in a pitch rather than what the regulation requires.
Distributed ledger vs conventional database for passport data| Requirement | Distributed ledger | Conventional store | Which wins |
|---|
| Correcting a wrong supplier figure | Cannot be removed | Straightforward, with history | Conventional store |
| Honouring an erasure request | Impossible by design | Standard capability | Conventional store |
| Proving a record existed on a date | Native | Requires a trusted third party | Ledger |
| Revocation nobody can silently reverse | Native | Depends on the operator | Ledger |
| Cost at supply-chain event volume | Prohibitive per event | Negligible | Conventional store |
RecommendationKeep the records in a system that can correct them, and publish only digests and revocation status to a ledger. Anything else trades a compliance obligation you have for a property you did not need.
Data space vs shared ledger for supply chain data
Automotive answered this question at scale with Catena-X and did not choose a chain. The reasoning generalises to most cross-company passport data.
Data space vs shared ledger for supply chain data| Concern | Data space | Shared ledger |
|---|
| Where data lives | In each company’s own systems | Replicated to every participant |
| Access control | Negotiated per exchange | Broadly all-or-nothing per network |
| Commercially sensitive data | Stays under the owner’s control | Exposed to the participant set |
| Onboarding a new participant | A connector and a policy | Governance, nodes and often a token |
| Proving prior state | Needs a separate anchor | Native |
RecommendationUse a data space or plain APIs for the data, and a ledger only for the proof. Most of what buyers expect a shared ledger to do is better done by a resolver, a signature and an access policy.
Item-level vs batch-level vs model-level passports
The decision that determines how many identifiers you serialise, what a scan can tell the holder, and how expensive a change of mind will be.
Item-level vs batch-level vs model-level passports| Level | What a scan identifies | Carrier cost | Required for |
|---|
| Item | This exact unit and its own history | One unique carrier per unit | Batteries above 2 kWh, high-value goods, resale |
| Batch | The lot this unit came from | One carrier design per lot | Food and chemicals, where recall is by lot |
| Model | The product design and its generic data | One carrier design per model | Most textiles and general consumer goods |
RecommendationChoose the lowest level the obligation and the use case actually require. Item level is the only option for batteries, and the only level that supports resale and repair history — but it multiplies serialisation and carrier work across the whole line.
Self-declared vs third-party verified claims
Both are legitimate. Presenting one as the other is what turns a sustainability claim into a greenwashing exposure.
Self-declared vs third-party verified claims| Dimension | Self-declared | Third-party verified |
|---|
| Who signs | The party that benefits from the claim | An accredited body with something to lose |
| Cost and lead time | Low, immediate | Material, weeks to months |
| Weight with market surveillance | Accepted where the instrument allows it | Stronger, and required for some claims |
| Typical use | Material composition, care information | Carbon footprint declarations, recycled content |
RecommendationRecord which it is, per claim, in the passport itself. The failure mode is not self-declaration — it is a reader assuming a self-declared figure was audited because nothing on the page said otherwise.
Chain of custody models for recycled content
Four models, all standardised, all legitimate — and they mean very different things about what is physically in the product a customer is holding.
Chain of custody models for recycled content| Model | Is the material physically present? | Cost to operate | Typical use |
|---|
| Identity preserved | Yes, from a single source | Highest | Premium provenance claims |
| Segregated | Yes, from certified sources | High | Certified timber, organic fibres |
| Controlled blending | Partly, at a known ratio | Moderate | Blended fibre and board |
| Mass balance | Not necessarily | Lowest | Chemical recycling, bulk polymers |
RecommendationPick the cheapest model that supports the claim you actually want to make, then state it explicitly beside the figure. A mass-balance number published as though it were segregated is the claim most likely to be challenged.
MCI vs recycled content vs repairability index
Three numbers routinely averaged into one "circularity score". They are measured on different scales and answer different questions, and combining them produces a figure no standard recognises.
MCI vs recycled content vs repairability index| Metric | Scale | What it measures | Method |
|---|
| Material Circularity Indicator | 0 to 1 | Recycled input, reuse potential and lifetime combined | Ellen MacArthur Foundation |
| Recycled content | Percent by mass | Share of recovered material in the product | ISO 14021, with a chain-of-custody model |
| Repairability index | 0 to 10 | Disassembly, fasteners, spare parts, repair information | EN 45554 |
RecommendationReport all three separately and name the method beside each. If a single headline figure is unavoidable for a board pack, publish it as a composite with its formula shown — never as "circularity".
Building a passport platform vs buying one
A fair comparison, including the parts that favour building. The decision usually turns on how many product groups you have and how fast the delegated acts are moving.
Building a passport platform vs buying one| Factor | Build | Buy |
|---|
| Time to first passport | Quarters | Weeks |
| Tracking delegated acts | Your team reads the Official Journal | Vendor obligation, and checkable |
| Standards implementation | GS1, EPCIS and W3C all built and maintained in-house | Inherited, and testable during evaluation |
| Fit to unusual products | Exact | Depends on the data model’s flexibility |
| Long-run cost | Ongoing engineering and regulatory monitoring | Licence, and switching cost if portability is weak |
RecommendationBuild only if you have one product group, deep in-house standards capability and a genuinely unusual data model. Otherwise the regulatory monitoring alone — not the software — is what makes buying cheaper.
Where to anchor a passport digest
Only relevant once you have accepted that the records themselves stay off the ledger. At that point the choice is about governance, finality and who has to accept the proof.
Where to anchor a passport digest| Network type | Governance | Finality | Best when |
|---|
| EU public permissioned | European Commission with member states | Immediate on inclusion | A European authority has to accept the timestamp |
| Sector consortium | Your own consortium | Immediate on inclusion | The sector already runs a shared ledger |
| Public proof-of-work timestamping | None | Probabilistic, about an hour | The proof must outlive every party to it |
| Public rollup | Settles to a public chain | Soft in seconds, hard after a challenge window | Anchoring often enough that fees decide frequency |
RecommendationDefault to the EU permissioned network for regulatory anchors, and publish the same root to a public timestamping service as well. Two anchors cost almost nothing and stop any single network becoming a dependency.
Hash anchoring vs storing data on a ledger
Both are described as putting product data on a blockchain and they are materially different. One publishes a fingerprint; the other publishes the record, with consequences that are difficult to reverse.
Hash anchoring vs storing data on a ledger| Property | Anchoring a hash | Storing data on-ledger |
|---|
| What is published | A salted fingerprint only | The record itself |
| Correcting an error | Normal — publish a new version and anchor | Impossible by design |
| Erasure of personal data | Possible — the data is under your control | Conflicts with erasure rights |
| Commercial confidentiality | Preserved | Lost, permanently |
| Cost per record | Negligible via a Merkle tree | Per transaction |
RecommendationAnchor hashes selectively where a dispute with a distrusting party is plausible, and keep the data in a conventional versioned store. Storing regulated product data on a public ledger conflicts with both erasure rights and the requirement to correct errors.
Supplier portal vs machine-to-machine exchange
How you collect supplier data determines how much of it you get. The right mechanism depends on the supplier’s capability rather than on your preference, and using one mechanism for everybody guarantees poor coverage.
Supplier portal vs machine-to-machine exchange| Mechanism | Suits | Supplier effort | Data currency |
|---|
| Direct system exchange | Suppliers with integration capacity | One-off build | Always current |
| Scheduled file exchange | Suppliers with systems, no integration capacity | Low, recurring | As fresh as the schedule |
| Portal entry | Suppliers with limited systems | High, recurring | Stale between submissions |
| Conversation and manual entry | Very small suppliers | Minimal | Whenever you ask |
RecommendationMatch the mechanism to the supplier rather than standardising on a portal. A portal succeeds only where you are a major customer, and manual entry on your side beats a portal invitation a small supplier will never open.
LCA, PCF, EPD and PEF compared
Four terms used interchangeably in conversation that mean different things in practice. The difference is mostly about how much methodological freedom each allows, which determines whether two results can be compared.
LCA, PCF, EPD and PEF compared| Term | What it is | Method fixed by | Verified? |
|---|
| LCA | A full environmental assessment | Practitioner choices within ISO | Not necessarily |
| PCF | A single-issue carbon result | Practitioner or a sector rule | Not necessarily |
| EPD | A published declaration | A product category rule | Third-party verified |
| PEF | An EU harmonised method | A category rule, sixteen impacts | Depends on the scheme |
RecommendationAsk which category rule a figure follows before comparing it with anything. Two competent LCAs of similar products can differ by a large factor through legitimate choices, which is exactly the problem category rules exist to solve.
Reuse, repair, remanufacture and recycle
Four recovery routes with different legal standing, different warranties and different economics. They are used loosely in marketing and precisely in regulation, and the difference matters commercially.
Reuse, repair, remanufacture and recycle| Route | What happens | Performance claim | Waste hierarchy tier |
|---|
| Reuse | The product is used again as-is | None made | Prevention |
| Repair | A specific fault is corrected | Restored function | Preparing for reuse |
| Remanufacture | Disassembled and restored to specification | At least as new | Preparing for reuse |
| Recycle | Reduced to material | None — the product ends | Recycling |
RecommendationBe precise in published claims, because these terms carry different warranty and liability consequences. Describing refurbishment as remanufacturing implies a warranty equivalent to new, which only a controlled documented process can actually support.
Which regulation gives your product its passport
Three separate instruments create digital product passports, and which one reaches you decides your timing, your data set and the framework you work within. Teams routinely assume ESPR covers everything.
Which regulation gives your product its passport| Instrument | Covers | Route into scope | Built on |
|---|
| ESPR (EU) 2024/1781 | Most product groups, over time | A delegated act per group | A new framework |
| Battery Regulation (EU) 2023/1542 | LMT, EV and industrial batteries | Directly, by category | Battery-specific rules |
| CPR recast (EU) 2024/3110 | Construction products | Directly, alongside ESPR | Declarations of performance |
| Toy safety framework | Toys | Directly, via safety rules | Existing safety evidence |
RecommendationCheck all four rather than assuming ESPR. Construction and batteries are already fixed and do not wait for a delegated act, and a manufacturer of battery-powered construction products sits under two regimes with different data sets at once.
Item, batch or model level identity
The issuance level decides what questions your data can ever answer, and it is the hardest decision to reverse because it is printed onto physical goods. Getting it wrong is discovered years later.
Item, batch or model level identity| Level | Answers | Cannot answer | Marking cost |
|---|
| Model | What this product is | Anything about a specific unit | Lowest |
| Batch | Which production run, for recalls | Which unit within the run | Low |
| Item | The full history of one unit | Nothing — but costs most to operate | Highest |
RecommendationBias toward the finer level when costs are close, because the asymmetry is severe. Item data aggregates to batch whenever you want it to, while batch data can never be refined to item level for units already in the field.
Self-declared, signed and third-party verified
Three levels of assurance behind a published figure. All three are legitimate and they are not equivalent evidence, which matters when a buyer is comparing two numbers that look identical on screen.
Self-declared, signed and third-party verified| Level | What it proves | What it does not | Cost |
|---|
| Self-declared | The manufacturer asserts it | That anybody checked | Minimal |
| Signed credential | Who asserted it, unaltered since | That the claim is true | Low |
| Third-party verified | An independent party checked | That it applies to this batch | Substantial |
RecommendationSign everything and verify selectively. A signature costs almost nothing and makes a claim portable beyond your own website, while third-party verification should be reserved for the figures a buyer or authority is most likely to contest.
Centralised registry vs federated resolution
Where passport data lives and who resolves it. The debate is usually framed ideologically and the practical consequences are about availability, control and what happens when an organisation disappears.
Centralised registry vs federated resolution| Model | Who holds data | Failure mode | Suits |
|---|
| Central registry | One operator | Single point of failure and governance dispute | Regulated registers |
| Federated resolution | Each manufacturer | Records vanish if a company fails | Most manufacturers |
| Federated plus anchoring | Each manufacturer, hashes public | Data still vanishes; proof survives | Long-lived products |
RecommendationFederated resolution is the practical default because manufacturers already control their own product data. The unresolved gap in every model is what happens to records when a company ceases to exist, which no individual programme can fix alone.
When repair beats replacement commercially
The environmental answer is usually repair and the commercial answer frequently is not. Understanding which factor tipped a specific decision is what lets a manufacturer change the outcome rather than lament it.
When repair beats replacement commercially| Factor | Favours repair | Favours replacement | Who controls it |
|---|
| Diagnosis time | Fault codes published | Investigation from scratch | Manufacturer |
| Part price | Priced against the fault | A large fraction of product price | Manufacturer |
| Part availability | In stock, short lead time | Discontinued or slow | Manufacturer |
| Labour access | Reversible fasteners | Bonded or welded assembly | Designer |
| Product price trend | Stable | Cheaper better replacement available | Market |
RecommendationFour of the five factors are within the manufacturer’s control, and publishing repair documentation and fault codes is the cheapest of them. It attacks diagnosis time directly and can be applied to products already in the field.
QR, NFC, RFID and digital watermarks
Four carriers with different economics and different failure modes. The deciding question is rarely capability — it is whether the carrier survives the product’s working life and who needs to read it.
QR, NFC, RFID and digital watermarks| Carrier | Unit cost | Read by | Survives |
|---|
| Printed QR | Negligible | Any phone camera | Until the surface wears |
| NFC tag | Cents | Most phones, by tapping | Well, if embedded |
| RFID | Cents | Dedicated readers at range | Well, in logistics |
| Digital watermark | Negligible | Sorting lines and some apps | The whole printed surface |
RecommendationPrinted QR for consumer access, because ubiquity beats capability. Consider a watermark alongside it where sorting matters, since it covers the whole pack surface and survives the crushing and tearing that destroys a discrete label.