Choosing your tag — NTAG 424 DNA or NTAG 215#

EdgeNFC works with two chips, and they are not two grades of the same thing. An NTAG 424 DNA can prove a tap came from the original tag. An NTAG 215 cannot, and never will be able to. It routes, it counts taps, and it tells a visitor the tag is registered — nothing more.

Read this before you order tags. Provisioned tags that are already in customers' hands cannot be converted, so this is the one decision in EdgeNFC that is not recoverable after you ship.

Important

The short answer. If a convincing fake would cost you money, a warranty claim, an entry at a door, or your customer's trust — buy NTAG 424 DNA. If the tag's job is to open a link, count the taps, and be recognised by your system, an NTAG 215 does that for less.

Why the choice is permanent#

The ability to prove a tap is a hardware feature. The 424 DNA holds AES-128 keys the chip never lets anyone read back, and computes a fresh code (an AES-CMAC) over its own counter during an ordinary NFC read. The 215 has no key store and no crypto engine, so nothing on the tag can sign anything. No server logic, URL design, or later software release adds that to a 215.

Two consequences follow, and both cost real money if you get them the wrong way round:

• A field of 215s cannot be upgraded by re-provisioning. Re-writing the tag rewrites a URL; it does not add silicon. Upgrading means replacing the physical tags.
• Buying 424 DNA for a batch you might never verify is cheap insurance. You can leave the cryptographic verdict unused; you cannot add it later.

What actually happens when someone taps#

Both chips lead to the same endpoint, the same system lookup, and the same routing rules. What differs is the verdict — and therefore what the visitor is told.

NTAG 424 DNA#

The tag signs each read. EdgeNFC re-derives that tag's key, recomputes the code, and compares it in constant time, then checks the counter has moved forward. The tap lands in one of three states:

NTAG 215#

The tag emits its serial number (UID) and its own read counter as plain text in the URL. Nothing signs either value. EdgeNFC looks the UID up in your registry, checks it belongs to this system and is recorded as a 215, advances the tap count, and honours your routing. The tap lands in one of two states:

The verdict a 215 returns is authentic: null — not assessed. That is its normal, correct, permanent result, not an error and not a degraded mode.

Warning

We never call a 215 tag verified, genuine or authentic — and neither should your copy. The page a visitor sees says the tag is registered, states plainly that this tag type has no security chip, and says we cannot confirm it is the original. Those four words are absent from that page by design, and a build check enforces it. If your marketing wraps a 215 in the word "verified", you have made a claim the hardware cannot support and the product deliberately refuses to make for you.

Feature by chip#

Everything in the "custom routing", "tap counting" and "analytics" rows is the same code path for both chips. A 215 is a smart link with a tap counter — which is honestly what it is, and for a lot of products is exactly what is wanted.

The tap counter is a duplicate signal, not proof#

Both chips count reads, and neither counter should be over-read.

On a 215, the counter is plain text with nothing signing it. If someone copies a tap URL and opens it later, the stale counter surfaces as "Already used" — that is genuinely worth having. It is also all it is worth: a competent copy simply increments the counter, and the server has no way to tell that from a real read. A counter value is never evidence that a 215 is the original, in any combination, and EdgeNFC will not present it as such.

On a 424 DNA, the counter is inside the signed message, so a replay is rejected outright and a forged counter cannot be produced without the tag's key. That is the difference you are paying for.

Note

A 215's NFC read counter never resets. It is one-way silicon: it cannot be zeroed. A tag that is re-provisioned legitimately resumes partway up — its first tap under a new registration may report tap #4711. EdgeNFC treats "we have not seen this tag before" as first contact, never "the counter is 0 or 1". Do not build a rule that treats a low count as new or a high count as suspicious; both are wrong, and both will misfire on honest tags.

Privacy: where the UID goes#

A 424 DNA can be provisioned in encrypted-PICC mode: the chip encrypts its identity and counter into a single blob that changes completely on every read, so the URL carries no serial number and two taps of the same tag do not visibly belong together. You turn it on with the UID privacy switch on the system — free on every plan — which also marks the system for encrypted-PICC provisioning. The mode is fixed in the chip when the tag is written, so it applies to tags you encode from then on and cannot reach tags already in the field.

A 215 cannot do this. Its UID is mirrored into the URL by the chip in plain text on every tap; that is how the tag is identified at all. The per-system privacy toggle keeps the UID off the displayed page, and that is worth turning on, but the value is still in the address bar, in browser history, and in any analytics that sees the link. If not exposing per-item serial numbers matters to you, that is a reason to choose the 424.

