Imagine buying a used technical jacket. The seller sends you its Digital Product Passport: the brand is right, the materials are listed, and the care information looks convincing. You can read everything before paying. What you still cannot tell is whether the jacket being sold belongs to that record.
If it is a publicly accessible link, someone selling a counterfeit could send it too. What the buyer can establish from it depends on any additional checks.
This is where a secure NFC tag can add something useful. Follow this hypothetical jacket from production to purchase, repair and resale: what does one tag need to do, and how does its role change over time?
A genuine passport does not settle whether the product is genuine
A Digital Product Passport makes product information accessible: which information, to whom and at what level of detail depends on the applicable rules. Its records need their own safeguards against unauthorised alteration. None of that automatically establishes that a particular physical object belongs to the record being viewed.
Ordinary printed QR data and static NFC links can be copied. If a passport uses such an entry point without additional checks linking it to the physical item, the same link could be placed on another jacket and still lead to genuine brand information. That is potential misuse of the access route, not necessarily a compromised passport record.
GS1’s digital-signatures guideline, Section 4.3 describes how even serial-level barcodes can be copied and how physical security features can strengthen the link to an item. A signature protects the signed data’s origin and integrity; detecting substitution also depends on the surrounding verification design.
Secure NFC addresses part of that missing connection. A suitably configured chip can generate a message that a copied identifier or static URL cannot generate on its own. A verification service checks that evidence and its registered product association. The physical attachment then matters: evidence from a genuine tag is only useful for the jacket if there is good reason to trust that the tag still belongs to it.
That distinction is the basis for combining DPP and anti-counterfeiting. The two functions share a product relationship, but they do not provide the same evidence. For the wider passport framework, see our EU Digital Product Passport guide.
What happens when one NFC tag does both?
The connection begins before the jacket leaves production. The tag needs its security configuration and keys provisioned under controlled conditions. Its credential must then be assigned to the correct physical unit and linked to the approved passport record. Before activation, a final read is reconciled with the finished jacket’s independent production record. Reading the tag alone cannot reveal that it was assigned to the wrong garment.
On a compatible phone, the customer can tap to read an NFC web address and open it in the browser. With NTAG 424 DNA, Secure Dynamic Messaging (SDM) can be configured to place dynamic, cryptographically protected data in that address. The backend can then validate a message authentication code (MAC) over the configured data using AES-based cryptography. The secret key is not sent in the URL. NXP describes the mechanism and configuration in AN12196.
This matters because a chip UID or printed serial number is not a secret. Copying one may reproduce a lookup, but it does not give the copier the key needed to generate new valid protected messages. An ordinary NFC tag containing only a passport URL has no equivalent capability simply because it uses NFC.
The verification service checks the protected message, rejects already-seen or out-of-order counter values under its per-tag policy, and checks the issued credential’s status and product association. The read counter helps distinguish responses from those already accepted by that service. The service also needs to know whether the credential is active, unassigned or retired. These checks belong together: a cryptographically valid response from a retired tag should not become a fresh positive verdict.
After successful verification, the service can offer the passport destination registered for that product. It should resolve that destination from controlled records, not trust an arbitrary redirect supplied in a scan URL. The customer can see the verification result and follow through to the product information without needing a second physical tag.
The passport itself is usually held in the connected system, not packed into the chip. Material information or repair instructions can be updated there by authorised parties without rewriting every jacket’s NFC tag. A stable entry point is useful, but the operator still has to maintain the domain, routing and records behind it.
The secure NFC route
- Read the tag
The phone receives the configured dynamic NFC message.
- Verify the evidence
The service checks the protected data, counter and credential status.
- Resolve the product
The issued credential is matched to its registered product association.
- Open the passport
The approved destination presents information under its access rules.
What does this stop—and what can still be copied?
Suppose someone copies the jacket’s public, static passport URL onto a counterfeit. If that route provides information without further physical checks, the copied URL may still open the genuine record. It cannot, by that act alone, produce the chip’s new protected NFC messages. This is the practical difference between distributing a record and presenting evidence from an issued security credential.
Now suppose someone captures a complete NFC response, including its valid protected data. Cryptography alone does not make that captured response disappear. If it has already been accepted, a verifier that tracks counters can recognise its reuse and avoid treating it as fresh evidence. But a captured response the service has not yet seen may still pass that counter rule. NXP explicitly discusses this limitation in the NTAG 424 DNA datasheet, Sections 9.3–9.3.1.
The counter is not a timestamp or proof that the phone is beside the jacket at this instant. It also counts qualifying chip reads, not website visits. Reads that never reach the server can leave gaps; refreshing a browser can resubmit an old URL. Neither event, on its own, establishes that a jacket is counterfeit.
A useful customer result therefore says what the service actually checked and gives an understandable next step when it cannot accept a request. An unreadable tag, a network outage and a rejected replay are different situations. Calling all three ‘fake’ would weaken confidence in the system. Our guide to secure NFC verification explains why opening a page and verifying a product must stay distinct.
The tag has to stay with the jacket
A less technical attack is to move a genuine tag onto another garment. Its cryptographic responses may remain valid. No algorithm inside the chip can inspect the surrounding fabric and determine that someone transferred it.
This is why tag construction is part of the security design. BrandGuard offers a heat-applied NFC garment badge built around NTAG 424 DNA for compatible textiles. For the jacket in this example, the fabric, badge position and bonding process would need to be qualified together. A heat-applied badge is not automatically suitable for every coated, laminated or heat-sensitive fabric.
The relevant questions are physical: can the badge be removed intact; can someone cut out the surrounding cloth and transplant it convincingly; does washing or flexing weaken the attachment; can the intended phone still read the finished assembly? The answer comes from tests on the actual garment and construction, not from the chip’s security specification.
A tag designed to break when transferred and a tag intended to survive years of use create different engineering demands. The design must address both rather than assuming that ‘durable’ also means ‘transfer-resistant’.
Even a well-attached, correctly verified tag does not independently prove a recycled-fibre percentage or the quality of a repair. Those claims need reliable source data and accountable contributors. Secure NFC strengthens the association with a record; it does not inspect every statement in it.
One jacket can outlive its first tag
At purchase, the buyer wants confidence in the item being offered. During repair, a technician may need the correct care or component information. On resale, a new buyer may want both. Keeping one product relationship through those changes is more valuable than simply avoiding an extra label at the factory.
That relationship should not depend entirely on the chip UID. The tag credential identifies an issued tag; the unit record identifies the jacket; the passport identifier identifies the information record required by the relevant rules. These may have different lifetimes and granularity. Several individually authenticated jackets could legitimately share a model-level passport where the applicable rules call for one.
GS1 Digital Link offers one way to express product identifiers with qualifiers such as batch or serial number. Its URI syntax standard and resolver standard distinguish the identity of a product from the information resources it can lead to. The identifier scheme and connection to the passport platform are agreed for each project.
If a repair replaces the zip and leaves the badge in place, the same tag can still lead to the relevant product information. An authorised service entry changes the record; neither the tag nor the jacket’s identity needs to change. But if an authorised repair replaces the panel carrying the badge, the new tag should be enrolled against the existing jacket record and the old credential retired through a controlled service process. The repair should not accidentally create a second jacket, wipe the service history or leave two active tags claiming the same unit. A serial number visible to the public is not sufficient authority to approve that change.
The service record also needs an authorised contributor. A successful tap does not, by itself, establish that a repair occurred or entitle the person holding the phone to edit it. Likewise, resale should not expose the previous customer’s identity or complete scan history to a new buyer. Information access and permission to make changes remain separate decisions.
This is where an integrated design earns its keep: the carrier can change while the product’s history remains coherent. It also creates a continuing responsibility. Verification, replacement and passport hosting need an owner and support arrangements for as long as they are required.
Do not make required passport information depend on a fresh tap
Return to the second-hand buyer. Before the jacket arrives, there is nothing to tap. It would make little sense to withhold all passport information until a successful physical authentication, and the ESPR explicitly provides for access before purchase, including distance selling. Articles 9–11 also address access rights and continued availability. See the EU regulation.
A sound design therefore separates the information route from the authenticity verdict. A permitted QR code, online listing or direct link can provide the applicable passport information. The secure NFC route adds its verification evidence when the item is available to read. Access remains subject to the relevant rights; a public entry point does not mean every record or personal detail should be public.
The choice of carrier must still follow the product-specific rules. NFC is not compulsory for every DPP, and it cannot simply replace a mandated QR code. For example, the battery-passport rules specify QR access for EV batteries, light means of transport batteries and industrial batteries above 2 kWh placed on the market or put into service from 18 February 2027. Our battery passport guide covers that separate case.
Where the relevant format and placement rules permit it, one physical tag assembly can contain secure NFC and a printed QR. ‘One tag’ then means one physical carrier, not one access method. If a verifier is unavailable or a badge becomes unreadable, an independent, trusted lookup can help preserve access without pretending that authentication succeeded.
The ESPR ties passport availability to at least the expected product lifetime and requires continued availability even if the responsible operator ceases trading. A long-lasting chip cannot deliver that on its own. Domains, passport services, backups and the ability to recover access need the same attention as the badge.
What BrandGuard can contribute
BrandGuard’s part of this design is the physical secure NFC tag, controlled encoding and product association, and online verification within the selected solution. The complete verification solution can provide a controlled handoff to a registered product-passport destination. Garments are one possible application; a retained surface-mounted NFC tag may suit a different product after its materials and operating conditions are assessed.
The passport provider and responsible operator still have to organise the required data, establish its accuracy, implement access rights and maintain availability. An authentication layer does not supply those functions automatically or confer DPP compliance. The connection between the systems needs to be agreed for the project; a proposed architecture is not a ready-made integration.
For a brand, the decision comes down to what needs protecting. If the immediate job is simply to make product information accessible, a permitted printed carrier may be sufficient. Where copied identities, counterfeit substitution or tag transfer are credible risks, secure NFC can add evidence that a static link lacks—but only with sound issuance, physical attachment and verification.
The strongest reason to combine the two is a better answer to the buyer’s original question: how does this information relate to the item in front of me? One tag can make that answer easier to obtain. Keeping it trustworthy requires the physical product and its records to remain connected long after the first scan. For other construction choices, see our anti-counterfeit label guide.
Questions about DPP and secure NFC
Does a Digital Product Passport prevent counterfeiting?
A DPP alone is not proof that an item is genuine. If a passport relies on a publicly accessible static link without further checks connecting it to the physical item, another item could misuse that entry point. Whether this is detected depends on the verification design. This is a conditional risk, not a claim that every DPP is vulnerable or that passport misuse is widespread.
Can one NFC tag also carry the required QR code?
A physical tag assembly can combine secure NFC and a printed QR code where the applicable format and placement rules permit it. The QR can provide passport access; the secure NFC route can add authentication evidence. Each route should make clear which checks, if any, were performed.
Could secure UHF RFID be used instead of NFC?
Cryptographic UHF RFID can be part of a suitable design; NXP UCODE DNA Track is one example supporting AES authentication. UHF suits dedicated-reader and batch workflows. Ordinary NFC-capable phones do not read UHF tags, which makes secure NFC a practical choice for consumer phone access. This is a technology distinction, not a claim that BrandGuard currently supplies a cryptographic UHF service.
Is the entire Digital Product Passport stored in the NFC chip?
Not in the online design discussed here. The tag carries the entry point and authentication-related data; the connected system holds the passport information. Authorised parties can update that information without rewriting the physical tag, provided the identifiers and access route remain properly maintained.
Sources and scope
- EU ESPR — Regulation (EU) 2024/1781, Articles 9–11
- European Commission — Digital Product Passport FAQs
- European Commission — battery passports and QR access
- NXP AN12196 — Secure Dynamic Messaging configuration and application guidance
- NXP NT4H2421Gx — NTAG 424 DNA; replay considerations in Sections 9.3–9.3.1
- GS1 Digital Link — URI syntax standard
- NXP UCODE DNA Track — AES-capable UHF RFID
- GS1 Digital Signatures Technical Implementation Guideline — Section 4.3, copied barcodes and physical security features
Sources reviewed on 5 September 2026. The jacket and its purchase, repair and resale are illustrative scenarios, not a reported deployment or test result. The proposed system design is distinguished from chip capabilities and legal requirements; final obligations and construction performance depend on the actual product and project.

