Open technical reference
What an NFC tap actually proves
Most writing about NFC authentication is either a datasheet or a sales page. This is neither. It is a plain account of what a tag can demonstrate, what it cannot, and why the difference decides whether a system is worth building.
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.
- The phone taps the tagNo app is required. The chip returns a URL it composed itself a few microseconds ago.
- The chip appends its own proofA read counter and a message authentication code computed over it, using a key that never leaves the silicon.
- The server recomputes the codeIt holds the same key, so it can tell whether the signature belongs to that tag, for that read.
- 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.
What it does not prove
This section exists because leaving it out is how the technology gets oversold.
A verified tap is evidence that a specific chip was read. Nothing more.
It does not establish who owns the object, that the tag is still attached to the thing it was attached to originally, or where either of them is now.
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.
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 locked against rewriting, and can it sign each read.
| Family | Lockable | Signs each read | What it is good for |
|---|---|---|---|
NTAG 213 / 215 / 216 |
Yes | No | A link that should not be rewritten by a passer-by. Cheap and widely supported. |
ICODE SLIX2 |
Yes | No | Longer read range and inventory scanning. Write-protected, but a copy of its link still passes. |
NTAG 424 DNA |
Yes | Yes | Per-read signatures with AES-128. The only row here where a copied link fails a check. |
MIFARE Ultralight |
Often not | No | Transit tickets and disposables. Treat the contents as public and rewritable. |
Locked is not signed. A write-protected tag resists being changed. A signing tag resists being imitated. Interfaces that label both as "secure" teach users the wrong thing, and that confusion survives long after the label is corrected.
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.
Why this matters more than it used to
The European Union's Digital Product Passport regulation will require many categories of goods sold in the EU to carry a machine-readable record of what they are made of and what has happened to them. A carrier that anyone can clone makes that record decorative.
That is the honest case for signing tags: not that they track anything, but that they let a record be tied to a physical object in a way that a photograph of a label cannot be. The modest claim is the durable one.