Introduction: The Question Nobody Asks Until It Is Too Late

 

Almost every conversation about NFC hardware starts in the wrong place. Someone asks how much the tags cost, how quickly they can be delivered, and whether they can be printed with a logo. Nobody asks the only question that actually determines whether the deployment survives contact with the real world: which chip is inside?

 

That question sounds pedantic. It is not. The silicon inside an NFC tag decides how much data you can store, whether the data can be altered by a stranger with a phone, whether a counterfeiter can clone your product in an afternoon, whether the tag still works after five years in a warehouse, and whether the tag can be read by an iPhone at all. Two tags that look physically identical — same size, same material, same price bracket — can differ by a factor of fourteen in memory and by an entire generation in cryptographic capability.

 

The confusion is understandable. The naming is genuinely awful. NXP alone ships NTAG, NTAG DNA, MIFARE Ultralight, MIFARE Classic, MIFARE Plus, MIFARE DESFire and ICODE, several of which overlap in capability and none of which are named in a way that suggests where they sit in the hierarchy. STMicroelectronics ships ST25TA, ST25TN, ST25TV and ST25DV. Infineon, EM Microelectronic, Silicon Craft and half a dozen Chinese fabs ship compatible parts under names that mean nothing to anyone outside procurement.

 

This guide fixes that. It is a complete, structured, engineering-level tour of the NFC chip landscape as it stands in 2026: what each family is, what is actually inside it, what it costs, what it is genuinely good at, where it fails, and how to pick the right one for a given job. It is written for people who have to make a decision and would rather make it from evidence than from a supplier’s brochure.

 

We will cover:

 

• The three-layer model that explains why chips differ at all
• The NXP NTAG family — the workhorse of consumer NFC
• NTAG 424 DNA and the SUN mechanism that changed product authentication
• MIFARE Ultralight, Classic, Plus and DESFire EV3
• STMicroelectronics ST25, and why dynamic tags are a different category
• ISO 15693 / NFC Forum Type 5 and long-range vicinity tags
• Clones, compatibles and how to detect them
• A structured decision framework with real selection criteria
• Cost, lifecycle, durability and procurement realities

 

If you have not yet read the companion piece on the physics of the air interface, it is worth understanding how a passive tag draws power out of a magnetic field before you dig into what the silicon does with that power. Everything below assumes 13.56 MHz inductive coupling as a given.

 

Part One: Why Chips Differ at All — The Three-Layer Model

 

Every NFC tag on the market can be described with three independent variables. Almost all buying confusion comes from conflating them.

 

Layer 1: The air interface

 

This is the radio conversation. There are two that matter in practice:

 

• ISO/IEC 14443 Type A — the proximity standard. Operating range measured in centimetres, 106 kbit/s baseline (up to 848 kbit/s for higher-end parts), anti-collision built in. This is what phones speak natively and what virtually every consumer NFC product uses.
• ISO/IEC 15693 — the vicinity standard. Longer range (tens of centimetres with the right reader), slower, designed for inventory-style bulk reading. Phones support it, but with less consistency and with far more variability in real-world reliability.

 

A chip’s air interface is not a quality signal. It is a category signal. A 15693 chip is not “better” than a 14443 chip; it is for a different job.

 

Layer 2: The data model

 

This is how the tag organises bytes. Three broad approaches:

 

• Flat page memory (Type 2 tags): the chip is a simple array of 4-byte pages. The reader reads and writes pages. NDEF is layered on top as a convention. Simple, fast, cheap. NTAG21x and MIFARE Ultralight live here.
• File systems (Type 4 tags): the chip exposes an ISO/IEC 7816-4 file structure, with an application, files, and per-file access rights. More overhead, far more capability. NTAG 424 DNA and DESFire live here.
• Sector-and-block memory with per-sector keys: MIFARE Classic’s model. Sixteen-byte blocks grouped into sectors, each sector guarded by two keys and an access-condition bitfield. Powerful in 1994. A liability in 2026.

 

Layer 3: The security model

 

This is where the real money and the real risk sit:

 

• None. The tag is a memory chip. Anyone can read it, and unless you lock it, anyone can rewrite it.
• Password / PWD-PACK. A 32-bit password gates writes (and optionally reads). Sufficient to stop casual tampering. Trivially bypassed by anyone determined and equipped, because the password crosses the air interface in the clear on most implementations.
• Symmetric cryptography (3DES / AES-128). Mutual authentication, encrypted sessions, message authentication codes. This is the boundary between “consumer convenience” and “security product.”
• Cryptographic message authentication on read (SUN). The newest and most useful category for authentication use cases; explained in depth later.
• Certified secure elements. Common Criteria EAL4+ / EAL5+ evaluated silicon with hardware countermeasures against side-channel and fault-injection attacks.

 

Hold those three layers in your head and every chip below stops being a mystery name and becomes a coordinate in a three-dimensional space.

 

Part Two: The NTAG Family — The Workhorse of Consumer NFC

 

If you have ever tapped a smart poster, an NFC-enabled event badge, a Bluetooth speaker’s pairing tag, an amiibo figure, or a contactless business card, you have almost certainly interacted with an NTAG21x.

 

