Capability Container (CC)

Capability Container (CC)

The Capability Container is a mandatory 4-byte data structure stored at a fixed location in every NFC Forum compliant tag. It describes the tag's fundamental capabilities — NDEF version support, available memory size, and read/write access conditions. An NFC reader or NFC-enabled device reads the CC first to determine how to interact with the tag before accessing any user data.

CC Structure (Type 2 Tags)

For NFC Forum Type 2 tags (NTAG, MIFARE Ultralight), the CC occupies page 3 (bytes 12-15 in the linear memory map):

CC1 access nibble values: - 0x0: Read and write access granted without security - 0x0F: No write access (read-only tag) - Other values: Proprietary access conditions

CC in Type 4 Tags

Type 4 tags (MIFARE DESFire EV3, ST25TA) use a CC file rather than a fixed memory page. The CC file is an EF (Elementary File) with file ID 0xE103 that contains:

• CCLEN: Total CC file length (15 or 17 bytes)
• Mapping version: NDEF mapping version (2.0 for modern tags)
• MLe: Maximum bytes readable in a single ReadBinary command
• MLc: Maximum bytes writable in a single UpdateBinary command
• NDEF file control TLV: File ID, maximum file size, and read/write access conditions for the NDEF data file

Why the CC Matters

The CC is the first thing an NFC stack reads after tag activation. Without a valid CC:

1. The reader cannot determine if the tag contains NDEF data.
2. The reader does not know how much user memory is available.
3. Write operations may exceed memory boundaries, corrupting the tag.

A tag with a corrupted or missing CC (magic number not 0xE1) will be treated as unformatted by smartphone NFC stacks — the phone will detect the tag but will not parse any NDEF records from it.

Protection

The CC page should be protected with lock bits after initial NDEF formatting to prevent accidental overwrite. Most tag provisioning workflows lock the CC (static lock bit for page 3) as a final step. Since lock bits are OTP, this protection is permanent.