NTAG 424 DNA SUN and SDM: How a Tap Proves a Tag Is Real
NTAG 424 DNA doesn't just store a static NDEF link — it rewrites part of that link on every single tap, using AES-128 and a rotating counter to prove the scan is genuine. Here's how SUN and SDM actually work, and where you'll run into them.
What it is (one-paragraph answer)
NTAG 424 DNA is an NFC Forum Type 4 Tag chip that rewrites part of its own NDEF message every time it's tapped, so each scan produces a fresh, cryptographically verifiable proof of authenticity — not a static payload anyone can copy. Under the hood: AES-128 encryption across 416 bytes of user memory, over ISO/IEC 14443 Type A, with five independently configurable application keys controlling read, write, and mirroring permissions per file. That last part matters. A normal NTAG213/215/216 writes one NDEF payload and leaves it there — read it once, and you've read it forever, which is also why a tag's UID was never a strong anti-clone measure on its own. NTAG 424 DNA closes that gap by making the payload itself change on every read.
How it actually works
SDM (Secure Dynamic Messaging) is the feature doing the actual work; SUN (Secure Unique NFC) is what you get out of it. You configure SDM. SUN is the guarantee that falls out the other end.
What gets mirrored into the URL
On a tap, the tag writes a block called PICCData into the NDEF message as ASCII text appended to a URL. PICCData is the tag's UID plus a counter that increments on every read (SDMCounter), and it's encrypted with a dedicated key — the SDMMetaReadKey — before it ever leaves the tag, so the plaintext UID isn't sitting in the URL for anyone to grab. A second key, the SDMFileReadKey, decides whether this mirroring fires on a plain, unauthenticated tap — the normal case for a phone just opening a link.
How the SDMMAC proves the tap is genuine
Alongside PICCData, the tag computes an 8-byte SDMMAC: an AES-CMAC calculated per NIST Special Publication 800-38B, truncated to the 8 even-indexed bytes of the 16-byte output. A backend holding the matching per-tag key decrypts PICCData and recomputes that same MAC. A match means the tap came from a genuine, unmodified tag. Because the counter feeds the calculation and increments on every read, a URL captured from a past tap can't be replayed to fake a new one — the kind of gap that plain NFC leaves open and that other NFC replay risks exploit when a tag has no per-tap authentication at all.
Where you'll see it
The most common deployment is brand protection and channel authentication — fashion, food and beverage, pharmaceuticals, electrical appliances. A shopper taps a product. A backend confirms the tag is genuine and was sold through an authorized channel, no dedicated app required. It's the same idea covered in more retail-facing detail in NFC product authentication and anti-counterfeiting.
There's also a TagTamper variant (424 DNA TT) that layers physical seal-tamper detection on top of the same SUN/SDM mechanism. Once the seal is opened, the chip records that event irrevocably and mirrors the opened status into the next NDEF read — useful for packaging where you want to know, at a glance, whether a product's already been opened.
Tips, gotchas, and reading a 424 DNA tag with NFCore
NFCore's Tag Inspector reads a 424 DNA tag's UID, memory layout, and NDEF content the same way it reads any other supported tag. The SUN/SDM cryptographic check itself happens server-side — NFCore shows you what the tag is broadcasting without needing that backend's keys, handy for confirming a tag's set up the way you expect.
One gotcha: SDM only mirrors correctly if the file's SDM settings and ASCII offsets match your backend's expected query-string format. Get the offsets wrong and the tag still mirrors something into the URL — it just won't land where your server is looking for it.
Curious what a 424 DNA tag is actually broadcasting? Grab NFCore on the App Store or Google Play and check one with the Tag Inspector.
Frequently Asked Questions
What's the difference between SUN and SDM?
SDM (Secure Dynamic Messaging) is the mechanism — it's the tag feature that rewrites part of the NDEF message on every read. SUN (Secure Unique NFC) is the result: a verifiable, non-repeating proof that a specific tap came from a genuine tag. You configure SDM; you get SUN out of it.
Can a SUN/SDM tap URL be copied onto a cloned tag?
No. The URL a phone reads off a NTAG 424 DNA tag changes on every tap, because the mirrored counter increments and feeds directly into the CMAC calculation. Copying yesterday's URL onto a blank tag just produces a URL a backend will reject as stale or already used.
Do I need a special app to read a SUN/SDM tag?
No — that's the point. A plain tap opens the mirrored URL in any browser, the same as tapping a normal NFC tag. The cryptographic verification happens server-side, against the query parameters already embedded in that URL.
Conclusion
NTAG 424 DNA turns "is this tag genuine" into a question a server can answer on every single tap, not just at the first scan — the counter and CMAC baked into each SUN/SDM read make a captured URL useless the moment it's reused. If you're deploying tags for product authentication, pair this with NFC product authentication and anti-counterfeiting for the retail side, and NFC security basics for the broader picture of what per-tap authentication is protecting against.