Chapter 2: NFC Standards — ISO 14443, ISO 15693, NFC Forum

HF RFID at 13.56 MHz is governed by a set of overlapping standards from the International Organization for Standardization (ISO) and the NFC Forum industry consortium. Understanding how these standards layer on top of each other — and how commercial chip families map to them — is essential for making sense of library documentation, reader command sets, and error messages.

2.1 The Standards Landscape

Three ISO standards define the physical and protocol layers at 13.56 MHz:

The NFC Forum — a consortium of companies including Sony, Philips (now NXP), and Nokia — built on top of these ISO standards to define interoperability specifications for NFC-enabled consumer devices.

2.2 ISO 14443 in Depth

ISO 14443 is a four-part standard for proximity integrated circuit cards (PICCs). “Proximity” means the operating distance is less than 10 cm.

Part 1 — Physical Characteristics

Defines the card physical dimensions (credit card size, ID-1 format), operating temperature, and mechanical durability requirements.

Part 2 — Radio Frequency Power and Signal Interface

Defines the carrier frequency (13.56 MHz ± 7 kHz), the power transfer method (inductive coupling), and the modulation schemes used for each type:

Type A is more common for access control and transit applications. Type B is used by some banking cards and passports (ISO/IEC 7816-based applications).

The base bit rate is 106 kbps for both types. Higher bit rates (212, 424, 848 kbps) can be negotiated in ISO 14443-4.

Part 3 — Initialization and Anticollision

This is where the protocol diverges most significantly between Type A and Type B.

Type A Anticollision

The reader starts by sending a REQA (REQuest type A) command — a single byte 0x26. Any Type A card in the field responds with its ATQA (Answer To reQuest type A), a 2-byte value that encodes the anticollision loop type and the expected UID size.

ATQA (2 bytes):

Bit: 15 14 13 12  11 10 9 8   7 6 5 4   3 2 1 0
      [proprietary ]  [UID size ] [   RFU  ] [bit frame anticoll]

• Bits 7–6 indicate UID size: 00 = 4 bytes, 01 = 7 bytes, 10 = 10 bytes
• Bit 0–4 indicate which anticollision bit frame loop to use

After receiving ATQA, the reader runs the bit frame anticollision loop (for single-size UIDs) or the cascade loop (for 7/10-byte UIDs) to isolate one card and retrieve its full UID.

Once a card is selected, the reader sends SELECT. The card responds with its SAK (Select AcKnowledge), a 1-byte value.

SAK interpretation (key bits):

Common SAK values:

Type B Anticollision

Type B uses a probabilistic slot-based anticollision process. The reader sends REQB with a time slot count; each card picks a random slot number and responds in that slot. The reader then sends an ATTRIB command to select a specific card.

UID Sizes

ISO 14443 supports three UID sizes:

• 4-byte UID (single size): simplest; used by older MIFARE Classic cards. Note: some chips use a random UID that changes every tap.
• 7-byte UID (double size): most NTAG and newer MIFARE chips. More likely globally unique.
• 10-byte UID (triple size): rare; used in some specialised applications.

The cascade anticollision protocol handles 7 and 10-byte UIDs by splitting the UID across multiple SELECT commands (Cascade Level 1, 2, 3), using the cascade tag byte 0x88 as a placeholder.

Part 4 — Transmission Protocol (T=CL)

ISO 14443-4 defines the half-duplex block transmission protocol (T=CL) used by “high-level” cards that support APDUs. It adds:

• PCB (Protocol Control Byte): block type, chaining, power-level indication
• Block types: I-block (information), R-block (receive-ready / not-acknowledged), S-block (deselect, WTX — waiting time extension)
• CID (Card IDentifier): allows up to 15 cards to be addressed independently after selection

Cards with SAK bit 5 set (0x20) support T=CL. MIFARE Classic does not — it uses its own proprietary protocol after SELECT instead of T=CL.

2.3 ISO 15693 — Vicinity Cards

ISO 15693 operates at the same 13.56 MHz carrier but targets a much longer read range — up to ~1 m with an optimised reader antenna. This makes it suitable for scenarios where you want to read tags without close approach.

Key differences from ISO 14443:

Common ISO 15693 chips: NXP ICODE SLI/SLI-S, Texas Instruments Tag-IT, Infineon SRF55.

NFC Forum Type 5 tags are ISO 15693 based. Some smartphone NFC controllers can read ISO 15693 tags (Android: NfcV technology class).

2.4 The NFC Forum Standards