NXP developed NTAG213, NTAG215 and NTAG216 as standard tag ICs for mass-market applications, fully compliant with NFC Forum Type 2 Tag and ISO/IEC 14443 Type A, communicating at 106 kbit/s. They are the default answer to “I need a tag that holds a URL and works on every phone.” NXP’s own datasheet lists the target applications as smart advertising, product authentication, shelf labels, mobile companion tags — and business cards.

 

The three parts, precisely

 

The only meaningful difference between them is user memory. Everything else — the protocol, the commands, the phone compatibility, the read speed — is identical.

 

Part	Total memory	User memory (NDEF-usable)	Practical URL capacity	Typical use
NTAG213	180 bytes	144 bytes	~130 characters	Smart posters, short links, most business cards
NTAG215	540 bytes	504 bytes	~490 characters	amiibo, richer payloads, small vCards
NTAG216	924 bytes	888 bytes	~870 characters	Full vCards, multi-record NDEF, WiFi credentials

 

The user-memory figures are the numbers that matter and the numbers most suppliers quote incorrectly. “NTAG213 has 180 bytes” is technically true and practically misleading — 36 bytes are consumed by the UID, lock bytes, capability container, configuration pages and password area. You get 144.

 

What is actually in the memory map

 

An NTAG21x is organised as 4-byte pages. The layout is fixed and worth knowing because it explains most of the odd behaviour engineers encounter:

 

Pages	Contents	Notes
0x00–0x02	UID, internal byte, static lock bytes	UID is 7 bytes, factory-programmed, read-only
0x03	Capability Container (CC)	Declares tag type and usable memory to the reader; one-time programmable
0x04 onward	User memory (NDEF)	144 / 504 / 888 bytes depending on part
Dynamic lock bytes	Write-lock control for upper memory	Set these and the region becomes read-only forever
CFG0 / CFG1	Configuration: mirror settings, AUTHLIM, access flags	Controls UID/counter mirroring and password behaviour
PWD / PACK	32-bit password + 16-bit acknowledge	Optional write (or read/write) protection

 

Two features in that table deserve attention because they are routinely underused.

 

The NFC counter. NTAG213, 215 and 216 include a 24-bit one-way read counter that increments on each read. It cannot be decremented or reset. Combined with ASCII mirroring, the chip can automatically inject the current counter value — and the UID — into the URL it serves, without any change to the stored NDEF record. This means a tag can serve https://example.com/p?uid=04A2…&ctr=000173 and your server can see, per tag, exactly how many times it has been read. That is analytics with no app, no battery and no cost. It is also a weak anti-cloning signal: a cloned tag’s counter will not track the original’s.

 

The ASCII mirror. The mirror feature writes the UID and/or counter as ASCII directly into the NDEF message at a configurable offset. It is the reason a properly configured tag can be uniquely identifiable while every unit in the batch is encoded with the same base URL. If your supplier tells you each tag must be individually encoded with a unique URL, they are either not using mirroring or not using NTAG.

 

NTAG213 TT — the tamper variant

 

NTAG213 TT adds a tamper loop: a conductive trace that, when broken, changes the tag’s response. It is used on bottle seals, pharmaceutical packaging and tamper-evident labels. The tag can serve one URL when sealed and a different status when the loop is cut, which lets a brand distinguish “sealed original” from “opened” in a single consumer tap.

 

Where NTAG21x is the right answer

 

• Any application where the data is public and non-sensitive (a URL, a vCard, a WiFi credential)
• Any application requiring universal phone compatibility with zero friction
• Any application where unit cost matters and volumes are meaningful
• Contactless business cards, which is why the cards built by Evrycard and every other serious vendor in the category are built on NTAG silicon rather than repurposed access-control chips

 

Where NTAG21x is the wrong answer

 

• Anything requiring the tag to prove it is genuine
• Anything storing personal or confidential data on the chip itself
• Anything where an attacker benefits from rewriting the tag and where you cannot lock it
• Access control (an NTAG UID can be emulated by a £30 device; UID-based door systems built on NTAG are security theatre)

 

That last point is worth stating bluntly because it is one of the most common and most expensive mistakes in the industry: a UID is an identifier, not a credential. It is transmitted in the clear, before any authentication, by design. Any system that grants access based on reading a UID can be defeated by anything that can transmit that UID.

 

Part Three: NTAG 424 DNA — When the Tag Has to Prove It Is Real

 

The single biggest limitation of a conventional tag is that reading it proves nothing. A tag says “here is a URL.” A photocopy of that tag also says “here is a URL.” From the server’s point of view, the two are indistinguishable. For a poster this does not matter. For a bottle of single-malt whisky, a luxury handbag, a pharmaceutical carton or a warranty claim, it matters enormously.

 

NTAG 424 DNA is NXP’s answer, and it changed the economics of physical product authentication.

 

What it is, technically

 

NTAG 424 DNA is an NFC Forum Type 4 Tag over ISO/IEC 14443-A, which means it exposes an ISO/IEC 7816-4 file system rather than flat pages. The memory is 416 bytes, organised as:

 

