EdgeNFC
EdgeNFC
NTAG 424 DNA vs NTAG 213 / 215
NTAG 213 and 215 are excellent tags, and for most NFC projects they are the correct purchase: cheaper, simpler, and completely adequate when what you need is for a phone to open a link. The 424 DNA costs more and asks more of you. This page is about the one capability you are paying for, and whether you need it.
The short version. Only the NTAG 424 DNA has SDM/SUN. It holds AES keys, computes an AES-CMAC over the data it mirrors into the URL, and increments an internal read counter on every read. A 213 or a 215 has no AES engine to key and nothing to sign with, so it physically cannot produce a code that changes per tap.
Credit where it is due
If your project is on this list, buy the cheaper chip. You will get the same user experience for less money and considerably less work.
An NTAG 213 costs a fraction of what a 424 DNA costs, and the gap is large enough to decide a programme on its own at volume. We do not sell tags and will not quote prices that go stale — ask a supplier, but expect the 213 to win this line decisively.
You write an NDEF URL with any free phone app and you are done. No master key, no per-tag key derivation, no authenticated session with the chip, no custody decision, no verification service to operate.
Published NXP figures: 144 bytes on the 213, 504 on the 215, 888 on the 216, against a 416-byte NDEF file on the 424 DNA. If you are storing a long vCard or a big payload rather than a link, the 215 is both roomier and cheaper.
They are NFC Forum Type 2 tags — the simplest, oldest, most widely supported profile. Every NFC app, every encoder, every hobbyist tutorial handles them. The 424 DNA is a Type 4 device with a file system and secure messaging.
Static lock bits make the URL permanent, and the 32-bit password can gate writes. That is a genuine, useful protection against someone re-pointing your tag at their own site, and it needs no infrastructure at all.
Stickers, wet inlays, cards, wristbands, on-metal, laundry tags — the 213 is in more form factors from more suppliers than the 424 DNA is. Sometimes the deciding factor is simply that the shape you need exists.
Memory figures are from NXP's published datasheets. Check the current revision for the exact part you are ordering before you commit a bill of materials.
The architectural limit
The 213 is not a dumb tag. It has real anti-tamper features, and it is worth being precise about what each one does before deciding it is not enough.
The chip can mirror its 7-byte UID into the NDEF text as ASCII, so your URL carries a per-tag identifier without you writing one. But a UID is a public serial number that any reader can read, and programmable tags that report a chosen UID exist. It identifies; it does not authenticate.
NTAG 213 has a 24-bit one-way read counter that can also be mirrored into the URL. If you check that it only increases, you will catch someone who copied the URL out of a tag and shared it, because their copy carries a stale value. That is worth having, and we would not tell you otherwise.
The mirrored counter is plain text with no MAC over it. It defeats a copied link. It does not defeat a copied tag: anything that can emit an NDEF record of its choosing can emit any counter value it likes, and your server has no way to tell that apart from a real read.
The 32-bit password gates reads or writes to protected pages, which is exactly right for keeping your URL from being overwritten. It is sent to the tag directly rather than as a challenge-response, so it is a shared secret that anyone who observes one successful authentication learns — and it never appears in the tap URL, so it cannot contribute to verifying a tap at all.
NXP ships an ECC signature over the chip's UID that a reader can check to confirm the silicon is genuinely NXP. It is a real cryptographic feature and worth using where you can. But it returns the same bytes on every read, so it can be captured and replayed, and reading it takes an app that issues the command — a plain tap never sees it.
The chip has nowhere to hold a secret key for message authentication and no engine to compute a MAC with. That is the whole story: a per-tap changing code requires a secret plus a computation, and those are silicon features. No amount of clever URL design or server logic adds them later.
What the extra cost buys
Secure Dynamic Messaging is a chip feature. The tag does the cryptography itself, during an ordinary NDEF read, with no app and no pairing.
Each tag's AES-128 key comes from your system master key and the chip's own UID via NXP's AN10922 diversification. The derivation is one-way, so extracting one tag's key in a lab teaches an attacker nothing about the master or any other tag.
Provisioning authenticates to the chip first, then changes keys and file settings inside encrypted, MAC'd secure messaging. The key is written into the chip and is never readable back out of it.
On each read the tag derives a session key from its file-read key, the UID and the read counter, computes an AES-CMAC over the mirrored data, and writes a truncated 8-byte MAC into the URL. The counter moves forward every time.
The verifier re-derives the tag's key, recomputes the MAC, compares constant-time, and rejects any counter value already seen. In encrypted-PICC mode the UID never appears in the URL at all.
Concretely, in the URL. A 213 with mirrors on emits something like ?uid=…&ctr=… — two plain values a reader can trust only as far as it trusts the tag. A provisioned 424 DNA emits ?picc_data=…&cmac=…: 32 hex characters of AES-encrypted UID and counter, plus 16 hex characters of MAC that nobody without the tag's key can produce. Paste either into the free SUN/SDM decoder to see the difference field by field.
Side by side
Two chips, one capability gap, and several rows where the cheaper chip is simply the better answer.
| Property | NTAG 213 / 215 | NTAG 424 DNA |
|---|---|---|
| Price per tag | Lower, by a wide margin | Higher — it is a bigger, cryptographic chip |
| User memory (NXP published) | 144 B (213) · 504 B (215) · 888 B (216) | 416-byte NDEF file |
| NFC Forum type | Type 2 — universally supported, trivial to write | Type 4 with a file system and secure messaging |
| Setup effort | Write a URL with any free app | Keys, an authenticated provisioning pass, a verifier |
| UID mirror | Yes | Yes, and it can be encrypted instead of exposed |
| Read counter | Yes — 24-bit, one-way, mirrored as plain text | Yes — SDMReadCtr, included in the signed message |
| Is the counter authenticated? | No — nothing signs it | Yes — it is covered by the CMAC |
| Secret key on the chip | 32-bit password, sent as-is, not a MAC key | AES-128 keys, never readable, used to sign |
| Per-tap changing code | No — impossible without a MAC key | Yes — a fresh 8-byte CMAC every read |
| Detects a copied URL | Yes, if you check the mirrored counter | Yes — replayed counters are rejected |
| Detects a cloned or emulated tag | No | Yes — the clone cannot compute the MAC |
| Originality signature | Yes — ECC over the UID, static, needs an app to read | Yes, plus per-tap proof that a plain tap can carry |
NTAG 216 is listed for memory only; everything said here about the 213 applies to the 215 and 216 as well, since none of the three has SDM.
Not an either/or
Choose per use, not per company. The chip is a line item, not an identity.
Shelf tags, Wi-Fi handoff, review prompts, the poster in the window, the sample pack, the conference badge that just opens a schedule. Nobody is forging those, and paying for cryptography there is paying for nothing.
The item whose authenticity is the product: the limited run, the luxury piece, the spare part with a safety implication, the ticket that gets someone through a door. If a convincing fake would cost you money or trust, that batch gets the 424.
SDM is silicon. A field of 213s cannot be converted by re-provisioning them, so the choice is made at purchase. If a batch might ever need to prove itself, buy the 424 for that batch even if you switch it on later.
Straight answer
All of these mean the same thing: buy NTAG 213 tags, write a URL, and keep your money. We would rather tell you that than sell you a chip you cannot justify.
If the tag's whole job is to take a phone somewhere, a 213 does that identically for less. Nothing about EdgeNFC makes the link open better, faster, or more reliably — the difference only appears when someone tries to fake the tag.
Low unit value, no resale market, no warranty exposure, no access being granted. The threat model has to contain an actual attacker with an actual incentive, or the cryptography is decoration.
At hundreds of thousands of low-margin units, the per-tag difference is a real budget line and it can be the whole decision. That is a legitimate reason to choose the 213, and no security argument should be allowed to talk you out of arithmetic.
A master key you protect, per-tag keys derived from it, and a provisioning pass over NFC from an Android phone. The key management playbook is honest about the work involved. A 213 requires none of it.
A long vCard, a big offline payload, a multi-record NDEF. The 215 gives you more room than the 424 DNA's NDEF file for less money, and if storage is the requirement, that is the right trade.
If your users will never touch the object, or you need to work on printed surfaces, no NFC chip helps — see NFC vs QR codes for the honest version of that comparison, including the parts QR wins.
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.
No. We don't sell hardware, in either chip family. You buy blanks from a specialist supplier and provision them yourself — see where to buy tags. Every price comparison on this page is therefore directional, not a quote.
No. Memory sizes and feature lists here are taken from NXP's published datasheets and are given so you can sanity-check a purchase, not as a specification we control. Always read the current datasheet revision for the exact part number your supplier is offering.
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. SDM is a feature of the chip, not of the URL written to it. NTAG 213 and 215 have no AES key you can install and no engine to compute a message authentication code over the data they mirror, so they cannot produce a code that changes on every tap. In this comparison only the NTAG 424 DNA can.
It depends on what you need. The password is a 32-bit value sent to the tag directly rather than as a challenge-response, and the read counter is mirrored as plain text with nothing signing it, so anyone who can read the tag once can reproduce both. They are useful features. They are not cryptographic proof of presence.
It is real and it is useful: an ECC signature over the chip's UID that shows the silicon came from NXP. It is also static, returning the same bytes on every read, so it can be captured and replayed, and reading it needs an app that issues the command rather than a plain tap. It speaks to the chip's origin, not to the freshness of this particular tap.
No. It is a different chip, and SDM cannot be added in software. A field of 213s cannot be turned into 424s by re-provisioning them, so if a batch might ever need to prove itself cryptographically, buy the 424 DNA for that batch up front.
Yes. It brings real key management: a master key you have to protect, per-tag keys derived from it, and a provisioning pass over NFC that authenticates to the chip before it changes anything. A 213 needs none of that — you write a URL and you are finished.
Next
The demo runs the real verification core in your browser. Forge a MAC, or replay a counter, and watch it refuse.