Mixing both chips#

You can. Tags are registered per UID with the chip family recorded against them, so one system can hold 424 DNA tags on the items that must prove themselves and 215s on the ones that only need to route — with one set of routing rules and one analytics view over both.

Mixing does not weaken the 424s. A tap that presents a 424's UID through the 215 path — the obvious attempt at downgrading a tag to a verdict that needs no signature — is rejected as unknown_uid. Registration as a 215 is checked, not assumed.

What a tap feels like on a recent Android phone#

Both chips hold an ordinary https:// link, so both are affected identically by recent Android changes. None of this is a reason to prefer one chip over the other, but it does change what you should tell customers and put on in-store signage.

• Android 16 and later: scanning a tag that stores a web link (http:// or https://) fires the ACTION_VIEW intent instead of ACTION_NDEF_DISCOVERED — the link is handled like a link.
• Android 17 and later: scanning such a tag surfaces an "open link" notification, and the person must tap it before the URL opens. Expect one extra confirmation between the tap and your page.
• Android 16 and later also added a per-app allowlist for NFC tag scanning: the first time an app receives an NFC tag intent, the user is notified and can disallow that app from scanning tags again. It lives under Settings → Apps → Special app access → Launch via NFC, and apps can check their state with NfcAdapter.isTagIntentAllowed() or ask again with ACTION_CHANGE_TAG_INTENT_PREFERENCE.

Source: Android's NFC basics documentation.

Warning

A separate, EdgeNFC-specific limit on NTAG 424 DNA. On Android 16+, the OS does not reliably NDEF-dispatch NTAG 424 DNA tags (a platform regression we hit on real hardware), so a tap may do nothing from the home or lock screen. The workaround is to scan the tag from inside the EdgeNFC app, which reads and verifies it directly — same read, same verdict. This is a 424-specific finding; we have not measured the same behaviour on a 215, so do not assume either way. iOS and pre-16 Android read these tags natively.

If you already have NTAG 215 tags in the field#

Tags written by an earlier version of the provisioning app carry a URL that no longer resolves to a tap: it pointed at the site root with the mirror parameters attached, so the tap returned the marketing homepage and the parameters were ignored. Those tags are not faulty and their chips are fine — the address they carry is simply not one that serves a tap.

They must be re-written with the current app to work. A 215 has no keys, so re-provisioning is a plain NDEF rewrite rather than a keyed operation — but it needs physical access to every tag. If you have 215s with customers, plan for that, and do not assume a server-side fix can reach them.

Choosing#

Buy NTAG 424 DNA when:

• someone has a financial or reputational incentive to fake your item;
• a tap grants something — entry, a warranty, a claim, a reward;
• you need to detect a cloned tag, not merely a copied link;
• you do not want per-item serial numbers travelling in URLs.

Buy NTAG 215 when:

• the tag's job is to open a link, and be recognised and counted as one of yours;
• nobody has a reason to counterfeit the item;
• you want re-pointable routing and tap analytics without any key management;
• unit price or provisioning effort decides the programme.

If you are unsure, split the batch. Put 424 DNA on the items whose authenticity is the product, and 215s on everything informational.

Check it yourself before you commit#

Provision one of each and tap them:

1. Tap a provisioned 424 DNA. The page reads Genuine. Copy the URL out of the address bar and open it again — it comes back Already used (reason: non_monotonic). Change one character of the mac parameter — Not verified (reason: mac_mismatch), and no redirect to your destination.
2. Tap a provisioned 215. The page reads Registered tag, with the tap count and, on the first tap EdgeNFC has seen, first scan. Nowhere on that page does it claim the tag is the original. Open the same URL again — Already used.
3. Set a custom route on the system (Creator+) and tap both again. Both redirect to your destination; a mangled URL of either kind does not, and never reveals the destination.

That is the whole difference, demonstrated on your own tags in five minutes — and it is much cheaper to see now than after a production run.

Related#

• Where to buy tags — form factors and suppliers for NTAG 424 DNA.
• NTAG 424 DNA vs NTAG 213 / 215 — the chip-level comparison, including NXP's published memory figures and where the cheaper chip is simply the better buy.
• Android provisioning — encoding both chip families with the app.
• Key management & security — the work a 424 DNA deployment actually involves.
• E-commerce / Shopify — custom routing, which behaves the same on both chips.