File	Size	Purpose
Capability Container	32 bytes	Standard T4T discovery structure
NDEF file	256 bytes	The URL or message served to a phone
Protected data file	128 bytes	Requires mutual authentication to read

 

The headline features from NXP’s specification:

 

• AES-128 cryptography for authentication and secure messaging, with an optional LRP (Leakage Resilient Primitive) wrapped AES mode for higher attack resistance
• SUN message authentication on every standard NDEF read
• 3-pass mutual authentication for the protected file
• Common Criteria EAL4 certification for hardware and software
• ECC-based NXP originality signature plus AES-128 originality check
• Random ID and encrypted UID for privacy
• On-chip assembly of item URLs via flexible ASCII mirrors
• Communication speeds up to 848 kbit/s

 

SUN: the mechanism worth understanding

 

SUN stands for Secure Unique NFC message. It is deceptively simple and genuinely clever.

 

When a phone reads a normal tag, the tag returns a fixed URL. When a phone reads an NTAG 424 DNA configured for SUN, the tag computes part of the URL at read time. Specifically, it appends:

 

1. An encrypted PICC data block containing the UID and a read counter, encrypted with a key only the tag and your server hold
2. A CMAC — a cryptographic message authentication code over that data

 

The resulting URL looks something like:

 

“`

https://brand.example/v?picc_data=EF963FF7828658A5&cmac=94EED9EE65337086

“`

 

The phone does not need an app. It does not need to understand cryptography. It opens the URL as it would any other. The intelligence lives on your server, which:

 

1. Decrypts picc_data with the tag’s key
2. Recovers the true UID and the read counter
3. Verifies the CMAC
4. Checks that the counter is higher than the last counter seen for that UID

 

If the CMAC verifies and the counter has advanced, the tag is genuine and this is a fresh read. If someone photographs the URL and shares it, the counter will not have advanced — replay detected. If someone clones the memory contents onto a blank tag, the clone cannot compute a valid CMAC for a new counter value, because it does not have the key. The key never leaves the chip.

 

This is the property that matters: the tag proves it exists, in the field, at read time, without an app. No prior NFC technology delivered that at consumer price points.

 

NTAG 424 DNA TagTamper

 

The TagTamper variant (NT4H2421Tx) adds the tamper loop concept to the DNA architecture, so the SUN message itself carries authenticated tamper status. A brand can therefore verify, cryptographically, not only that the seal is genuine but that it has not been broken. For pharmaceuticals, spirits, cosmetics and anything with a grey-market problem, this is the current state of the art.

 

The cost and complexity trade

 

NTAG 424 DNA costs several times what an NTAG213 costs, and — more significantly — it requires infrastructure. You need key management, a provisioning process, a verification endpoint, counter storage and a policy for what happens when verification fails. It is not a chip you drop into an existing workflow; it is a system.

 

Which means the honest guidance is: use NTAG 424 DNA when authenticity is the product. Do not use it for a business card. A business card whose URL can be copied is not a security failure — sharing the URL is the entire point.

 

Part Four: The MIFARE Family — Access Control, Transit, and a Cautionary Tale

 

MIFARE is not a chip. It is a brand covering several architecturally unrelated product lines, all owned by NXP, all running at 13.56 MHz on ISO/IEC 14443A. Understanding that the word “MIFARE” on a datasheet tells you almost nothing is the first step to buying competently.

 

MIFARE Ultralight — the disposable ticket chip

 

The base Ultralight carries 64 bytes in sixteen 4-byte pages, with no on-board cryptography — just one-time-programmable bits and per-page write locks. Ultralight C adds 192 bytes and 3DES authentication. Ultralight EV1, Nano and AES variants adjust memory and add password protection or AES.

 

Ultralight is the close sibling of NTAG: both are memory-only parts at 13.56 MHz. The distinction is intent. NTAG follows the NFC Forum Type 2 specification for NDEF, so a phone reads it and does something useful. Ultralight mostly speaks raw ISO 14443-3 and lives in closed-loop ticketing, where a proprietary reader — not a phone — interprets the bytes.

 

Practical consequence: if a supplier offers you “MIFARE Ultralight NFC cards” for a phone-facing consumer application, ask specifically whether the chip is NDEF-formatted and whether iOS reads it reliably. Frequently the honest answer is “sort of.”

 

MIFARE Classic — the most deployed broken cipher in history

 

MIFARE Classic was introduced by Philips (now NXP) in 1994 and became the dominant contactless card globally, with billions deployed across transit, access control and loyalty. It comes as Classic 1K (16 sectors) and Classic 4K (40 sectors). Each sector holds 16-byte blocks plus a sector trailer containing two keys (Key A and Key B) and an access-condition bitfield.

 

Its security rests on Crypto-1, a proprietary 48-bit LFSR stream cipher NXP designed in-house. In 2008, researchers including Karsten Nohl reverse-engineered it; by 2009, practical attacks recovered sector keys in seconds. NXP responded with hardened Classic EV1 silicon — and in 2015, Meijer and Verdult published attacks that broke those too. Consumer-grade tools such as Proxmark3 and Flipper Zero have since made cloning a routine exercise rather than a research project.

 

