MIFARE Plus EV2 vs DESFire EV3

Quick comparison

The two chips at a glance

• MIFARE Plus EV2 — NXP part family MF1P (SE entry / S standard / X extended). Launched as Plus EV1 in 2009; EV2 refresh 2018. 2K or 4K EEPROM organized as Classic-compatible sectors (16 × 4-block for 2K, 32+8 for 4K). AES-128 session keys derived per-sector. Common Criteria EAL4+ on the hardware. The canonical migration chip out of the MIFARE Classic installed base.
• DESFire EV3 — part family MF3DHx3 (2K = MF3DH32, 4K = MF3DH34, 8K = MF3DH38). Launched 2020 as DESFire EV2's successor. DESFire Light (EV3L) is the reduced-memory variant (~640 bytes) for use cases where card cost dominates. File-system memory model. Up to 28 applications (AIDs) per card, up to 32 files per application, file types include Standard Data, Backup Data, Value File, Linear Record, Cyclic Record.
• Both chips implement ISO/IEC 14443-A Parts 1-4 (T=CL transmission protocol, unlike Classic which stops at Part 3). This means both expose the full APDU command frame to the reader. Higher-layer application logic, crypto operations, and file management happen over T=CL rather than raw anti-collision frames.
• NFC phone compatibility: both are readable from stock iPhone (iOS 13+) and Android phones using the HCE and reader-mode APIs. Stock phone wallet apps don't exercise the crypto layers; custom apps using Core NFC (iOS) or android.nfc (Android) can perform the full AES authentication and file-read sequences.
• The two chips are not mutually exclusive. Several transit deployments use DESFire EV3 for the multi-application primary credential + Plus EV2 for concession or occasional-user cards. Same reader fleet, different security/cost tiers per user class.

Security posture in practice

• Plus EV2 security-level model (SL0 (virgin / pre-personalization), SL1 (CRYPTO1-compatible output, AES keys stored but not used for auth) readers see a Classic-compatible card), SL2 (CRYPTO1 authentication + AES encrypted data), SL3 (full AES-128 authentication + encrypted session). Cards can be upgraded from SL1 → SL3 in the field via a one-way key-rollover flow; downgrade is not supported.
• DESFire EV3 security model. No three-level ladder. Each file has a 4-entry access-rights field specifying which key (of 0-13 AES keys per application) is required for each operation. 'Free' access (no key required) is a valid setting for public files. The Application Master Key is required for application-level operations (create/delete file).
• Cryptographic strength parity: both chips implement AES-128 with 128-bit session keys derived via NIST SP 800-108 key derivation. Hardware RNG is Common Criteria certified on both. Neither chip has public cryptanalytic breaks as of 2026.
• Side-channel resistance: DESFire EV3 is EAL5+ on the hardware versus Plus EV2's EAL4+. This maps to additional on-die shielding, clock-randomization, and power-analysis countermeasures. For credit-card-adjacent and government applications the EAL5+ rating is sometimes a hard procurement requirement; for corporate access control EAL4+ is normally sufficient.
• Originality Signature: both chips ship with an NXP-signed originality signature that a reader can verify against the NXP Originality Signature public key. This detects re-marked or counterfeit silicon without requiring chip-side secret keys. Incoming-inspection scripts should sample the Originality Signature on 1-2% of each card shipment.
• For the deep command-level treatment of DESFire EV3 (CreateApplication, CreateStdDataFile, ChangeKey, AuthenticateAES, ReadData + CMAC), see the dedicated `/guides/mifare-desfire-ev3-commands-reference/`.

Performance and operational behavior

• Transaction time: Plus EV2 SL3 authentication + 16-byte read ≈ 55-70 ms on a typical ISO 14443 reader (MFRC522 class). DESFire EV3 AuthenticateAES + ReadData of the same 16 bytes ≈ 80-110 ms due to T=CL framing overhead. For turnstile throughput targeting <150 ms both are fine; for very-high-throughput portals (1000+ taps/minute) the Plus delta matters.
• Bulk write performance: DESFire EV3 supports APDU command chaining, allowing block writes of several hundred bytes per reader transaction. Plus EV2's block-write is 16 bytes at a time per sector. For initial card personalization DESFire EV3 is meaningfully faster per card; quantify it against your actual personalization flow before committing — the delta depends heavily on reader firmware, HSM round-trips and key-injection model.
• Power consumption: both cards operate within the ISO 14443 field strength envelope (1.5-7.5 A/m). Neither chip is power-limited in typical ID-1 card antennas. For small-antenna wristband or keyfob form factors DESFire EV3's larger die may require slightly more field strength; verify at prototyping time for antenna designs <30 mm.
• Temperature: Plus EV2 operates -25 °C to +85 °C per the standard NXP qual. DESFire EV3 matches this range. For extended-temperature applications (vehicle-mounted credentials, industrial environments beyond 85 °C), both are subject to the same limitation and no HF 13.56 MHz card is appropriate above 105 °C without specialized encapsulation.
• Operational lifetime: both EEPROMs are rated ≥10-year data retention and ≥100,000 write cycles per byte. For typical access-control use (daily read, occasional write on credential rotation) both outlast the 5-7 year typical card replacement cycle by wide margins.

Ecosystem and application fit

