Product Identity Platforms: What They Are and How They Work

Several categories of software touch product data. A PIM stores product attributes per SKU. A track-and-trace system follows shipments. A brand protection service monitors marketplaces. None of them answers the question a product identity platform exists for: is this physical item the one we made, and what has happened to it?

System	Unit of record	Answers	Doesn’t answer
PIM	Product (SKU)	What are this product’s attributes?	Which unit is this? Is it genuine?
ERP / WMS	Order, batch, pallet	Where is the shipment?	Where is the individual item after sale?
Online brand protection	Listing, seller	Who is selling suspicious listings?	Is the item in hand genuine?
Product identity platform	Individual item	Is this item genuine, where has it been, who owns it?	It doesn’t replace the systems above. It connects to them.

The confusion is understandable because the categories overlap at the edges. A track-and-trace system can store serial numbers. A brand protection service can run test purchases. A PIM can publish a product page behind a QR code. But none of them is designed around the individual physical item as the unit of record, and none verifies that the item in someone’s hand is the one that was made.

In practice, a product identity platform sits between production and the market, connecting to all of these. It takes batch and product data from upstream systems, adds item identity and events, and feeds verified field evidence back into supply chain, brand protection and CRM.

One way to see the boundary: if the system can’t tell you whether a specific physical object in front of you is genuine, and what has happened to that object since it was made, it isn’t a product identity platform, whatever else it does well.

Every serious platform does five things. Weakness in one undermines the others, which is why evaluating a platform on its consumer scan page alone misses most of what matters.

1. Issue: Generate identifiers and cryptographic keys, structured to standards (GTIN + serial, GS1 Digital Link).
2. Bind: Encode the carrier and commission the item on the line, linking the identity to batch and production data.
3. Verify: Check each scan server-side: is the signature valid, is the counter fresh, is the item where it should be?
4. Record: Write every event (production, logistics, scan, transfer) to the item’s history in a standard model.
5. Act: Turn records into outcomes: alerts, dashboards, consumer experiences, ownership transfer, passport views.

The five functions also map onto who uses the platform. Issue and Bind belong to operations and IT: they decide whether items leave the line with working identities. Verify belongs to security: it decides whether the programme can be trusted. Record belongs to everyone, because it’s the shared source of truth. Act is where each team (brand protection, supply chain, marketing, compliance) gets its own view.

Behind the five functions sit a handful of components. Knowing them helps you ask better questions, because each component has its own failure modes.

• Experience layer: Consumer, retailer and reseller pages; multilingual, market-aware
• Analytics and alerting: Dashboards, anomaly rules, notifications to each team
• Verification engine: Cryptographic checks, counters, tamper, location, ownership
• Item record and event store: Append-only events per item in a standard model
• Resolver: Routes each identifier to the right response by role and context
• Identity and key management: Serial allocation, key generation, secure storage

The bottom two layers are where security is decided, and they’re the least visible in a demo. The top two are what everyone sees, and they’re the easiest to change later. Weight your evaluation accordingly.

The scan page is what everyone sees in a demo. The decision behind it is what matters. A platform that answers only ‘authentic’ or ‘not authentic’ is throwing away the most useful information it has.

What a good verification engine checks

 

Check	What it catches
Cryptographic signature	Cloned or emulated tags that don’t hold the secret key
Counter freshness	Replayed URLs copied from a genuine tap
Commissioning status	Tags that were encoded but never released (rejected or stolen stock)
Tamper state	Opened closures presented as sealed
Location vs intended market	Genuine stock outside its allocated market
Scan velocity and geography	The same item scanned in distant places within an implausible time
Ownership status	Items presented for resale by someone other than the registered owner

The first two checks are what makes the answer trustworthy. The rest are what makes it useful. A platform that does only the first two is an authentication service; one that does all seven is an operational tool.

The security of a cryptographic NFC programme depends on the secret keys inside each chip. Whoever controls key generation, injection and storage controls the programme’s integrity. These are questions to ask explicitly.

Question	Good answer	Warning sign
Where are keys generated?	In a secure environment, unique per chip or derived per chip	One key shared across many tags
How are they written to chips?	In a controlled encoding process with audit trail	Keys sent to co-packers in files
Where are they stored?	Hardware security module or equivalent	Application database
What happens if one chip is compromised?	Only that chip is affected	A batch or the whole programme is affected

Diversified keys, where each chip has its own key derived from a master that never leaves secure storage, mean that extracting one chip’s key, which is already very hard, compromises one item rather than a product line.

A platform that isn’t connected to production, logistics and customer systems produces a parallel database nobody trusts. The integration points that matter:

Connects to	Why	Data that flows
Production line / MES	Commission items as they’re made	Item ID, batch, line, timestamp
ERP / WMS	Know where each item was sent	Shipment, case and pallet aggregation, destination
CRM / e-commerce	Link owners and scans to customer records	Ownership, consented contact, scan history
Brand protection tools	Feed field evidence into enforcement	Suspect scans, location clusters
DPP registry and portals	Serve passport data from the record	Passport subset, access rights

Selinko’s platform, SelinkoTrack, is designed around these connections. On the production side, Selinko’s ILM Station hardware handles encoding and commissioning on the line.

Two integrations matter more than the rest. The production integration decides whether every item is commissioned at the moment it’s made, with batch data attached. Without it, the record starts with a gap. The ERP or WMS integration decides whether each item has an intended market. Without it, every field scan is a dot on a map with nothing to compare against, and diversion detection doesn’t work.

