Is MIFARE Classic really NFC?
MIFARE Classic shares the radio layer with NFC but runs a proprietary protocol above it rather than an NFC Forum tag type. Android states plainly that support depends on the device. It is common in existing access systems and a poor choice for anything new.
Where it sits
MIFARE is a product family from NXP, not a standard. MIFARE Classic in particular uses the ISO/IEC 14443 Type A radio layer, so a phone can detect it, and then departs from the NFC Forum path by using a proprietary command and authentication scheme instead of a Forum tag type.
That is the whole answer to the question in the title. It is NFC at the radio layer, and it is not an NFC Forum tag above it.
How its memory is organised
Android documents the structure precisely in its MifareClassic reference, which is the most accessible authoritative description available.
| Variant | Total memory | Structure |
|---|---|---|
| Mini | 320 bytes | 5 sectors of 4 blocks |
| 1K | 1024 bytes | 16 sectors of 4 blocks |
| 2K | 2048 bytes | 32 sectors of 4 blocks |
| 4K | 4096 bytes | 32 sectors of 4 blocks, then 8 of 16 |
Blocks are always 16 bytes. Each sector requires authentication before any read or write, with two keys per sector and access bits deciding what each key permits. This per sector locking is exactly what made the family attractive for access control, where different areas belong to different applications.
Why support is not universal
Because the protocol is proprietary, reading it requires a controller that implements it. Android says so directly: a failure "indicates the tag is not MIFARE Classic compatible, or this Android device does not support MIFARE Classic".
That sentence is the one to remember. There is no software workaround for a device whose NFC controller does not implement the scheme, and the population of such devices is not small.
Security
The authentication scheme used by MIFARE Classic is proprietary and has been the subject of published academic analysis for many years. Treat it as offering obstruction rather than protection, and do not build a new system whose security depends on it. The cipher was reverse engineered by Nohl and Plötz in 2007, then broken in Dismantling MIFARE Classic, published by Garcia and colleagues in 2008.
The verdict for a new deployment
Do not choose it. For content meant to be read by the public, a Type 2 tag is cheaper and works on every phone. For access control, current MIFARE generations and other modern families exist precisely because Classic aged badly.
Where it remains unavoidable is an installed base. Buildings full of readers and thousands of issued cards do not get replaced because a standard moved on, and working with what exists is legitimate. Just be clear that you are maintaining a system rather than designing one.
Frequently asked questions
Will MIFARE Classic tags read on an iPhone?
Not in the way a Type 2 tag does. Core NFC is built around the NFC Forum tag types, so the proprietary layer that makes a Classic tag useful is not reachable in the same way. Assume no for a consumer deployment.
Is MIFARE Ultralight the same thing?
No, and the distinction matters. Ultralight is a different family that does follow a Forum tag type, which is why it reads everywhere. If a supplier offers you MIFARE for a public deployment, Ultralight is the one to accept.
Can I write NDEF to a MIFARE Classic tag?
There is a documented way to lay NDEF into its sector structure, and Android exposes an application directory key for that purpose. It works where the device supports the family at all, which brings you back to the same limitation.
Should I replace an existing MIFARE Classic installation?
Not reflexively. Replacing readers and reissuing cards is expensive, and the right moment is usually a renewal that was going to happen anyway. What should stop immediately is adding new security assumptions on top of it.