• Corporate access control: HID Signo, Assa Abloy iCLASS SE, Kaba evolo, SALTO XS4, dormakaba MATRIX all support Plus EV2 and DESFire EV3. For facilities migrating from Classic, Plus EV2 is the default because it preserves reader-fleet investment. For greenfield office builds, DESFire EV3 is increasingly the default because it allows badge + canteen + printer-quota on one AID-segmented card. See `/solutions/rfid-access-control/` for the full solution stack.
• Transit: the major transit deployments (Hong Kong Octopus, London Oyster, Netherlands OV-chipkaart, Singapore EZ-Link) are progressively moving from Plus to DESFire EV3 as the primary credential type. Plus EV2 remains in the secondary and concession-card tier because of the cost delta. Expect this split to persist through 2030.
• Hotel key cards: Plus EV2 dominates the recent-build hotel segment because the Classic → Plus migration path matches hotel operators' slow reader-fleet replacement cycles. DESFire EV3 is specified in ultra-luxury and enterprise-hospitality chains where per-card cost is a rounding error and multi-application (room + fitness + spa + F&B) is valuable. The `/industries/hospitality/` page carries the full Saflok / Onity / Visionline / Salto chip-per-lock matrix.
• Education and campus: student ID cards sit on the same Plus EV2 / DESFire EV3 decision. Single-purpose access-only cards are typically Plus EV2; cashless campus (meal plan + print credit + transit) drives DESFire EV3 as default because it carries stored value. See `/industries/education/` for the full K-12 vs higher-ed decision framework and FERPA/GDPR compliance notes.
• Brand protection and luxury: neither Plus EV2 nor DESFire EV3 is the right chip for tap-to-verify consumer authentication — NTAG 424 DNA with SUN authentication is the defensible choice because it ships a cryptographic artefact per tap from a no-app consumer flow. See `/industries/brand-protection/` and `/industries/luxury-brands/` for that decision, and `/products/rfid-cards/ntag424-dna-tt-card/` for the tamper-evident SKU.
• Payment-adjacent: neither chip is a payment chip per EMV. Both are appropriate for closed-loop stored-value (campus canteen, transit purse, gym class credits). For deployments with stored-value above ~€50 per card, DESFire EV3's file-level access control provides the segregation required by many corporate compliance frameworks.
• Loyalty and membership: for pure UID-based loyalty programs where the chip only needs to be identified and the backend does the validation, both chips are overspecified. NTAG424 DNA (NFC phone-tap workflows) or MIFARE Plus SE (entry-tier Plus) are more cost-effective. For legacy 125 kHz / UID-only workflows that remain good enough, see `/products/rfid-cards/em4100-rfid-card/`. See the `/guides/mifare-classic-1k-4k-chip-encyclopedia/` for cases where Classic remains acceptable — noting that CRYPTO-1 has been broken since 2008 and `/products/rfid-cards/mifare-classic-1k-card/` should not be used for stored-value or fresh security-sensitive deployments.
• Where neither is the right choice. UHF supply chain (use UCODE 9 / Monza R6), one-time event tickets (use Ultralight C), library book tags (use ICODE SLIX), general NFC tap-to-URL campaigns (use NTAG213/215/216).

Migration decision framework

• If you are migrating a Classic installed base with >2 years of useful life remaining on the reader fleet. Choose Plus EV2. The SL1 compatibility mode lets you refresh the card fleet now, upgrade readers over the next 12-24 months, and upgrade cards to SL3 once readers are ready. Three-phase migration is less disruptive than any single-step cutover.
• If you are building new and multi-application from day one. Choose DESFire EV3. The file-system model is the right design for multi-application credentials; retrofitting multi-application into Plus's sector-based model is possible but operationally awkward compared to DESFire's per-file AES keys.
• If total credential volume exceeds 500,000 units and application is single-purpose. Choose Plus EV2. The Plus-vs-DESFire per-card silicon delta compounds into real budget at this scale. For Fortune-500 corporate-ID refresh programs this is usually the dominant decision factor — run the delta against a live quote, not a list-price estimate.
• If regulatory or government audit requires EAL5+ — choose DESFire EV3. Plus EV2's EAL4+ rating is insufficient for some EU public-sector and US federal-contractor procurements.
• If the project needs NFC-phone-based HCE (Host Card Emulation) on the reader side. Either works, but DESFire EV3 is the better-documented choice. Most third-party HCE SDKs (HID Mobile, Allegion, SALTO JustIN) ship with DESFire reference code rather than Plus reference code.
• If the project needs MIFARE Plus SE (entry-tier Plus with reduced memory / capabilities) on some card classes. You can mix Plus SE, Plus EV2, and DESFire EV3 in one fleet as long as the reader firmware supports the superset. Most current reader firmware does.

Sampling checklist before broader ordering

• Read the card with your actual reader hardware on your actual antenna. Lab-bench reads on reference readers are a poor predictor of portal or turnstile performance with real antennas, real card stock, and real card-to-reader distances.
• Validate the full personalization flow end-to-end. Key injection, application creation, file structure, access-bit configuration. Many issuance pipelines fail not on the chip but on the key-management / HSM integration between the personalization bureau and the card.
• For Plus EV2, test the SL1 → SL3 upgrade path on real field cards, not just virgin stock. SL2 intermediate behavior has subtle timing differences across reader firmware versions; pilot at scale before committing the production fleet.
• For DESFire EV3, test application deletion and recreation. Some issuance workflows re-personalize cards in the field; DESFire's deletion semantics differ between EV2 and EV3 in edge cases involving locked applications.
• Sample cards from at least two converters. Inlay antenna tuning varies between converters and changes the reader-field-strength requirements. Running the pilot on two sources derisks supply-chain issues.
• Verify Originality Signature on a statistical sample (1-2%) of each batch. This catches counterfeit or re-marked silicon before it reaches the production issuance line.

FAQ