Ask vendors which of these integrations they’ve built for brands with a similar production setup, and how long they took. ‘We have an API’ describes a possibility, not a delivered integration.

It’s tempting to treat the consumer page as marketing’s concern. In practice it determines how much data the platform collects, because scans happen only when people have a reason to tap. A thin ‘authentic’ page generates a scan once, if the buyer is already suspicious. A page that offers provenance, usage guidance, registration, warranty or resale value generates scans from people who simply want those things.

Experience element	Who it serves	What it produces for the brand
Authenticity result with explanation	Buyers, resellers	Trust; evidence of counterfeits where results fail
Provenance and product story	Consumers	Scans at the point of purchase, location by market
Registration and ownership	Owners	First-party relationship, ownership record
Care, repair and warranty	Owners, repairers	After-sales relationship, service history
Resale verification and transfer	Second-hand buyers	Visibility into the secondary market
Retailer stock check	Retail and on-trade staff	Channel-level location and tamper evidence

Two requirements apply whatever the content: no app should be needed, since modern phones read NFC natively and open a web page, and the experience should adapt to market and language from the scan context rather than needing different tags per country.

Once live, a product identity platform is an operational system with users across the company. Programmes that plan only for launch tend to produce alerts nobody reads.

Role	Uses the platform to	Needs
Production / operations	Monitor commissioning, encoding yield, line issues	Real-time line status, exception alerts
Supply chain / commercial	Review diversion by market, shipment and distributor	Weekly views, drill-down to shipment
Brand protection	Investigate counterfeit, clone and refill signals	Case-level evidence, exportable
Marketing / CRM	Manage content, analyse engagement, sync registrations	Content tools, consented data feeds
Compliance	Manage passport content and access	Versioned data, audit trail
IT	Maintain integrations, access and security	Monitoring, logs, role management

Agree before launch who receives which alerts, how quickly they’re expected to act, and how outcomes are recorded. An alert that leads to an action, and an action that’s recorded back against the item, is what turns the platform from a reporting tool into an operational one.

Different products need different carriers: a cryptographic NFC tag in a cognac closure, a secured QR on a lipstick carton, UHF RFID on the shipping case. A platform tied to one carrier forces you to run multiple platforms with records that don’t reconcile. Ask whether one item record can hold identities from several carriers at once (for example, an NFC tag on the bottle and a UHF tag on its case), and whether verification logic is the same across them.

Selinko’s portfolio spans NFC, secure QR, RFID, secured barcodes and Diamond Dust for exactly this reason.

Carrier-agnosticism also protects against change. Carrier technology evolves: new chip generations, new secured printing techniques, new regulatory recognition. A platform that ties identity to the carrier forces a migration each time. One that separates the identity from the carrier lets you change the carrier on new production while items already in market keep working.

Platform licence is one line among several. Over three to five years, the full picture usually looks like this.

Cost	Type	Notes
Platform licence	Recurring	Check what it scales with: units, scans, modules, markets
Carriers and application	Per unit plus step	Often larger than the licence at scale
Production integration	Step, per line or site	Encoding and commissioning equipment, line changes
Systems integration	One-off plus maintenance	ERP, WMS, CRM, brand protection, DPP
Experience content	Recurring	Translation, market content, campaigns
Internal operations	Recurring	People who act on alerts and maintain data
Exit costs	Contingent	Low if the brand owns domain, data and keys; high otherwise

The last line is the one most often missing from business cases. It’s also the one that decides how much negotiating power you have at renewal. For per-unit economics, see How Much Does NFC Product Authentication Cost?.

Brands rarely use every function of a platform on day one. Use tends to mature in stages, and each stage asks different things of the platform. Knowing where you are helps you buy for the next stage, not just the current one.

Stage	Typical scope	What the platform must do well	Signal you’re ready to move on
Pilot	One SKU, one market	Encoding on a real line, reliable verification, basic dashboard	Yield and line impact understood; scan data is meaningful
Product line	Several SKUs, several markets	Intended market from ERP, diversion views, multilingual experience	Diversion or counterfeit cases resolved with platform evidence
Range	Most premium lines, several sites and co-packers	Central serial allocation, multiple carriers, role-based access	Several teams use the record routinely
Infrastructure	Default for new products	Passport views, ownership, open data export, partner access	New use cases added without new carriers

The most common mistake is to choose a platform that excels at the pilot stage and struggles at the range stage: strong scan pages, weak serial management across sites, no intended-market logic. Ask vendors to show a customer at the stage you expect to reach in three years.

Buy for the stage you’ll be at in three years, not the pilot you’re running next quarter.

1. Write down the threat and the questions: Copying, refilling, diversion, resale, DPP. The platform should be evaluated against your questions, not its feature list.
2. Test with your hardest case: Ask each vendor to demonstrate a cloning attempt, a diversion case and a resale transfer on their platform.
3. Check production references: A platform that has never been integrated on a line like yours will learn on your budget.
4. Review security and data terms: Key management, export, domain ownership and personal data roles.
5. Pilot on a real line and a real market: Measure yield, verification behaviour and data flow, not just scan rates.

• A product identity platform issues, binds, verifies and records the identity of each physical item, then turns records into actions.
• It doesn’t replace PIM, ERP or brand protection tools. It connects them at item level.
• Verification should return signals, not just yes or no: tamper state, intended market, scan pattern, ownership.
• Key management, data export and domain ownership are as important as features.
• Evaluate with your hardest scenario and a production reference, not a scan demo.