The uncomfortable truth is that MIFARE Classic remains everywhere — hotel key cards, office badges, gym entry, some transit systems — because the installed reader base is enormous and replacing it is capital expenditure that nobody wants to sign off. NXP itself recommends migration.

 

If you are specifying a new access-control system in 2026 and someone proposes MIFARE Classic, the correct response is a firm no. There is no scenario in which it is the right choice for a new deployment. It exists in the market as legacy inertia, not as a product recommendation.

 

MIFARE Plus — the migration path

 

MIFARE Plus was designed as the drop-in upgrade for Classic installations. It can operate in a Classic-compatible security level and be upgraded in the field to AES-128, allowing an estate to be migrated card-by-card and reader-by-reader rather than in a single expensive cutover. It is a sensible product for organisations trapped in a Classic estate. It is not what you would choose on a blank sheet.

 

MIFARE DESFire EV3 — the serious one

 

DESFire is a different animal entirely: a microcontroller-based smart card with a real operating system, not a memory chip with a lock bit.

 

Key characteristics of DESFire EV3:

 

• Memory options of 2 KB, 4 KB or 8 KB EEPROM
• A genuine file system supporting up to 28 applications, each with up to 32 files
• AES-128, 2K3DES and 3K3DES cryptography with mutual authentication and encrypted, MAC’d sessions
• Common Criteria EAL5+ certification of the hardware and OS
• Transaction MAC and value files with built-in integrity for stored-value applications
• Proximity check — a distance-bounding protocol that measures command timing to defeat relay attacks
• Delegated application management, allowing multiple independent operators to occupy the same card without trusting each other

 

That last feature is why DESFire dominates multi-application deployments: a single card can carry a transit operator’s ticketing application, a university’s door credential, and a canteen payment purse, each cryptographically isolated, each managed by a different party.

 

The MIFARE comparison, in one table

 

Product	Architecture	Memory	Crypto	Certification	Verdict for new builds
Ultralight	Memory, page-based	64 B (EV1/C variants larger)	None / 3DES / AES variants	—	Disposable tickets only
Classic 1K/4K	Sector/block memory	1 KB / 4 KB	Crypto-1 (broken)	—	Do not specify
Plus	Sector/block, upgradeable	2 KB / 4 KB	AES-128	EAL4+ (SL3)	Only for Classic migration
DESFire EV3	Microcontroller + file system	2 / 4 / 8 KB	AES-128, 3DES, 3K3DES	EAL5+	The default for access control

 

NTAG vs MIFARE: the question everyone actually asks

 

The phrasing “NTAG vs MIFARE” is a category error, but the intent behind it is real. Here is the honest answer:

 

• You want a phone to read a URL and open a web page → NTAG. Every time. It is the NFC Forum Type 2 standard, it is universally supported, and it is the cheapest reliable option.
• You want a door to open, a turnstile to unlock, or a balance to be debited → DESFire EV3. It is a credential, not a bookmark.
• You want a product to prove it is genuine → NTAG 424 DNA.
• You want a single-use paper ticket → Ultralight.
• You want to specify MIFARE Classic → you do not.

 

Part Five: STMicroelectronics ST25 — The Alternative Ecosystem

 

NXP dominates the conversation, but it does not own the market. STMicroelectronics’ ST25 family is the most credible alternative, and in several categories it is the better choice.

 

ST25 spans both major air interfaces — ISO/IEC 14443 and ISO/IEC 15693 — which itself distinguishes it from NXP’s more segmented lineup. The family breaks down as:

 

Series	Type	Distinguishing capability	Typical application
ST25TA	NFC Forum Type 4	ISO 7816-4 file system, password protection, up to 64 Kbit	Smart packaging, consumer electronics pairing
ST25TN	Type 2-class with augmented NDEF	On-chip dynamic URL generation and tag authentication	Brand protection at lower cost than full crypto
ST25TV	NFC Forum Type 5 (ISO 15693)	Tamper detection, untraceable mode, longer read range	Retail inventory, tamper-evident labels
ST25DV	Dynamic tag	I²C bridge to a host MCU, energy harvesting, RF/I²C mailbox	IoT devices, industrial configuration, firmware transfer

 

Dynamic tags: a genuinely different category

 

ST25DV deserves special attention because it breaks the mental model most people have of an NFC tag.

 

A conventional tag is a passive memory that a reader talks to. A dynamic tag has two interfaces: the RF side facing the phone, and an I²C bus facing a microcontroller inside the product. Both can access the same memory. The chip also provides a mailbox — a fast buffer for passing messages between the two domains — and energy harvesting, extracting a few milliwatts from the reader’s field to power external circuitry.

 

The consequences are large:

 

• A product with no display and no buttons can be configured by tapping a phone against it — the phone writes to the mailbox, the MCU reads it over I²C
• A device with a dead battery can still report its serial number, error code and warranty status, because the reader’s field powers the tag
• Firmware can be transferred to a sealed, waterproof product with no connector
• A factory can program calibration data into a finished, boxed device without opening the box

 

