Product Authentication Technology: What Actually Works in Practice

Product Authentication

Product Authentication Technology: What Actually Works in Practice

Arun Krishnan2026-09-1610 min read

For years, product authentication has been sold as a label decision: pick a QR code, or a hologram, and the counterfeit problem is handled. That framing has never really held up. A product can return a valid scan result and still be counterfeit. A copied code can lead to the correct brand page, a genuine serial number can be transferred to another pack, a legitimate container can be refilled with something else entirely.

The technology in these cases hasn’t failed. The organisation has asked it to prove something it was never designed to prove. Product authentication works only when a trusted identity, a physical item, a verification method and an investigation response are connected as one system, not procured as separate line items.

A valid scan is not proof of a genuine product

This is the one distinction that reframes everything else. Identification, authentication and traceability get treated as one procurement requirement, but they don’t establish the same facts.

Identification answers which product, batch or unit this is. Authentication answers whether this specific item satisfies a defined genuineness check. Traceability answers what recorded events describe its production, movement or custody. None of the three proves the others.

A serial number can distinguish one unit from a million others. A traceability platform can record where that identity was commissioned, shipped or scanned. Neither of those automatically binds the digital record to the physical object a verifier is holding. GS1’s Digital Link guide is a good example of why this matters: it standardises how identifiers connect to online information. Connectivity is not the same as authentication.

ISO 22383:2020 is direct about the order this should happen in: authentication elements should be selected after the organisation has assessed its counterfeiting risks, not before. Picking a preferred tag first and defining the threat later reverses the logic that actually protects a brand.

Why a QR programme can work technically and still fail commercially

QR codes are familiar, cheap to print and readable on any phone. Those are real advantages as a data carrier. They say nothing about whether the printed image resists copying.

EUIPO’s guidance on two-dimensional barcodes is blunt about this: QR codes alone do not protect against copies. They contribute to authentication only when combined with unique identifiers, other controls, a management platform and scan-data analysis. The difference sits in the system around the symbol, not the symbol itself.

Three superficially similar deployments produce three very different outcomes:

1. A shared QR code sends every pack to the same page. Useful for engagement. Unable to distinguish one physical unit from another.
2. A serialised QR code gives every unit its own identity, so the platform can flag repeated or implausible use. The printed symbol itself can still be copied.
3. A protected authentication workflow adds server-side status checks or a physical security property on top of identity. This is the only one of the three that can assess more than whether the code is readable.

The most common failure isn’t choosing QR technology. It’s letting a successful scan stand in for a genuine-product decision. A reassuring green screen on every readable code creates confidence without producing evidence.

Where authentication deployments actually break down

Demonstrations look clean. A prepared sample scans instantly, the dashboard logs the event, the verification page shows the expected result. Production asks harder questions a demo never answers.

1. The packaging line is the first point of failure. Unit-level identity has to be generated, printed, inspected, commissioned and matched to the right product record. Printer faults, duplicate jobs, rework and line stoppages all create data exceptions before a product ships. Code size, substrate, curvature and varnish behave differently at production speed than on a lab sample.

2. Verifiers don’t behave like test users. A consumer abandons a slow-loading scan. A distributor avoids anything that delays dispatch. A service centre prioritises warranty turnaround over evidence quality. One verification journey can’t serve all three well, and “unable to verify” is operationally different from “counterfeit,” even though weak interfaces routinely blur the two.

3. Events accumulate faster than investigations can absorb them. A repeated scan or an odd location is a reason to look, not proof of fraud. A dashboard full of alerts is not intelligence. Intelligence needs thresholds, ownership and an escalation path. Without them, authentication data becomes another queue nobody trusts.

4. Governance gets treated as a post-pilot task. Access, retention, evidence preservation and change control need deciding before scale, not after a dispute breaks out over who owns a suspicious event.

Five layers, evaluated together

This is a practical synthesis of the standards and deployment patterns above, not a separate industry standard. Weakness in any one layer reduces the value of the other four.

Trusted product identity. Define what’s actually being identified: product class, batch, carton, unit or component. More granularity means more printing, data and reconciliation overhead, so unit-level serialisation should answer a defined risk, not signal technical maturity by default. Identity also has a lifecycle: a product can be genuine at manufacture and later recalled, expired or deactivated, and a verification result needs to reflect that state without implying every non-valid result proves counterfeiting.

Physical and digital binding. The identity has to connect meaningfully to the physical item, and the right control depends on the attack: copying, label transfer, refilling, tampering or substitution. No vendor should get away with “unclonable” as a self-explanatory spec. Ask what attack was tested, under what conditions, against what equipment, with what false-acceptance and false-rejection rates. Security is a claim about resistance to a defined method, not an absolute property of a label.

Verification that works in the real channel. The strongest control is worthless if the intended verifier can’t reliably use it. A consumer needs a camera scan with no app. A warehouse needs automated reading. A service centre needs product history next to warranty status. The design has to distinguish genuine, suspicious, already-used, deactivated and unable-to-verify outcomes clearly enough to reduce both false confidence and unnecessary support load.

