NFC Product Authentication Without Building Your Own Platform

A secure chip is only part of a usable authentication system. It needs a suitable physical format, the correct security configuration, a link to the right product record and a backend that checks what the tag sends. Those parts have to work together.

With BrandGuard™ complete NFC protection, tag production, secure encoding and online verification can be covered within one agreed scope. Adopting NTAG® 424 DNA does not require your brand to develop and operate its own verification backend.

Customers tap the tag with a compatible NFC phone, follow the phone's prompt to open the browser and receive an online result. No dedicated app or manually entered verification code is required for this flow.

If you already run a verifier, our tag and secure-encoding service can instead be assessed against your configuration. This article concerns the option in which BrandGuard™ also handles online verification.

Consider two perfumes sold by the same brand in similar bottles. Even a genuine tag can mislead a customer if its record identifies the wrong fragrance. Accuracy therefore involves more than recognising genuine hardware.

BrandGuard™ secure encoding prepares each tag for authentication. We configure independent security credentials for the tags and associate their identities with the relevant product records. Online verification checks the authentication information and the registered product relationship.

This ties the physical tag supply, encoding and backend together. It also gives the customer product information to compare with the item in hand. Software can check the registered relationship; it cannot correct inaccurate source records or a tag attached to the wrong item. Product data and physical application must also be checked during production and delivery.

A basic NFC tag can open your genuine website. Someone who copies its fixed URL to another tag may open exactly the same page. Seeing your logo or finding a serial number in a database does not, on its own, authenticate the tag.

When properly configured, NTAG® 424 DNA produces authentication data protected by AES-128 cryptography during a read. BrandGuard™ checks that data on the server alongside the registered tag and product relationship. Copying a public number or fixed URL does not provide the means to generate equivalent valid new authentication data.

BrandGuard™ makes the verification decision on the server. The public page does not need to store verification keys or decide whether a check passed based on an editable address parameter. The displayed result comes from the service's check of the authentication data.

Suppose someone taps a genuine product and forwards the resulting link. The recipient may be able to read the product description. That does not mean a different item in their possession has just been authenticated.

First, the service checks for reused tag responses. It compares the read-counter information with previously accepted records, rather than treating data already used as another new verification.

That check has limits. If someone saves a valid response from a genuine tag without submitting it, counter checks alone cannot establish whether they still hold the tag when they eventually use the link. Preventing reuse is therefore not a guarantee against every attack.

Second, ProofWidget controls how the result is obtained on the website. It uses a short-lived, single-use credential to retrieve the corresponding official result from BrandGuard™. An ordinary product URL cannot create a new NFC verification. Copying the URL or refreshing the page cannot repeatedly use the same credential to obtain new success results.

One control checks the tag data; the other controls the display of the result. Product information can be shared, but opening a shared link does not authenticate the item in the recipient's hands.

If a phone cannot read a tag or loses its network connection, the check may be incomplete. An incomplete check should show neither a successful verification nor a warning that the product is counterfeit.

Without a valid verification credential, the official panel displays a neutral state. The same principle applies when someone opens a bookmarked product page without a new NFC check. Product information and support can remain available, but the page should not imply another verification has just happened.

Authentication data that fails a check is a different situation: the service has not confirmed that response and cannot report success. Customers should receive clear guidance to tap again or contact brand support. The messages shown depend on the official verification states enabled for the project.

Packaging status must also remain separate from tag authentication. A customer can open a genuine product; an appropriate tamper-detecting seal may report that opening while its tag still authenticates. Keeping those findings separate helps a brand flag concerns without alarming legitimate customers unnecessarily.

Cryptographic verification checks a tag's authentication data. It does not, by itself, tell whether that tag has been removed from a genuine item. Physical protection matters because it connects the useful digital result to the actual product.

BrandGuard™ offers formats including secure NFC labels, tamper-detecting closure seals and heat-applied garment badges. Suitable materials and attachment methods help reduce the risk of tags being removed intact and reused. A seal intended to detect opening must be placed across the relevant closure.

Surfaces, liquids, metal, washing and wear can affect the design. Reading performance and attachment therefore need testing on the actual product. A tag cannot analyse a bottle's contents, so physical protection and digital verification need to be considered together.

You can use a BrandGuard™-hosted result page or direct successfully verified customers to an approved brand or product page. Your site can continue to offer instructions, brand information, an official shop and after-sales support.

ProofWidget includes the panel that displays the official verification result to customers. Your brand manages the content and overall page layout; BrandGuard™ supplies the panel's verification result, time and applicable packaging state. The panel shows the result of a specific check; it does not represent permanent certification of the product.

BrandGuard™ determines the panel's verification status and wording. Your team can maintain the surrounding website without building its own rules for when to show a successful check. Connections to membership, loyalty or order systems require separately agreed integrations.

ProofWidget's core component and integration examples have been developed. It is not activated by default: each customer deployment requires domain approval, page integration, explicit activation and acceptance testing on real phones and browsers.

ProofWidget integration requires evidence that the customer controls the domain, followed by approval of the specific HTTPS site and destination. This limits the onward visit to an agreed destination. Installing the component on another site does not authorise that site to display official results.

The integration requirements specify that verification credentials and protected item information must be excluded from analytics and session-replay tools. This exclusion needs to be checked before launch to keep verification data out of unrelated website tools.

Acceptance testing includes copied links, refreshes, expired credentials, unapproved sites and situations where no result is available. The product page should remain usable and display a neutral panel. It should not show a success badge for an incomplete or failed check. These requirements must be verified for each customer deployment.