This last point alone has justified ST25DV designs in medical devices, industrial sensors and consumer appliances. It is not a business-card technology; it is an embedded-systems technology that happens to use the same radio.

 

Other silicon vendors worth knowing

 

• Infineon — strong in secured elements and government ID; less present in the commodity tag market.
• EM Microelectronic (Swatch Group) — EM4425 “em|echo-V” notably supports both NFC and UHF RFID in a single die, which solves a real supply-chain problem where a pallet needs long-range reading and the retail unit needs phone reading.
• Silicon Craft, Fudan Microelectronics, Shanghai Huahong — high-volume commodity and compatible parts, common in low-cost tags.

 

Part Six: ISO 15693 and NFC Forum Type 5 — The Long-Range Option

 

Everything discussed so far except ST25TV operates on ISO/IEC 14443, the proximity standard. ISO/IEC 15693 — the vicinity standard — is the road less travelled, and it is worth knowing when to take it.

 

What it gives you: read range measured in tens of centimetres rather than centimetres, with the right reader antenna. Bulk reading of many tags. Better behaviour when tags are stacked or hidden inside packaging.

 

What it costs you: slower data rates, more variable phone support (both Android and iOS can read Type 5, but real-world reliability across handsets is noticeably less uniform than Type 2/Type 4), and a smaller ecosystem of encoding tools and off-the-shelf inlays.

 

When it is correct: library book tagging, laundry and linen tracking, medical instrument trays, laboratory sample management, warehouse and asset inventory — anything where you sweep a reader over many items rather than deliberately tapping one.

 

When it is wrong: any consumer-facing tap interaction. The whole value of a tap is its precision and intentionality. Vicinity coupling actively undermines that.

 

ICODE (NXP) and ST25TV (ST) are the dominant families here.

 

Part Seven: Clones, Compatibles and “NTAG-Compatible”

 

There is a large grey market in chips described as “NTAG213 compatible,” “NTAG215 compatible” or simply “NFC 215.” They are not counterfeit in the criminal sense — they are independently manufactured parts that implement the Type 2 command set and present a compatible memory layout. They generally work.

 

Generally.

 

The differences that bite:

 

Attribute	Genuine NXP NTAG21x	Typical compatible
EEPROM data retention	Specified at 10 years	Often unspecified
Write endurance	Specified at 100,000 cycles	Often unspecified
Originality signature	ECC signature verifiable against NXP public key	Absent or forged/copied
Configuration behaviour	Fully documented and consistent	Edge cases diverge (mirroring, AUTHLIM, lock semantics)
RF input capacitance	Tightly controlled	Varies, affecting antenna tuning and range
Batch consistency	High	Variable between production runs

 

The two that cause the most real-world pain are RF input capacitance and configuration edge cases. Capacitance variance means an antenna tuned for genuine silicon may perform noticeably worse with a compatible part — which manifests as “the cards from the second batch don’t read as well,” a complaint that is maddening to diagnose because nothing visible changed. Configuration divergence means features like ASCII mirroring or password behaviour may work in testing and fail in production.

 

How to verify what you actually received

 

1. Read the originality signature. Genuine NXP parts carry an ECC signature over the UID, verifiable against NXP’s published public key. NXP’s TagInfo app and several open-source tools do this in one tap.
2. Check the UID prefix. NXP-manufactured chips begin with manufacturer byte 0x04. It is not proof — the byte can be spoofed on writable-UID tags — but a non-0x04 prefix on a chip sold as NXP is conclusive evidence that it is not.
3. Read the version block. The GET_VERSION command returns product type, subtype, major/minor version and storage size. Compare against the datasheet.
4. Ask for the part number in writing. Not “NFC chip.” Not “high-capacity NFC.” The specific part: NTAG213, NTAG215, NTAG216, NTAG424 DNA, MF0UL11, MF3D8301. A supplier who will not put the part number on the quotation either does not know it or does not want you to.

 

Whether compatibles are acceptable depends entirely on the application. For a promotional campaign with a six-week life, they are fine and the saving is real. For a professional card someone will carry for three years, specify genuine silicon and pay the few pence difference. The failure mode is not “the card is slightly worse”; it is “the card stops working in month eighteen and the person blames you.”

 

Part Eight: The Variables That Are Not the Chip

 

A great deal of what buyers attribute to chip quality is not the chip at all. Three factors dominate perceived performance.

 

Antenna geometry

 

Coupling efficiency scales with the area enclosed by the antenna coil. A full credit-card-format inlay encloses roughly ten times the area of a 25 mm circular sticker. The identical chip in both will deliver dramatically different read distance and dramatically different tolerance for imperfect alignment.

 

This is why comparing a card-format tag against a keyfob or a small label tells you nothing about the silicon. You are measuring geometry. If you are running a bench comparison between suppliers, hold format constant or the result is meaningless.

 

Metal and the detuning problem

 

Metal near an NFC antenna absorbs the magnetic field via eddy currents and detunes the resonant circuit. The result is a tag that does not read at all. This is not a defect and it is not fixable by choosing a better chip.

 