Event intelligence and investigation. Verification events can reveal patterns that a static security feature can’t on its own. The value isn’t scan volume, it’s the quality of the decisions that follow. A platform should support judgement: documented thresholds, evidence capture, case ownership and escalation paths, rather than turning every anomaly into an accusation.

Operational integration and governance. Identity has to connect to packaging, ERP, MES, warehouse and warranty systems, plus a process for damaged marks, offline verification and returned stock. This layer is the least visible and the most decisive. It’s what separates a reliable enterprise control from a pilot that can’t survive scale.

No technology category is inherently best

NIST’s evaluation of product authentication technologies makes this explicit: strengths and weaknesses are context-dependent, not fixed rankings.

Layering controls can reduce reliance on any one mechanism. It doesn’t follow that more technology is automatically better. Every layer adds cost, training and support burden. The right architecture is the smallest combination that addresses the actual threat and can be run consistently.

Why this is a brand decision, not just a packaging one

It’s tempting to read authentication technology as a packaging or procurement question. That’s too narrow.

Industry context changes what “good” looks like. Pharma needs auditability alongside the consumer-facing check. Automotive and electronics extend authentication into after-sales. A genuine code copied onto a substitute component creates both a product-integrity problem and a warranty-abuse problem. Agrochemical products face refillable containers and rural connectivity constraints that matter more than smartphone familiarity. FMCG’s line speeds and thin per-unit economics can make an elaborate control commercially impractical even when it performs well in a lab.

And none of this reaches fake marketplace listings or impersonation sites, which can attract a buyer before a physical item ever exists to scan. Real product integrity usually needs authentication working alongside traceability, online brand protection and warranty verification, not one of them standing in for all four.

The gap regulation and technology alone can’t close

Better authentication can establish whether a specific unit satisfies a genuineness check. It can’t, by itself, guarantee that every genuine product reaches the shelf it was meant for, or that every counterfeit gets caught before a consumer buys it.

This is where the five layers above stop being a checklist and start being an operating model: identity, binding, verification, investigation and integration, working together continuously rather than as a one-time deployment. Certify is Acviss’s product authentication solution built around that same model, and it holds up to the same scrutiny as any other option: not the strength of the pitch, but whether it performs across all five layers on a real product, not a demonstration one.

The useful starting point with any option, Certify included, isn’t a broad rollout. It’s one SKU, one credible attack scenario and one verifier group, tested against real packaging and real channel conditions.

Procurement mistakes that quietly undo good technology

Buyers often compare vendors on feature lists: code type, dashboard modules, integration count, claimed security level. That process rewards the best presentation, not the best operational fit.

Selecting the tag before defining the attack means copying, refilling and warranty abuse, three different problems, end up with the same generic response. Treating uniqueness as proof of authenticity ignores that a unique identity can still be copied or transferred onto something else. Testing only happy-path scans in a pilot misses exactly the conditions that determine whether the system holds up in the field: damaged packaging, poor connectivity, ambiguous results. Ignoring investigation capacity turns detection into an unresolved queue rather than protection. And assuming a successful pilot proves scalability skips over the production throughput, distributor adoption and support load that only show up at real volume.

A structured anti-counterfeiting vendor checklist can help translate these five mistakes into specific questions before a contract is signed.

What a pilot should prove before it scales

A credible pilot uses the real product, substrate, packaging process and verifier group, and defines what failure looks like before deployment, not after the results come in.

Before approving scale, a cross-functional team should be able to answer: what specific attack is being tested; what binds the digital identity to the physical product; how copying, transfer and refilling are each handled; what false acceptance and false rejection mean in this context; whether every intended verifier can actually use the result; what happens with weak connectivity or a legitimate repeat scan; whether the production line can generate, print and reconcile identities reliably; who owns a suspicious event and what evidence reaches them.

The pilot should end in a go, redesign or stop decision against criteria set in advance. A demonstration proves a prepared sample can work. It doesn’t prove an enterprise programme stays reliable across millions of ordinary exceptions.

What changes once the label stops being the answer

Authentication is moving from a printed mark to an operating decision. As supply chains, service networks and digital channels get more connected, the brands that hold up are the ones that can link product identity to lifecycle status, investigation evidence and clear ownership of a suspicious event, not the ones with the most technology on the pack.

The next generation of programmes won’t be judged by scan volume. They’ll be judged by whether genuine products move with less friction, suspicious activity reaches the right person, and the response is proportionate to the evidence. Start with one threat, decide what has to be proven, and design the operational response before choosing the tag.

Frequently asked questions

Is a QR code enough for product authentication?
Not by itself. A QR code carries an identity, but the printed symbol can be copied. It only contributes to authentication combined with other controls.

What’s the difference between authentication and traceability?
Authentication checks whether an item satisfies a genuineness test. Traceability records where it’s been. A valid history doesn’t prove the physical item carrying it is original.

Is there one best authentication technology?
No. The right choice depends on the attack, the product, and who’s verifying it. A technology that’s excellent for a controlled inspection can be wrong for a high-speed consumer scan.

Written by

Arun Krishnan

Arun is a storyteller at heart, with a knack for making complex ideas click. He works at the intersection of technology, content, and communication, turning technical jargon into stories people actually want to read.