Access Cards
MIFARE Classic 1K Cards
Bulk 13.56 MHz Access
Quick answer
The legacy 13.56 MHz access-control chip is NXP's original ISO/IEC 14443-3 Type A contactless smart card (13.56 MHz, 1 KB EEPROM, 16 sectors × 4 blocks) and still the highest-volume HF credential in circulation worldwide. It is the right specification for legacy-reader-compatible, low-value, high-volume issuance — gym memberships, event badges, time-attendance and budget hotel keys. Where universal reader compatibility and the lowest per-card cost in the MIFARE family outrank the need for modern AES-128 cryptography.
- Universal MIFARE Classic reader compatibility — works with every 13.56 MHz ISO/IEC 14443-3 Type A reader deployed in the last two decades, with no firmware change or reader upgrade.
- 1 KB EEPROM, 16 sectors × 4 blocks — each sector independently key-protected, supporting basic multi-application use (access + canteen + parking) without migrating to DESFire.
- The lowest per-card cost in the MIFARE family at volume; ideal for high-volume issuance where the credential is disposable, replaceable or covers a low-value authorisation.
Used in these industries
Deployments where this product is referenced on our industry landing pages.
At a glance
Use these short answers to decide whether this page matches the project before moving into the detail.
Air-interface + CR80 envelope
ISO/IEC 14443-1/-2/-3 Type A at 13.56 MHz — 106 kbit/s bit-rate with anticollision per Type A cascade level 1. ISO/IEC 7810 ID-1 CR80 (85.60 × 53.98 × 0.76 mm) physical...
Memory architecture (1 KB / 16 sectors)
1 KB EEPROM organised as 16 sectors × 4 blocks × 16 bytes; block 0 of sector 0 is the read-only manufacturer block (UID + manufacturer data). Trailer block of each secto...
Next step
Ready to move forward? Start your inquiry to get specific answers for this project.
Request Classic 1K samples & quote- CRYPTO-1 cipher (historical posture)
-
- Proprietary 48-bit stream cipher designed by Philips in the mid-1990s; public reverse-engineering published at 24C3 (Nohl & Plötz, 2007).
- Full cryptanalysis by Garcia et al. (ESORICS 2008) — dark-side + nested attacks recover sector keys in seconds on modest hardware.
- CRYPTO-1 should not be trusted as a security boundary for any new deployment — specify Plus SE or DESFire EV3 where cloning is a realistic threat.
- Key A / Key B per-sector access conditions
-
- Each sector carries two independent 48-bit keys; access-condition bits determine which key authorises each block operation.
- Sector model supports basic multi-application use (access + canteen + parking) under separate key ownership without migrating to DESFire.
- Sector-key slots map 1:1 onto MIFARE Plus SE SL1 keys — the mechanical basis for the phased Plus SE upgrade path.
- MIFARE Application Directory (MAD)
-
- MAD v1 (sector 0) and MAD v2 (sector 16) provide a canonical directory of sector → application mapping for multi-application issuance.
- Application identifiers register with the MIFARE Application Directory registry — enables cross-issuer sector-allocation consistency.
- Access control + time-attendance + loyalty applications have canonical MAD AIDs documented in the NXP Classic 1K functional specification.
- Universal reader compatibility
-
- Every MIFARE-capable reader deployed in the last two decades reads Classic 1K natively — HID, SALTO, ASSA ABLOY, dormakaba, Suprema, ZKTeco, Rosslare.
- Every major card-printer platform (Zebra ZXP Series 7/8, Evolis Primacy, Matica XID, Fargo HDP5000) supports inline Classic encoding.
- iOS Core NFC exposes Classic UID only; Android MifareClassic API exposes sector data under known keys.
- Low-value / high-volume issuance economics
-
- Lowest per-card BOM cost in the MIFARE family at 10 k+ volume — the reason Classic is still specified where credentials are disposable.
- CR80 4-colour offset print + overlay lamination + inline Classic encoding pipeline runs at 1,200–1,800 cards/hour on standard bureau equipment.
- Volume discount tiers apply at 1 k / 5 k / 10 k / 50 k — the economic floor against which Plus SE and DESFire are compared on TCO.
- Gym, fitness + events deployment
-
- Gym membership + locker token issuance where the credential is re-issued on cancel and the threat of cloning is low-cost-per-event.
- Multi-day event and conference badges with session-access sectors — disposable after the event, replacement cost covered in the entry fee.
- Loyalty + gift card issuance where a low-value balance or sequential member ID lives on the card.
- Budget hospitality deployment
-
- Classic-compatible hotel key cards for properties running legacy MIFARE Classic generations of Saflok, VingCard, SALTO, Onity locks.
- Combi cards co-laminate Classic inlay with ISO/IEC 7811-2 HiCo 2750 Oe / LoCo 300 Oe magstripe for properties with mixed door fleets.
- Natural migration pivot to Plus SE or DESFire when the property refreshes locks — the card body stays the same, the chip specification changes.
- Time-attendance + loyalty
-
- Factory, warehouse and construction time-clock terminals reading Classic UID for payroll integration — often UID-only with server-side validation.
- Library membership + school / college campus estates that already invested in Classic-only readers — Plus SE + DESFire are the phased upgrades.
- Server-side credential-check pattern (UID + back-end validation) is safer than trusting data stored in Classic sectors under CRYPTO-1.
- Migration path (Plus SE / DESFire)
-
- MIFARE Plus SE drops in on Classic readers at Security Level 1, upgrades to AES-128 at Security Level 3 after reader firmware update.
- MIFARE DESFire EV3 provides AES-128 file-system architecture + EAL5+ certification for new deployments with no Classic reader debt.
- NTAG 424 DNA TT is the path where the credential also needs smartphone-readable tamper-evident brand authentication.
- Regulatory + card-body posture
-
- RoHS 3 + REACH Annex XVII compliant PVC substrates; ISO/IEC 27001 controlled pre-encoding bureau process.
- Batch chip certificates + ISO/IEC 14443 conformance test reports + UID lists ship with every production lot.
- Classic 1K is NOT suitable where PCI DSS, SOX, HIPAA, SOC 2 or government procurement references AES-128 / EAL4+ as the credential baseline.
What is MIFARE Classic 1K, and where does it still fit?
MIFARE Classic 1K is a 13.56 MHz ISO/IEC 14443-3 Type A smart card launched by Philips Semiconductors (now NXP) in 1997 and still the most widely issued contactless credential on earth. It remains the right specification when the threat model is low-value and the existing reader base is Classic-capable — not as a new-deployment security baseline.
The chip's 1 KB EEPROM is organised into 16 sectors of 4 blocks each. Each sector has two independent keys (A and B) and configurable access conditions, so a single card can carry access authorisation in sector 1, a canteen balance in sector 2 and a parking counter in sector 3 under separate key ownership. That sector model is the reason Classic is still specified — legacy reader systems, time-attendance terminals and hotel locks all understand it natively.
The elephant in the room is CRYPTO-1: the proprietary stream cipher Classic authenticates with has been publicly broken since 2008, and a Classic card can be cloned in seconds with a Proxmark, ChameleonMini or Flipper Zero. For any new deployment where the credential protects a high-value asset (data-centre access, banking, government ID, enterprise that audits under PCI/SOX), Classic should not be the answer. The migration path is MIFARE Plus SE (AES-128, backward-compatible on Classic readers) or MIFARE DESFire EV3 (AES-128 file system on modern readers).
Classic 1K vs Plus SE vs DESFire EV3 — when to pick which
The three MIFARE families sit at distinct security / cost / migration points. Use this matrix to position Classic 1K against its modern replacements before the specification is locked.
| Question | MIFARE Classic 1K | MIFARE Plus SE | MIFARE DESFire EV3 |
|---|---|---|---|
| Per-card cost at 10k+ | Lowest in the MIFARE family | Modestly above Classic | Above Plus SE |
| Cryptography | CRYPTO-1 (broken since 2008) | CRYPTO-1 (SL1) → AES-128 (SL3) | AES-128, 3DES, SDM (native) |
| Reader upgrade needed? | No — works on any MIFARE reader | No for SL1; firmware update for SL3 | Yes — DESFire-capable reader firmware |
| Multi-application architecture | 16 sectors, shared key space | 16 sectors, AES-128 in SL3 | Up to 28 firewalled applications |
| Typical fit | Low-value, high-volume legacy issuance | Phased AES migration on Classic readers | New transit, campus, enterprise, government |
Volume vs threat — the economic decision pivot
The single procurement question for Classic 1K is whether high-volume unit economics outweighs a public cloning attack. The figures below are the pivot point.
The CRYPTO-1 break and what it means for your deployment
Classic's security status is not speculation — it is 18 years of published attacks. The timeline below is the context procurement and audit teams will expect to see acknowledged.
- 1997 · MIFARE Classic launches
Philips Semiconductors (now NXP) introduces the Classic 1K chip with the proprietary CRYPTO-1 stream cipher; it becomes the dominant 13.56 MHz credential of the 2000s.
- 2008 · CRYPTO-1 reversed
Researchers at Radboud University and Ruhr-Universität Bochum publish full cryptanalysis of CRYPTO-1; the dark-side and nested attacks recover sector keys in seconds.
- 2011 · Commodity tooling arrives
Proxmark and MFCUK / MFOC attack tools become publicly available, moving the attack from academic to script-kiddie territory.
- 2018 · NXP publishes migration guidance
NXP formally recommends MIFARE Plus or DESFire for new high-security deployments and positions Classic for low-value issuance only.
- 2024–2026 · Flipper Zero era + integrator handoff
Consumer-grade devices (Flipper Zero, ChameleonMini) clone a Classic card in under a minute. Classic should not be specified where physical cloning is a threat. How experienced teams run gym-membership-issuance, event-badge-programme, budget-hospitality-keycard, time-attendance-terminal and loyalty-card-fleet MIFARE-Classic-1K programmes.
Do / don't — common Classic 1K specification mistakes
Classic is still a valid choice for the right use case. The mistakes below are what get flagged on the first procurement audit.
Don't
- Specify MIFARE Classic 1K for a new data-centre or government-facility access credential.
- Leave default transport keys (FFFFFFFFFFFF) unchanged — any third party with a USB reader can read and overwrite the card.
- Store any secret (PIN, balance, serial) in clear in a Classic sector and rely on CRYPTO-1 to protect it.
- Rip-and-replace the entire reader estate to upgrade Classic — the reader-firmware cost dwarfs the card cost.
Do
- Use Classic 1K for gym membership, low-value event access and low-risk time-attendance, where the credential is disposable and the threat is low.
- Program unique sector keys per issuance lot and lock access conditions before the cards leave the factory.
- Pair Classic with a server-side credential check (UID plus back-end validation) rather than trusting data stored on the card.
- Migrate to MIFARE Plus SE on the existing Classic reader base (Security Level 1 today, Security Level 3 AES-128 as reader firmware is updated).
Six deployments where Classic 1K still wins on total cost
Where the combination of universal reader compatibility, sector-based multi-use and lowest per-card cost beats AES-128 on total cost of ownership.
Gym & fitness
Member cards and locker tokens where the credential is re-issued on cancel and the threat of cloning is low.
Event & conference
Multi-day badges with session access sectors — disposable after the event, with replacement cost covered in the entry fee.
Budget hospitality
Classic-compatible hotel key cards for properties still running MIFARE Classic Saflok, VingCard or Onity locks in legacy generations.
Time-attendance
Factory, warehouse and construction time clocks reading the Classic UID for payroll integration.
Loyalty & gift
Printed loyalty cards encoded with a low-value balance or sequential member ID.
Campus legacy
School and college estates already invested in Classic-only readers; Plus SE and DESFire are the phased migration.
Reader, lock and printer compatibility
Because Classic 1K is the oldest HF smart card in wide circulation, almost every MIFARE-capable reader and card printer in the world accepts it. Here is the compatibility surface that matters on a specification.
- Access control readers: HID iCLASS SE, HID Signo, ASSA ABLOY Aperio, SALTO, dormakaba, Suprema, ZKTeco, Rosslare — all read Classic 1K natively.
- Hotel lock systems: compatible with MIFARE Classic generations of Saflok, VingCard, SALTO and Onity — see per-brand compatibility pages for exact lock-generation notes.
- Card printers: Zebra ZXP Series 7/8, Evolis Primacy, Matica XID, Fargo HDP5000 — all include Classic encoding options for in-line personalisation.
- Mobile SDKs: iOS Core NFC reads Classic UID only; Android NFC reads Classic UID and, with the MifareClassic API, sector data under known keys.
- Library, transit and payment systems still using Classic — see the complete MIFARE guide for platform-level context.
When Classic no longer fits — the migration path
Classic becomes the wrong answer the moment (a) the credential protects something worth cloning, or (b) a procurement audit references AES-128 / EAL5+. The supported migration paths from Proud Tek's catalogue are:
- MIFARE Plus SE — drop-in on existing Classic readers in Security Level 1, AES-128 in Security Level 3 once reader firmware is updated. Zero card-side disruption.
- MIFARE DESFire EV3 — full AES-128 file system, 28 firewalled applications, EAL5+ certification. Requires DESFire-capable readers.
- NTAG 424 DNA TT — when the credential also needs a smartphone-readable, tamper-evident brand-authentication layer (luxury goods, warranty).
- Review Plus EV2 vs DESFire EV3 and Classic vs Plus vs DESFire for hotel locks before locking the migration roadmap.
Useful next pages
Use these linked product, guide and comparison pages to keep the next click specific and practical.
Related card SKUs
Other MIFARE family options from Proud Tek for the same CR80 card body.
Hotel lock compatibility
Per-brand guidance on MIFARE Classic compatibility for major hotel lock platforms.
Background reading
Context on MIFARE family selection and the Classic 1K security posture.
FAQ
Is MIFARE Classic 1K still secure enough for building access?
For a high-value building — data centre, finance, government, any site with a PCI / SOX / HIPAA audit — no. The CRYPTO-1 cipher has been fully broken since 2008 and a Classic card can be cloned in under a minute with a consumer-grade Proxmark or Flipper Zero. For a low-value environment where the cost of cloning a card is lower than the cost of the credential itself — gym, hotel, low-risk office — Classic 1K is still a defensible specification. The decision rule: threat model, not brand preference. If cloning is a realistic threat, migrate to MIFARE Plus SE (AES on your current readers) or DESFire EV3 (AES on new readers).
Can MIFARE Classic 1K cards be cloned?
Yes, trivially. The CRYPTO-1 stream cipher was cryptographically broken in 2008 by researchers at Radboud University and Ruhr-Universität Bochum, and the attacks (dark-side, nested authentication, MFCUK/MFOC) are now packaged into consumer devices. A modern Flipper Zero or ChameleonMini will recover the sector keys and write a clone card to a writable Classic chip in seconds. If cloning is a risk, specify MIFARE Plus SE or MIFARE DESFire EV3 — both use AES-128 with diversified keys and have no public attack path.
Can you print employee photos on MIFARE Classic 1K cards?
Yes. Proud Tek supports two approaches. Digital printing (Evolis / Matica / Fargo / Zebra) for variable data — employee photo, name, ID number, barcode — where each card is unique. Offset printing for the common design elements (logo, background, text) combined with digital overprinting for the variable data, which is more cost-effective above 2,000 cards. Both methods include overlay lamination to protect the printed surface, and Classic sector keys and data can be written inline with the print pass.
What is the difference between MIFARE Classic 1K and 4K?
MIFARE Classic 1K has 1 KB EEPROM organised as 16 sectors × 4 blocks × 16 bytes. MIFARE Classic 4K has 4 KB organised as 32 sectors of 4 blocks plus 8 sectors of 16 blocks — more storage for applications carrying photo, biometric template or larger stored-value records. Both share CRYPTO-1 and the same reader compatibility surface; 1K is the volume leader for basic access and 4K is specified when the card needs to carry more than a few hundred bytes per application.
Can we mix Classic 1K and Plus SE cards on the same reader estate?
Yes. MIFARE Plus SE in Security Level 1 is wire-compatible with Classic 1K on any MIFARE reader, so a phased issuance works naturally. Issue Plus SE cards instead of Classic 1K going forward; existing Classic cards continue to function; once the reader firmware is updated to support Plus SE Security Level 3 (AES-128), new issuances run at AES. This is the lowest-disruption AES-128 migration path for organisations with large Classic reader estates — see the MIFARE Plus SE page for the full phased-upgrade timeline.
What is the MOQ and lead time for MIFARE Classic 1K cards?
Blank white cards ship from stock at a 100-piece minimum in 2–3 business days. Custom 4-colour printed cards with overlay lamination require a 200-piece minimum and 10–15 business days from artwork approval. Pre-encoded cards with sector keys, MAD (MIFARE Application Directory) and access-control data loaded in-factory add 2–3 business days. Repeat orders reuse stored artwork and encoding templates for faster turnaround; volume discounts apply at 1,000, 5,000 and 10,000-piece tiers.
Do Classic 1K cards support NFC tap-to-URL on a smartphone?
Not natively — the Classic 1K memory layout is not NDEF-compatible and iPhones expose only the UID for Classic over Core NFC. Android can read Classic sector data through the MifareClassic API when the sector keys are known, but that is not a URL-opening consumer experience. For smartphone tap-to-URL you need an NFC Forum Type 2, 4 or 5 tag — NTAG213 / 215 / 216 (Type 2) for simple URLs, or NTAG 424 DNA / MIFARE DESFire EV3 (Type 4) for secure, dynamic URLs.
Sources & references
Primary standards, OEM datasheets and regulatory documents cited by this article. All URLs were verified on the access date shown below.
- NXP MIFARE Classic 1K (MF1ICS50 / MF1S503x) product page
Official product brief covering Classic 1K memory, air interface and recommended migration guidance.
- NXP MF1ICS50 functional specification (MIFARE Application Directory)
MAD v1 / v2 application-directory structure used in multi-application Classic issuance.
- ISO/IEC 14443-3:2018 — Proximity cards, Type A initialisation and anticollision
Type A air-interface standard that MIFARE Classic 1K implements.
- Nohl & Plötz — 'MIFARE: little security, despite obscurity' (24C3, 2007)
First public reverse-engineering of the CRYPTO-1 cipher used in MIFARE Classic.
- Garcia et al. — 'Dismantling MIFARE Classic' (ESORICS 2008)
Full cryptanalysis establishing key recovery in seconds — the reference citation for Classic's broken security posture.
- de Koning Gans et al. — 'A Practical Attack on the MIFARE Classic' (CARDIS 2008)
Practical dark-side attack demonstrating key recovery from a single sector without prior knowledge.
- ISO/IEC 7810:2019 — Identification cards, physical characteristics (ID-1 / CR80)
CR80 physical card dimensions (85.60 × 53.98 × 0.76 mm).
- ISO/IEC 7811-2:2018 — Magnetic stripe on identification cards (HiCo / LoCo)
Magstripe standard referenced for Classic + magstripe combi cards in budget hospitality.
- ISO/IEC 10373-6:2020 — ID card test methods, proximity cards
Durability and electrical test methods applied to Classic 1K card bodies at the issuance bureau.
Proud Tek is a Shenzhen-based RFID & NFC manufacturer supplying hotel chains, transit operators, event venues and retail brands worldwide. Every order includes free samples, RF testing and dedicated project support.
Get a Quick Quote
Tell us about your project and we'll respond within one business day. Fields marked (asterisk) are required.