The solution is a ferrite isolation layer between the antenna and the metal, which redirects flux around the conductor. Metal NFC cards, metal asset tags and phone-mounted tags all depend on it. Ferrite adds thickness, cost and manufacturing complexity — which is precisely why metal NFC cards cost several times what PVC cards cost, and why cheap “metal” cards often turn out to be metal-effect plastic.

 

Encapsulation and environment

 

EEPROM retention specifications assume reasonable conditions. Sustained high temperature accelerates charge loss. Repeated mechanical flexing fatigues the antenna-to-die bond, which is the single most common physical failure mode in card-format tags — the chip is fine, the connection is not. Moisture ingress corrodes the aluminium or copper antenna trace.

 

For anything expected to survive years in a wallet, in a vehicle, or outdoors, the encapsulation specification deserves as much scrutiny as the chip specification.

 

Part Nine: Phone Compatibility — What Actually Reads What

 

A chip that a phone cannot read is a paperweight. The compatibility picture in 2026:

 

Tag type	Android	iOS (background)	iOS (in-app)
Type 2 (NTAG21x, Ultralight)	Full	Yes, from iPhone 7 / iOS 11+ (URL records)	Full via Core NFC
Type 4 (NTAG 424 DNA, DESFire NDEF)	Full	Yes	Full
Type 5 (ISO 15693, ST25TV, ICODE)	Yes, device-dependent	Yes, iPhone 7+	Yes
MIFARE Classic (proprietary sectors)	Yes on NXP-based Android chipsets only	No	No

 

Two points carry practical weight.

 

Background reading on iOS requires the tag to serve a well-formed NDEF URI record. If the tag holds raw bytes, a malformed record, or a proprietary structure, iPhones will not surface a notification and the user experience simply does not exist. This is the single most common cause of “it works on Android but not iPhone.”

 

MIFARE Classic is effectively unreadable on iOS at the sector level. Core NFC does not expose Crypto-1 authentication. Any consumer-facing product built on Classic excludes roughly half the smartphone market in most Western countries.

 

Part Ten: Cost, Volume and Lifecycle

 

Approximate unit economics at meaningful volume (chip cost only, before inlay, conversion, printing, encoding and margin):

 

Chip	Indicative chip cost	Cost driver
Compatible Type 2	pennies	Commodity silicon
NTAG213	low pennies	Volume standard part
NTAG216	~2–3× NTAG213	Die area for 888 bytes
MIFARE Ultralight EV1	comparable to NTAG213	Commodity
NTAG 424 DNA	~5–10× NTAG213	Crypto engine, EAL4 certification
DESFire EV3 2K	~10–20× NTAG213	Microcontroller, OS, EAL5+
ST25DV	Similar to DESFire band	Dual interface, energy harvesting

 

Two observations that consistently surprise buyers:

 

The chip is rarely the dominant cost. In a finished metal card, the chip may be two per cent of the bill of materials. Choosing NTAG213 over NTAG216 to save a penny on a £25 product is optimising the wrong variable — and it is the reason so many cards ship with 144 bytes when the customer later wants a full vCard.

 

The expensive part of secure chips is the system, not the silicon. NTAG 424 DNA at scale is affordable. The key management infrastructure, the verification service, the provisioning pipeline and the operational policy around failed verifications are what the project actually costs.

 

Part Eleven: A Decision Framework

 

Work through these in order. Each question eliminates whole families.

 

1. Does a phone need to read it without an app?

Yes → NFC Forum Type 2, 4 or 5 with valid NDEF. No → the field opens up to proprietary and closed-loop options.

 

2. Does the tag need to prove it is genuine?

Yes → NTAG 424 DNA, ST25TN, or DESFire with mutual authentication. No → proceed.

 

3. Does the tag grant access to something valuable?

Yes → DESFire EV3 with AES and, if relay attacks are in scope, proximity check. Never a UID-only scheme. No → proceed.

 

4. Does data need to be written in the field, by users?

Yes → password-protected NTAG21x at minimum; DESFire if the data has value. No → lock the tag after encoding.

 

5. How much data must live on the chip?

Under 130 characters → NTAG213. Under 490 → NTAG215. Under 870 → NTAG216. More → Type 4 with a file system, or reconsider the architecture and store a short URL instead.

 

6. Does the tag talk to a host microcontroller?

Yes → ST25DV or an equivalent dynamic tag with I²C. No → proceed.

 

7. Do you need to read many tags at once, at distance?

Yes → ISO 15693 / Type 5. No → ISO 14443 Type A.

 

8. What is the service life?

Under a year → compatibles are defensible. Multi-year → genuine silicon with published retention and endurance figures.

 

The short version

 

If you are building…	Specify
Contactless business cards	NTAG213 (or 215/216 for richer payloads), locked, short URL
Smart posters / marketing campaigns	NTAG213 with counter + ASCII mirror for analytics
Product authentication	NTAG 424 DNA with SUN, server-side verification
Tamper-evident packaging	NTAG 213 TT or NTAG 424 DNA TT
Office / campus access control	MIFARE DESFire EV3 with AES-128
Transit ticketing	DESFire EV3 (season) + Ultralight (single use)
Warehouse / asset inventory	ISO 15693 — ICODE or ST25TV
Embedded device configuration	ST25DV or comparable dynamic tag

 

