What an NFC tap actually proves

A tag can sign, and that is the whole trick

A plain NFC tag holds a link. Anyone can read it, and anyone can write the same link onto a blank tag. That is not a flaw; it is what the chip is for.

Authenticating chips do one additional thing. They hold a secret key that cannot be read back out, and they use it to compute a short signature over a counter that increases every time the tag is read. The signature and the counter are appended to the link as it is served.

1. The phone taps the tagNo app is required. The chip returns a URL it composed itself a few microseconds ago.
2. The chip appends its own proofA read counter and a message authentication code computed over it, using a key that never leaves the silicon.
3. The server recomputes the codeIt holds the same key, so it can tell whether the signature belongs to that tag, for that read.
4. The counter must move forwardA replayed URL carries a counter the server has already seen, so it is refused even though the signature is valid.

That is the full mechanism. It is modest, and it is enough to tell a tag that was physically present from a link that was copied out of a photograph. On the NTAG 424 DNA the feature is called Secure Unique NFC, enabled by Secure Dynamic Messaging, and the signature is an 8-byte AES-128 CMAC under a key derived from a 24-bit read counter.^[1] How that is computed, byte by byte.

What it does not prove

This section exists because leaving it out is how the technology gets oversold.

The tag can still be moved

A signature proves the chip is genuine. It says nothing about the glue. If a tag can be peeled off one item and stuck to another, the cryptography is intact and the claim is false. Tamper-evident construction is a separate problem with a separate answer.

A copy can still be made

Anyone can clone the link a tag serves. What they cannot do is produce a valid signature for the next read, because they do not hold the key. So the copy exists, and it fails the check. Those are different claims, and only the second one is true.

Presence is not proximity

A valid signature says the chip answered. It does not say the chip was near the reader. Two radios and a network link will carry the exchange as far as the network goes, and no amount of cryptography at the application layer closes that gap.^[2] What that costs an attacker, and what else works.

Absence proves nothing either

A check that cannot finish, because the phone is offline or the server is down, is not evidence that a tag is counterfeit. Systems that treat a failed verification as a failed item will generate false accusations, and will deserve them.

Chip families, and which ones can do this

The word "secure" gets applied to tags that mean very different things by it. Two distinctions matter: can the chip be protected against rewriting, and can it sign each read.

The full comparison, with memory sizes, counter widths, what the air-interface standards actually specify about range, and the two vendors whose anti-counterfeit features cannot be evaluated because the specifications are not public.

Anatomy of a verifying URL

Mirrored parameters are written by the chip at read time, not stored in advance. The exact names are chosen by whoever provisions the tag; the shape is conventional.

# served by the chip, freshly composed on each tap
https://example.com/t/a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
    ?u=04AABBCCDDEEFF   unique chip identifier
    &c=00012F           read counter, increments every tap
    &m=9F3C1A7E5D0B4826 signature over the two values above

# the server answers one question, and answers it narrowly
{ "verified": true, "counter": 303, "at": "2026-10-24T11:02:19Z" }
# not: who owns it, not: where it is, not: whether it is still attached

Three implementation notes that are easy to get wrong

Strip the proof before it is logged. The signature and counter should be removed from the address bar as soon as the page loads. Left in place they reach browser history, referrer headers and any analytics script on the page.

Refuse by default. A malformed URL, an unknown tag and a bad signature should all produce the same answer. Distinguishing them tells an attacker which half of the guess was right.

Counters only move one way. Accepting a counter equal to the last one seen turns a captured URL into a reusable token.

Where to go deeper

Three pages, each sourced to a vendor datasheet, a published standard or a paper you can read yourself.

Why the distinction is worth the trouble

A record about a physical object is only as good as the binding between the record and the object. A carrier that anyone can copy makes the record decorative: it will still be there after the object it describes has been swapped, and nothing in the system will notice.

That is the honest case for signing tags. Not that they track anything, but that they let a record be tied to one particular piece of silicon in a way that a photograph of a label cannot be. The binding is narrow and it is physical, and most of the engineering work is in not claiming more than it gives you.

Product-passport rules in several jurisdictions are the usual reason people arrive at this question. This page does not summarise them. The obligations differ by product category and change faster than a page like this can honestly track, and a reference that summarised them once would be wrong within a year.

Sources

Every claim above should be checkable without taking our word for it. Documents were read on 2026-10-24.

1. NXP, NTAG 424 DNA, NT4H2421Gx product data sheet, Rev. 3.0, 31 January 2019. Sections 9.3.1, 9.3.7 and 9.3.8.1: the 24-bit SDMReadCtr, and the 8-byte SDMMAC computed with AES-128 CMAC per NIST SP 800-38B.
2. G. P. Hancke and M. G. Kuhn, An RFID Distance Bounding Protocol, SecureComm 2005, Athens, pages 67 to 73: "Relay attacks cannot easily be prevented by cryptographic protocols that operate at the application layer".
3. NXP, NTAG213/215/216 product data sheet, Rev. 3.2, 2 June 2015. Section 8.6 for the 24-bit NFC counter; the document contains no mention of CMAC or dynamic messaging.
4. NXP, MIFARE Ultralight EV1, MF0ULX1 product data sheet, Rev. 3.3, 9 April 2019. Section 2.1 and 8.7: "3 independent, true one-way 24-bit counters", incremented with the INCR_CNT command.
5. NXP, ICODE SLIX2 product data sheet, Rev. 4.2, 1 December 2021. Section 2.2 for the 16-bit counter "increased by one with a WRITE command"; the document contains no mention of AES or CMAC.
6. NXP, MIFARE DESFire EV3 product page, and AN12753, MIFARE DESFire EV3 Quick start guide, Rev. 1.2, 30 September 2020, which describes Secure Dynamic Messaging as new in EV3.