MIFARE Classic vs DESFire EV2/EV3: Security, Cost and Migration

For new access credentials, specify DESFire EV2/EV3 with AES-128 application authentication and protected file access. MIFARE Classic uses Crypto1, which has published practical attacks; NXP marks Classic EV1 as not recommended for new designs. A DESFire chip alone does not secure a system: the reader must authenticate the application, protect its keys and deliver credentials over a protected controller link.

Summary table: MIFARE Classic vs DESFire at a glance

Both families run at 13.56 MHz on ISO/IEC 14443 Type A, so the same reader antenna detects either card. The difference is what happens after the card answers.

Feature	MIFARE Classic 1K / 4K	DESFire EV1	DESFire EV2	DESFire EV3
ISO/IEC 14443A compliance	Parts 1–3 (proprietary authentication)	Parts 1–4	Parts 1–4	Parts 1–4
Cryptography	Crypto1, 48-bit keys	DES, 2K3DES, 3K3DES, AES-128	As EV1, plus EV2 secure messaging	As EV2
Memory	1 KB (752 bytes user data) / 4 KB (3,440 bytes)	2, 4 or 8 KB	2, 4, 8 or 16 KB in NXP’s comparison	2, 4, 8 or 16 KB
Structure	16 or 40 sectors, two keys per sector	Up to 28 applications, 32 files each	Applications limited by memory	Applications limited by memory
UID	4-byte NUID or 7-byte UID	7-byte UID or random ID	7-byte UID or random ID	7-byte UID or random ID
Procurement security check	Legacy Crypto1; not recommended for new designs	Verify exact chip certificate and configuration	Verify exact chip certificate and configuration	NXP lists EAL5+ hardware/software; verify exact chip
Protection to specify	Do not rely on Crypto1 for new secure credentials	AES authentication and protected file access	AES authentication and protected file access	AES authentication and protected file access
Relative cost (cards and readers)	Lowest	Higher	Higher	Higher

Cost is the one row where Classic wins, but weigh it against what a copied credential or a forced card reissue would cost later. Ask us for current card and reader pricing for your volumes.

Why MIFARE Classic Crypto1 is considered broken

Classic uses a proprietary 48-bit cipher. The 2008 research paper Dismantling MIFARE Classic demonstrates vulnerabilities in the cipher and authentication protocol, including recovery of keys through interaction with a reader. Attack requirements vary with chip generation and configuration; a claim that every card takes a fixed number of seconds to copy is not a useful specification.

For procurement, use the practical conclusion: do not select Classic for a new credential whose security depends on keeping card data secret. NXP’s Classic EV1 product page recommends other products for new designs. Classic may remain a low-cost identifier in an existing system where copying is an accepted risk, but such a decision should be recorded rather than described as secure authentication.

Changing a default sector key does not remove the underlying Crypto1 weaknesses. During migration, record which readers still accept Classic and when that acceptance will be disabled. A new DESFire reader that continues to accept the old Classic credential still permits the old path into the building.

DESFire EV1 vs EV2 vs EV3

DESFire replaces Crypto1 with published, standard algorithms and adds a file system. One card can hold several applications, each with its own keys and files, so access control and a cashless vending scheme can share a card without sharing keys.

Do not substitute an older chip generation without checking the application requirements. NXP’s generation comparison documents command support, key sets and additional protection features:

Feature	EV1	EV2	EV3
AES-128 mutual authentication	Yes	Yes	Yes
Secure messaging modes	EV1	EV1 and EV2	EV1 and EV2
Maximum applications	28	Limited by memory	Limited by memory
Multiple key sets per application (key rolling)	No	Yes	Yes
Delegated application management	No	Yes	Yes
Proximity check (relay-attack mitigation)	No	Yes	Yes
Transaction MAC	No	Yes	Yes
Transaction timer	No	No	Yes
Secure Unique NFC (SUN) messages	No	No	Yes
Backward compatible with	—	EV1	EV1 and EV2

How to choose:

• New projects: specify EV3. It supports the EV1 and EV2 command sets, so readers configured for an EV1 or EV2 application generally read it, but test before rollout.
• EV2 remains a sound choice where it is already deployed.
• Existing EV1 deployments: check their AES configuration, keys and reader firmware before deciding whether to retain them. EV1 lacks some EV2/EV3 features, including proximity check and multiple key sets.
• Any generation: use AES-128 rather than DES or 2K3DES keys, and change the factory-default card master key (a DES key of all zeros) before issuing cards.

Reader compatibility and key ownership

Chip support is only the starting point. A reader advertised as DESFire-compatible may read only the UID, support a vendor-defined application, or allow a customer-defined application with imported keys. Those are different capabilities. Ask for the exact AID, file communication mode, key-import method and controller output supported by the reader firmware.

Question	Evidence to request
Does the reader authenticate the card?	A sample application read with your AES key and access rights
Who owns the keys?	Provisioning and handover terms, including backup and rotation
Can another reader source use the credential?	An interoperability test with the same encoded card
What reaches the controller?	Credential format and an enforced Secure Channel where supported

Do not assume that every DESFire reader can accept arbitrary customer keys. Keep card issuance, reader configuration and key custody in the same integration plan. For an existing proprietary credential system, obtain its actual technical and commercial migration requirements before comparing alternatives.

Can RFID cards be cloned? Risk by technology

Many can. The deciding factor is whether the reader checks a secret key or simply accepts a number the card announces to anyone.

Credential and read mode	Clone difficulty	Why
125 kHz proximity (EM4100-type and similar)	Trivial	Fixed ID sent without authentication; copied to writable 125 kHz chips such as T5577
Any 13.56 MHz card read UID/CSN-only	Easy	UID is sent in clear before any authentication; UID-changeable cards and emulators replay it
MIFARE Classic sector read (Crypto1)	Easy	Keys recoverable with published attacks; data and UID copied to “magic” cards
DESFire EV2/EV3 application read, diversified AES-128 keys	Resists simple data copying	Reader verifies secret-key authentication; key theft and relay remain separate risks

If your site still runs 125 kHz credentials, our 125 kHz vs 13.56 MHz guide explains the upgrade path. Two related risks sit outside the card itself:

• Relay attacks. An attacker relays the live conversation between a genuine card and a reader rather than copying it. DESFire EV2/EV3 proximity check, and the EV3 transaction timer, mitigate this when the reader uses them.
• The cable. Wiegand between reader and controller is unencrypted, so a device spliced into the cable can capture and replay card numbers. OSDP with Secure Channel (AES-128) closes that gap; see Wiegand vs OSDP.

UID-only reading vs encrypted sector and application reads

Before you buy a “13.56 MHz reader,” ask which of three modes it runs. Many low-cost readers output only the UID, whatever card you present.

1. UID-only read. The reader outputs the card’s UID (4 or 7 bytes, often truncated to fit Wiegand 26 or 34). No keys are involved, so security is similar to 125 kHz. If you enable random ID on DESFire cards for privacy, the identifier can change between field activations, so UID-only enrollment is unsuitable.
2. Classic sector read. The reader authenticates to one sector with Key A or Key B and reads a credential number stored there. That beats UID-only reading, but Crypto1 is broken, so the protection is thin.
3. DESFire application read. The reader selects the application by its AID, runs AES-128 mutual authentication, reads an encrypted or MAC-protected file holding the credential number, and outputs that number to the controller over Wiegand or OSDP.

For mode 3, keys should be diversified per card: each card’s key is derived from a site master key and the card’s UID (key diversification; NXP application note AN10922 describes a widely used method). Keep this diversification master secret in protected provisioning infrastructure or a SAM (secure access module); cards receive derived keys. It is distinct from a card’s own PICC master key, which is stored on that card. Start with our encrypted anti-clone readers and confirm DESFire EV2/EV3 support and key storage per model. For kiosks, lockers or OEM terminals, check 13.56 MHz reader modules for DESFire command support.

Cost: cards, readers and key management

We don’t publish list prices in guides, but the cost drivers are consistent:

• Cards. DESFire costs more per card than Classic, and larger memory costs more. An access-control application with a few small files fits comfortably in 2 KB; buy 4 or 8 KB only for multi-application plans.
• Readers. Readers that store keys and speak DESFire commands cost more than UID readers, and readers with a SAM slot cost more again.
• Encoding. Either the supplier pre-encodes cards with your application and keys, or you run a desktop encoder and software in-house.
• Key management. Someone must generate, store, back up and eventually rotate keys.

Migration plan: dual cards, reader swaps and key management

1. Audit what you have. For each reader, record what it actually reads (UID, Classic sector or other) and what it outputs (Wiegand 26/34 or OSDP). Note the controller’s accepted formats and the size of the card population.
2. Define the new credential. Fix the AID, file layout, AES keys, diversification method and credential number format. Keep a number format your controller already accepts so the controller itself needs no changes.
3. Swap readers first. Install readers that accept both the legacy card and the new DESFire credential during the transition, with the same output format. Check that legacy and new credential numbers cannot collide.
4. Issue DESFire cards. Start with new users and replacements, then reissue in batches. Where some 125 kHz readers must stay for a while, dual-technology cards (a 125 kHz chip plus DESFire in one card) bridge the gap. MIFARE Plus is another route: in Security Level 1 it behaves like Classic, including Classic’s weaknesses, and can later be switched one-way to AES-based Security Level 3 once readers support it.
5. Cut over. Disable legacy acceptance on every reader and revoke the old cards.
6. Secure the cable. Move reader-to-controller links to OSDP Secure Channel where the controller supports it.

Key management deserves its own plan:

• Own your keys. You, not a vendor, should hold the master keys; write key handover into the purchase agreement.
• Diversify. Per-card keys mean one extracted card key doesn’t expose the site.
• Store keys in hardware. Load them into reader protected storage or a SAM via secure configuration cards or encrypted files, never in plain text.
• Separate and rotate. Use different keys for the card master and each application, and plan rotation; EV2/EV3 key sets make rolling keys practical.
• Back up securely. Keep an escrowed copy of the keys under dual control.

RFQ checklist for encrypted card orders

Use this list when you request cards, key fobs or wristbands for a DESFire project:

• Chip generation (DESFire EV3 or EV2) and required memory, with written confirmation of the chip used
• Form factor: ISO/IEC 7810 ID-1 card (85.60 × 53.98 × 0.76 mm), key fob, wristband or tag
• Dual technology needed, e.g., a 125 kHz chip plus DESFire
• UID mode: fixed 7-byte UID or random ID (random ID breaks UID-only readers)
• Application layout: AID, file numbers, file sizes, communication mode (fully encrypted) and access rights
• Keys: AES-128, diversification method, transport-key exchange and who receives the final keys
• Credential numbers: range and format (26-bit facility code/card number, 34-bit or other), with no overlap with existing cards
• Printing: artwork, printed or laser-engraved number, slot punch
• Encoding report: a CSV mapping UID to credential number for enrollment
• Reader configuration: same AID and keys, output format for your controller (Wiegand or OSDP)
• Samples: a test batch verified with your readers and controller before volume

Pre-encoding, custom numbering and printed artwork are available on request; see OEM customization.

Next steps

Send us your current card type, what your readers output today, and how many cards and readers you need. We’ll confirm compatibility, propose a DESFire application layout, and ship sample cards and readers for testing. Request a quote and we’ll reply within 24 hours.

MIFARE, MIFARE Classic, MIFARE Plus and MIFARE DESFire are trademarks of NXP B.V. Names identify the technologies discussed; no affiliation is implied.

Sources and review scope

Reviewed 1 October 2026. Chip capabilities do not establish the security of a configured access system.

• NXP: MIFARE Classic EV1 — product lifecycle guidance.
• Radboud University: MIFARE Classic research — original research and publication links.
• NXP: MIFARE DESFire EV3 — capabilities and certification scope.
• NXP AN12752: DESFire generation comparison — memory, commands and compatibility.
• NXP AN10922: Symmetric key diversification — diversification inputs and methods.