Part Twelve: The Procurement Checklist

 

Send these questions to any supplier before you commit to volume. The quality of the answers tells you more than the quality of the samples.

 

1. What is the exact chip part number? Written on the quotation.
2. Is it genuine NXP / ST / Infineon silicon, or a compatible? If compatible, from which fab?
3. What is the usable user memory in bytes after the capability container and configuration pages?
4. Will the tag be locked after encoding? If not, why not?
5. Will the tag hold a short URL or a raw vCard? If a vCard, what happens when the person changes job title? The answer is “you buy new cards.”
6. Is the NDEF record a well-formed URI record that triggers iOS background reading? Show me on an iPhone.
7. What is the specified data retention and write endurance?
8. For metal products: what is the ferrite specification?
9. Can you provide the originality signature verification for a sample from the actual production batch?
10. What is the encoding process — individually encoded URLs, or a common URL with UID/counter mirroring?

 

A supplier who answers all ten precisely is a supplier who understands their own product. In practice, most cannot answer more than four, which is itself the most useful screening result you will get.

 

Part Thirteen: Encoding Pitfalls That Kill Deployments

 

Choosing the right chip is half the job. The other half is what you write to it. These are the failure modes that appear repeatedly in post-mortems.

 

Writing a raw vCard instead of a URL

 

A vCard with a name, title, company, two phone numbers, an email address and a website consumes roughly 250–400 bytes. That does not fit on an NTAG213 at all, and it fills most of an NTAG215. Worse, it is frozen: the day the person changes role, every card in circulation is wrong and the only remedy is reprinting.

 

A short URL consumes around 25 bytes. It fits on any chip, it resolves to a page you can edit indefinitely, and it produces analytics. The engineering constraint and the product decision point in the same direction, which is rare and worth taking advantage of.

 

Not locking the tag

 

An unlocked Type 2 tag can be rewritten by anyone with a phone and a free app, in about four seconds, without your knowledge. For a tag on a public poster this is not hypothetical — it is a documented attack pattern where a legitimate campaign tag is rewritten to point at a phishing page.

 

Locking is irreversible, which is why suppliers avoid it: a locked tag cannot be re-encoded if the customer changes their mind. Insist on it anyway for anything deployed in public, and make sure the URL is one you control and can redirect server-side.

 

Using a URL you do not control

 

If the encoded URL points at a third-party link shortener, your entire deployment depends on that service’s continued existence, uptime and pricing. Tags in the field cannot be updated. Use a domain you own, with a redirect layer you operate.

 

Ignoring the URI prefix optimisation

 

NDEF URI records use a single-byte prefix code to represent common schemes. 0x04 means https://, 0x03 means http://, 0x02 means https://www.. Using the prefix saves seven or eight bytes over writing the scheme as text — trivial on an NTAG216, meaningful on an NTAG213 where you are working within 144 bytes. Good encoding tools do this automatically; poor ones do not.

 

Multi-record messages that phones ignore

 

An NDEF message can contain several records. In practice, phones act on the first record only. A message containing a URI record followed by a text record and a MIME record will surface the URI and silently discard the rest unless an app reads the tag deliberately. Design for the first record to carry the entire user-facing intent.

 

Testing on one phone

 

NFC antenna placement varies enormously between handsets. On most iPhones the antenna sits at the very top edge of the device; on Android handsets it may be central, upper-third or near the camera array. A tag that reads instantly on the tester’s phone can be frustrating on a colleague’s.

 

Test on a minimum of one recent iPhone, one flagship Android, and one budget Android — the budget device is the one that finds marginal antenna designs, because its NFC front-end tends to deliver a weaker field.

 

Part Fourteen: Four Deployment Patterns, End to End

 

Abstract comparison only goes so far. Here is how the decisions actually compose.

 

Pattern 1: A contactless business card programme for a 200-person sales team

 

Chip: NTAG213, genuine NXP silicon.

Encoding: A common base URL per card with UID mirroring, or individually encoded short URLs. Locked after encoding.

Why not NTAG216: The payload is a 25-byte URL. The extra 744 bytes have no use.

Why not NTAG 424 DNA: The card’s job is to share a profile with anyone. There is nothing to authenticate — copying the URL is the intended behaviour, not an attack.

The real risks: Antenna bond fatigue from wallet flexing, and profile pages that cannot be updated centrally when someone changes role. Both are solved by specification, not by silicon — and by pairing the physical card with a profile you can edit at any time.

 

Pattern 2: Anti-counterfeit tagging for a spirits brand

 

Chip: NTAG 424 DNA TagTamper, on the closure seal.

Encoding: SUN-enabled URL with encrypted PICC data and CMAC, keys provisioned in a controlled facility.

Server side: Decrypt, verify CMAC, check the read counter is monotonically increasing per UID, check tamper status, log geography and time.

What it defeats: Cloned tags (no key, no valid CMAC), replayed URLs (counter does not advance), refilled bottles (tamper loop broken).

