IC Card vs ID Card vs CPU Card: Which One for Your One-Card System
In a one-card project the first decision is usually not the hardware but the card. ID, IC and CPU cards differ in unit price by several times, and once the card is chosen every reader, POS terminal and controller has to follow it — choose wrong and everything downstream is rework.
The three cards, in one line each
· ID card: 125 kHz, a serial number burned in at the factory, read-only, no encryption · IC card (usually Mifare Classic / M1): 13.56 MHz, organised in sectors, read/write, password protected, 1K or 4K capacity · CPU card: carries a microprocessor running a card OS, supports mutual authentication and hardware encryption — a genuine smart card
ID cards: as cheap as it gets, and as weak as it gets
The card holds only a factory-burned serial number, and the reader is finished once it has read that string. Cheap, very thin, and available as key fobs or shaped tokens — but that number is public, and a cloner costing a few dollars copies it.
Fine for attendance only, temporary cards, visitor cards, or very tight budgets where the risk is acceptable. Not for a primary access control system, and certainly not for anything carrying money.
IC cards (M1): the industry default, with a public vulnerability
At 13.56 MHz, Mifare Classic 1K is divided into 16 sectors, each with its own Key A/B, and reads require the password check. One kilobyte is enough for identity, balance and trip counts, and the ecosystem is so mature that virtually every POS terminal and reader accepts it.
But this has to be said plainly: the Crypto-1 cipher M1 relies on was publicly broken back in 2008, and equipment costing a few hundred dollars now clones a whole card, encrypted sectors included. Treat M1 as an identity token, never as a secure container.
The correct pattern: the card number is only an index. Balances and permissions live in the backend database; the on-card purse is an offline fallback that synchronises the moment the terminal is back online. Even if a card is cloned, the loss stays inside the single-transaction limit.
CPU cards: security costs money
The card carries a microprocessor running a card operating system. Communication is mutual authentication between card and terminal, encrypted with DES/3DES or SM1, with a different session key each time. It cannot be cloned and replay attacks do not work.
The price is real: cards cost roughly three to five times an M1, the reader module must support them, and card issuance with key injection is a good deal more involved. It suits campus one-card systems, corporate sites, transit and government projects.
Selection checklist
· Tight budget, attendance only, or temporary cards: ID · Standard access control plus canteen, balance kept on the server: IC (M1), best value · Larger sums involved, cloning must be prevented, compliance required: CPU card · Upgrading an existing system: check what your current readers and terminals support — most read both M1 and CPU · Want it right first time: CPU cards with dual-frequency readers. A little more now, one full card swap avoided later
Details that get overlooked
· The frequency must match: 125 kHz and 13.56 MHz are incompatible, and IC cards simply will not read on an ID reader · 13.56 MHz covers phone NFC alongside Mifare and CPU cards — if users should tap their phone, the terminal needs an NFC module · Custom printing has a minimum order, commonly 500 cards, and lead time: do not let the hardware arrive on site before the cards are printed
Bottom line
None of the three replaces the others: ID wins on price, IC on ecosystem, CPU on security. For a one-card system I usually suggest IC or CPU for the core population and ID for visitors and temporary staff — cost and security each where they belong.