The NFC Forum publishes specifications that sit on top of the ISO physical layer standards. The Forum’s goal is interoperability: an NFC tag written by any compliant device should be readable by any other.

NFC Forum Tag Types

The NFC Forum defines five tag types. Each maps to a specific chip family or ISO standard:

MIFARE Classic is notably absent from this table. MIFARE Classic predates the NFC Forum and is not compliant with any NFC Forum tag type. It uses a proprietary protocol (CRYPTO1) that the NFC Forum did not adopt. Many smartphones can read it (via low-level ISO 14443-3 access) but it is not an NFC Forum tag.

NFC Forum Operating Modes

An NFC-enabled device (e.g. a smartphone) can operate in three modes defined by the NFC Forum:

Reader/Writer Mode: The device acts as an ISO 14443 or ISO 15693 reader, polling for tags and reading/writing NDEF data. This is what happens when you tap your phone to a smart poster or a payment terminal.

Peer-to-Peer Mode (NFC-IP-1/2): Two NFC devices exchange data using the LLCP (Logical Link Control Protocol) and SNEP (Simple NDEF Exchange Protocol). This was used for Android Beam (now deprecated). Both parties actively generate a field in an alternating fashion.

Card Emulation Mode: The device presents itself as an NFC tag to an external reader. The secure element (SIM card, embedded SE, or Host Card Emulation / HCE in software) handles the reader’s commands. This is how contactless payment apps work on phones.

2.5 The Anti-Collision Process in Practice

When you bring a tag close to a reader, the following sequence occurs (for ISO 14443 Type A):

Reader                              Tag
  |--- REQA (0x26) --------------->  |
  |<-- ATQA (2 bytes) ------------|  |
  |--- SELECT CL1 (0x93 0x20) --->  |
  |<-- UID bytes + BCC ------------|  |
  (if 7-byte UID, cascade continues)
  |--- SELECT CL2 (0x95 0x20) --->  |
  |<-- UID bytes + BCC ------------|  |
  |--- SELECT (with full NVB) ---->  |
  |<-- SAK (1 byte) + CRC -------->  |
  (if SAK bit 5 set, proceed to RATS for T=CL)
  |--- RATS ---------------------->  |
  |<-- ATS (Answer to Select) ---->  |

After this sequence the tag is “selected” — in an exclusive dialogue with the reader. Other tags in the field that lost the anticollision step are in a HALT state and will not respond until a WUPA/WUPB command is issued.

2.6 Key Identifiers Summary

Understanding these three identifiers is fundamental:

UID (Unique IDentifier)

• 4, 7, or 10 bytes
• Globally unique (or random for cards with random UID feature)
• Read without authentication; publicly visible
• Used by the OS/library to identify and cache tag objects

ATQA (Answer To reQuest type A)

• 2 bytes, returned immediately in response to REQA
• Encodes UID size and anticollision frame type
• Useful for quick chip family identification before SELECT
• Example: 0x0004 → MIFARE Classic 1K; 0x0044 → MIFARE Ultralight

SAK (Select AcKnowledge)

• 1 byte, returned after SELECT
• Most important for routing: tells you whether the card speaks ISO 14443-4 (T=CL) or not
• Example: 0x08 → MIFARE Classic 1K; 0x00 → MIFARE Ultralight; 0x20 → DESFire / Java Card

2.7 Practical Identification Flow

When you pick up an unknown card with a reader, the standard identification sequence is:

1. Issue REQA → get ATQA → note UID size from bits 7–6
2. Run anticollision → collect full UID
3. Issue SELECT → get SAK
4. Cross-reference ATQA + SAK against known chip table
5. If SAK bit 5 set, issue RATS to get ATS (contains chip-specific historical bytes)
6. The ATS historical bytes often identify the specific chip model

Python libraries (nfcpy, pyscard) do steps 1–5 automatically and expose the results as tag object attributes. You typically just read tag.type, tag.identifier (UID), and tag.atq / tag.sak.

Summary

• ISO 14443 defines proximity NFC at < 10 cm; ISO 15693 defines vicinity RFID at up to 1 m.
• ISO 14443 has two types: Type A (used by MIFARE) and Type B (used by some banking and passport chips).
• The anticollision loop produces the three key identifiers: UID, ATQA, and SAK.
• SAK tells you whether a card supports ISO 14443-4 (T=CL) for APDU-based communication.
• The NFC Forum defines five tag types (Type 1–5) and three operating modes (Reader/Writer, Peer-to-Peer, Card Emulation).
• MIFARE Classic is not an NFC Forum tag type — it uses a proprietary protocol on top of ISO 14443-3.