What it does not defeat: A counterfeit bottle with no tag at all — which is why the consumer-facing message must be “no tag means no verification,” communicated on the packaging.

 

Pattern 3: Campus access control for a university

 

Chip: MIFARE DESFire EV3 4K.

Configuration: AES-128 mutual authentication, separate applications for door access, library, printing and canteen purse, each with independent keys and delegated management.

Additional measure: Proximity check enabled on high-value doors to defeat relay attacks.

Why not Classic: Crypto-1 is broken and cloning is a consumer-grade exercise.

Why not NTAG: UID-based access is not access control; it is a list of numbers broadcast in the clear.

 

Pattern 4: Field configuration for a sealed industrial sensor

 

Chip: ST25DV with I²C bridge and energy harvesting.

Flow: A technician taps a phone against the sealed enclosure. The app writes configuration into the RF mailbox. The sensor’s MCU reads the mailbox over I²C, validates, applies and writes a status response back. The phone reads the response.

Why it matters: No connector, no seal breach, no ingress path, and diagnostics remain available even when the internal battery is flat, because the reader’s field powers the tag.

Why not a standard tag: A conventional tag is memory. It cannot talk to the product’s own electronics.

 

Part Fifteen: Where the Market Is Heading

 

Three trends are worth planning around rather than reacting to.

 

Cryptographic tags are becoming the default for anything with brand value. The price gap between a plain memory tag and a SUN-capable tag has narrowed to the point where, for any product above a modest retail price, the marginal cost of authentication is negligible against the cost of counterfeiting. Expect brand-protection tagging to move from luxury goods into mid-market categories.

 

Regulatory pressure is pulling NFC into compliance workflows. Digital product passports, material and repairability disclosures, and supply-chain traceability requirements all need a per-item, machine-readable, consumer-accessible identifier. A tap is a better user experience than a printed code, and the chip can carry authenticated data that a printed code cannot.

 

Dynamic tags are quietly reshaping embedded design. Once a designer realises that an NFC interface removes the need for a service connector, a display, a pairing button and a waterproof port, the calculus changes. Expect more sealed products with no visible interface at all.

 

None of this changes the fundamentals. The chip you choose still determines what is possible. It just raises the cost of choosing badly.

 

Frequently Asked Questions

 

Is NTAG better than MIFARE?

The question does not have an answer, because MIFARE is a brand covering several product lines. NTAG is better than MIFARE Classic for phone-facing applications. MIFARE DESFire is better than NTAG for access control. They are built for different jobs.

 

What is the difference between NTAG213 and NTAG215?

User memory: 144 bytes versus 504 bytes. Nothing else meaningful. Both are Type 2, both read identically on every phone, both cost within pennies of each other.

 

Can NFC tags be cloned?

The memory contents of a standard Type 2 tag can be copied trivially, and the UID can be emulated with writable-UID hardware. Chips with cryptographic authentication — NTAG 424 DNA, DESFire EV3 — cannot be cloned in any practical sense, because the secret key never leaves the silicon.

Do NFC chips expire?

There is no battery and no wear-out from reading. EEPROM data retention is typically specified at ten years, and write endurance at around 100,000 cycles. In practice, the physical failure — a fatigued antenna bond from repeated flexing — arrives long before the silicon degrades.

Which chip do contactless business cards use?

Almost universally NTAG213, sometimes NTAG215 or NTAG216 where a larger payload is required. Anything else in that category should prompt a question about why.

 

Does an NFC card need an app?

No. A correctly encoded NDEF URI record opens directly on both Android and iOS with no app installed. If a supplier says an app is needed to read their card, the tag is either not NDEF-formatted or not standards-compliant. Evrycard and every credible vendor encode to the open standard for exactly this reason.

Is 13.56 MHz the same as RFID?

NFC is a subset of HF RFID. All NFC is RFID; most RFID is not NFC. UHF RFID (860–960 MHz) is a different technology with metre-scale range and no phone support.

Conclusion: Specify the Silicon

The NFC chip market looks chaotic because the naming is chaotic. The underlying structure is not. Strip away the brand names and there are four genuine categories:

1. Cheap memory tags that hold a URL and are read by phones — NTAG21x, MIFARE Ultralight, ST25TA. The right answer for the overwhelming majority of consumer applications.
2. Cryptographic authentication tags that prove they are genuine on every read — NTAG 424 DNA, ST25TN. The right answer whenever authenticity has value.
3. Smart card credentials with an operating system and certified security — MIFARE DESFire EV3. The right answer whenever the tag opens something or spends something.
4. Dynamic and embedded tags that bridge into a product’s own electronics — ST25DV and equivalents. A different discipline entirely.

Everything else is a variation on those four themes, and every genuinely bad NFC deployment is a case of picking from the wrong category: an access-control system built on a memory tag, a product-authentication programme built on a copyable URL, a business card built on a chip nobody can name.

The discipline is simple and it costs nothing: decide what the tag must prove, then specify the silicon that proves it — by part number, in writing, before you order. Everything downstream — range, reliability, security, lifespan, and whether the project is still working in three years — follows from that one decision.