EdgeNFC
EdgeNFC
NFC vs QR codes
This page is not an argument that QR codes are bad. They are the most successful piece of consumer scanning technology ever deployed, they cost nothing, and for most jobs they are the right answer. They just cannot do one specific thing — and that thing is the entire reason EdgeNFC exists.
The distinction, stated precisely. A QR code is a fixed encoding of a string: every scan returns the same bytes, and a photograph of it reproduces it perfectly. An NTAG 424 DNA tag holds an AES key it never discloses and uses it to sign a message that is different on every tap. One tells you what was printed. The other tells you a particular chip was here, just now.
Credit where it is due
Not "considerations". These are real, structural advantages, and if any of them is decisive for you, you should print a QR code and skip the rest of this page.
A QR code costs nothing to generate and nothing to reproduce. There is no bill of materials, no minimum order, no lead time, and no per-unit cost that scales with your production run. An NFC tag is a physical chip and will never be free.
The camera app reads a QR code on essentially any modern phone with no app, no settings change, and no hardware requirement beyond a lens. NFC reading is widespread but not universal, and it behaves differently across devices and OS versions.
Paper, cardboard, a receipt, a poster, a screen, a billboard, an email. Anywhere ink or pixels can go, a QR code can go. An NFC tag needs a chip and an antenna physically attached to the object, which rules out a lot of surfaces and a lot of budgets.
A QR code can be scanned across a room, through a shop window, or off someone else's screen. NFC is a near-field technology by design: the phone has to touch the tag. That is a security property, but it is also a usability limit.
QR encoding includes error correction, and a damaged code can be replaced by printing another one for free. A tag with a crushed antenna is dead, and replacing it means provisioning a new tag and retiring the old one.
No keys, no provisioning pass, no verification service, no supplier. You generate the image and you are finished. Everything EdgeNFC adds is also something you now have to operate — see when not to use us below.
The architectural limit
This is not a criticism of QR quality or of any particular vendor's QR product. It follows from what the format is.
A QR code is a visual encoding of a string. There is no key inside it, no computation happening, and no state that changes between scans. Everything a reader will ever learn from it is visible in the picture, which means everything it will ever prove is visible in the picture too.
Photograph a QR code and reprint it and you have not made an imitation — you have made a second original. The copy scans to the identical string, so no reader, anywhere, can tell the two apart. This is true no matter how long or how random the string is.
Giving every item its own unique code is genuinely useful for tracking, and it means a copied code is at least tied to one specific item. But copying that one code still produces a code that verifies, because verifying means "is this string in my database", and the copy contains the same string.
Flagging a code scanned in two countries an hour apart is a good heuristic and worth doing. It is also statistical, after the fact, and silent when the counterfeit is scanned before the original. It tells you something probably went wrong; it cannot tell a shopper, at the moment they tap, that this item is the real one.
It proves that something displayed that string. It cannot demonstrate physical presence, because a photo on a screen scans exactly like the label on the box. Whether that matters depends entirely on what you are using it for.
You can put a digital signature inside a QR code, and for some jobs that is exactly right — it proves the payload was issued by you. It still does not prove freshness or presence, because the signed image can be photographed and reused unchanged.
What changes with a chip
The tag is not storing a better secret. It is doing arithmetic that requires a secret, and emitting only the result.
At provisioning, each tag gets an AES-128 key derived from your system master key and the chip's own 7-byte UID using NXP's AN10922 diversification. Two tags never share a key, and the derivation does not run backwards.
The chip keeps an internal read counter, SDMReadCtr, that only moves forward. It is part of the data the tag mirrors into the URL, so no two taps of the same tag ever produce the same URL.
The tag derives a per-read session key from its file-read key, the UID and the counter, computes an AES-CMAC over the mirrored data, and puts a truncated 8-byte MAC in the link. The key itself is never part of the payload.
We re-derive that tag's key from the master key, recompute the MAC, compare it in constant time, and reject any counter we have already seen. A forgery fails the first check; a replay fails the second.
What the URL actually looks like. In the recommended encrypted-PICC mode a tap arrives as ?picc_data=…&cmac=… — 32 hex characters of AES-encrypted UID and counter, plus 16 hex characters of MAC. The plaintext-mirror alternative sends ?uid=&ctr=&mac= instead, which is easier to inspect and gives up the UID to anyone who reads the link. Both change on every tap; only one keeps the tag's identity private.
You can paste a real one into the free SUN/SDM decoder and watch it come apart field by field, or try to forge one in the live demo.
Side by side
Five of these rows go to QR. They are not padding — they are the reasons most things in the world should still carry a printed code.
| Property | QR code | EdgeNFC tap (NTAG 424 DNA) |
|---|---|---|
| Cost per item | Free — it is ink | A physical chip with a real per-unit cost, plus one provisioning pass |
| Reader required | Any camera, at a distance, through glass | A phone with NFC, held against the tag |
| Surfaces | Anything printable, including screens and receipts | Needs a chip and antenna attached to the object |
| Damage and replacement | Error-corrected; reprint for free | A crushed antenna is a dead tag; the replacement must be provisioned |
| Operational overhead | None — generate and print | Key custody, provisioning, and a verification service |
| What each scan returns | The same string, forever | A different signed message every tap |
| Secret material involved | None — it is all in the picture | A per-tag AES key held in the chip and never emitted |
| Effect of copying it | The copy is indistinguishable from the original | Copying the URL does not copy the key; the copy fails the MAC |
| Replay of a captured scan | Accepted — it is the same string | Rejected: that counter value has already been seen |
| Identifier privacy | The identifier is printed in the open | Encrypted-PICC mode keeps the UID out of the URL |
| Proves physical presence | No | Yes — of the tag, at the moment of the tap |
Both technologies open an ordinary web page on the phone. Neither requires your customer to install anything.
Not actually a fight
They fail in opposite directions, which is exactly why they pair well.
Care instructions, registration, a manual, a campaign landing page, the thing someone scans from across the store before they have picked the item up. Any camera, any distance, zero cost. This is a genuinely better tool for that job.
The moment where the answer has to be "yes, this specific object is the real one" — at unboxing, at the door, at resale, at warranty registration. That moment needs presence and freshness, and only the chip can supply them.
One design rule if you ship both. Do not let the QR code render the authenticity verdict. A counterfeiter will photograph whichever code produces the green tick, so the verdict must come from the surface that cannot be copied. Print the QR for information; reserve the word "verified" for the tap.
Straight answer
If you recognise yourself in any of these, a QR code is fine for you, and we would rather say so here than sell you a chip you do not need.
A menu, a Wi-Fi password, a review request, a landing page, an event programme. If nobody has any incentive to forge it, cryptographic proof of presence is solving a problem you do not have. Print a QR code.
Millions of low-value items where fractions of a cent decide the programme. A chip per item will not survive that maths, and pretending otherwise wastes your time. If the tag costs a meaningful share of the item, the answer is no.
Printed advertising, a screen, a receipt, an email, a projected slide, a page in a magazine. A chip needs a physical host. If your surface is an image, the only thing that can live on it is an image.
Across a counter, through a window, from a shelf label, off someone else's phone. NFC requires contact by design. If your interaction never involves the customer touching the object, the tap will not happen.
A master key you have to protect, a provisioning pass over NFC, and a decision about custody. It is not enormous, and the key management playbook walks through it — but it is real operational work that a printed code does not require.
If your actual problem is grey-market diversion, warranty fraud by the customer, or supply-chain visibility, then serialisation and good analytics may address it completely, and a QR code carries a serial as well as a chip does.
Straight answers
It proves the tag is genuine, present, and not replayed. Whether that transfers to the item depends on how the tag is attached — a tag that can be peeled off a real item and stuck on a fake one proves only that the tag is real. Design the attachment as carefully as the crypto.
Not always. Some Android phones and versions have a known platform quirk where tapping an NTAG 424 DNA tag doesn't reliably hand the link off to a browser from the home screen or lock screen. It's outside our control, and it varies by device. The reliable workaround is to open the EdgeNFC app and scan the tag from there — same read, same verdict. A QR code has no equivalent failure mode, and that is a fair point against us.
No. We don't sell hardware. You buy blank NTAG 424 DNA tags from a specialist supplier and provision them yourself — see where to buy tags. That means the per-unit cost in the table above is somebody else's price list, not ours, and we are not the right people to quote it.
Not yet. We have not commissioned a third-party audit or obtained any security certification, and we will say so here until that changes. What we can point at today is the design, standard primitives, and conformance against published NXP vectors.
FAQ
No. A QR code is a fixed pattern that encodes a string, so photographing it reproduces it exactly. You can make each code unique per item, and you can watch for a code that suddenly appears in two countries at once, but that is detection after the fact — the code itself holds no secret and cannot prove anything about the object it is printed on.
No. A tap opens an ordinary web page and the verification happens server-side. An app is only needed to provision tags, and on the Android phones affected by the tap-dispatch quirk, where scanning from inside the app is the reliable workaround.
Yes, and it always will be. A QR code costs nothing to print; an NFC tag is a physical chip with a per-unit cost and a one-time provisioning step. The question is not which is cheaper, it is whether the thing you are protecting is worth more than the tag.
Yes, and it is often the right design. Let the QR code do reach — any camera, any distance — and let the tap do proof. Just do not let the QR code display the verification result, because a copied QR code would display it too.
That the specific chip was physically present, held the right key, and produced a counter value never seen before. That is a much stronger statement than a scan can make, and it is still a statement about the tag rather than about the item it is attached to.
Next
The demo runs the real verification core in your browser. Change a byte of the MAC, or reuse a counter, and watch it refuse.