MIFARE Classic vs Plus vs DESFire for Hotel Locks

Quick comparison

The three chips at a glance (hotel context)

• MIFARE Classic 1K/4K — NXP MF1S50 (1K) / MF1S70 (4K). The dominant hotel-key-card chip 1997-2015. ~€0.15-0.25 per card at volume. 1,024 or 4,096 bytes organized as sectors with per-sector Key A / Key B. CRYPTO1 cipher, publicly broken since 2008 (nested / darkside / hardnested attacks; commodity tooling takes minutes). Still appropriate for properties where cloning risk is negligible and the reader fleet predates Plus/DESFire support.
• MIFARE Plus EV2 — NXP MF1P family. Launched as successor to Plus EV1 in 2018. 2K or 4K memory, Classic-compatible sector layout, AES-128 session keys. The distinguishing feature: three security levels (SL1 = CRYPTO1 compatible, SL2 = CRYPTO1 auth + AES data, SL3 = full AES-128). Drop-in replacement for Classic cards on legacy readers (SL1); future-proof against the CRYPTO1 break (SL3). ~€0.30-0.40 per card at volume.
• DESFire EV3 — NXP MF3DHx3 family. Launched 2020 as successor to DESFire EV2. 2K / 4K / 8K variants. File-system memory model. Up to 28 applications per card, up to 32 files per application, per-file AES keys. EAL5+ hardware. ~€0.60-0.90 per card at volume. The architecturally-correct choice for multi-application credentials (room + spa + F&B + loyalty on one card).
• All three chips are ISO 14443-A compliant at the physical and anti-collision layers. Classic stops at Part 3 (sector authentication frames on raw 14443-A). Plus EV2 supports both Part 3 (SL1/SL2 modes) and Part 4 (SL3 mode T=CL). DESFire EV3 uses Part 4 exclusively with APDU-wrapped commands.
• For the full chip-level technical reference on each, see the dedicated guides: `/guides/mifare-classic-1k-4k-chip-encyclopedia/`, `/guides/mifare-desfire-ev3-commands-reference/`, and the `/compare/mifare-plus-ev2-vs-desfire-ev3/` deep dive.

Lock vendor compatibility matrix

Hotel chip selection is heavily gated by the installed lock firmware. This table reflects the common configurations seen in 2026 globally.

What drives the decision in practice

• Scenario A: Budget-tier or regional chain, 2010-era Saflok/Onity lock fleet, no CAPEX for lock replacement. Choose Classic 1K. The operational risk (opportunistic cloning) is accepted; the operational cost of lock replacement is not. Common in economy-tier properties and hospitality-adjacent verticals (hostels, small B&Bs). Re-encode cards frequently (every guest cycle) to limit the blast radius of any cloned key.
• Scenario B: Mid-market chain with mixed Saflok MT + Confidant installed base, card-fleet refresh on the annual procurement cycle. Choose Plus EV2 in SL1 mode. Cards are reissued fleet-wide as Plus EV2; legacy-reader properties continue operating unchanged; Confidant-equipped properties can begin moving toward SL3 as firmware is updated. Matches the typical 3-5 year reader-fleet migration cadence.
• Scenario C: Luxury chain, all-new property build or full lock replacement program. Choose DESFire EV3 2K. Per-card cost is negligible at luxury average-daily-rate economics. Multi-application capability supports room + fitness + spa + F&B + parking on a single card, which is a brand-experience differentiator.
• Scenario D: Enterprise business hotel, frequent-traveler program with HID Mobile Access or equivalent mobile-credential. Choose DESFire EV3 for the physical-card fallback tier. Mobile-credential is the primary path; physical cards issued at front desk use DESFire because the existing reader fleet already speaks DESFire for the mobile integration.
• Scenario E: Hotel with significant compliance exposure (hosting government or healthcare guests, certified against ISO 27001 or equivalent). Choose DESFire EV3. EAL5+ is often the documented security baseline in supplier audits; Plus EV2's EAL4+ can fail audit review even though the practical cryptographic strength is equivalent.
• Scenario F: Timeshare or serviced-apartment chain with multi-year resident credentials and per-unit access requirements. Choose DESFire EV3. Long credential lifetime and complex access rules (owner access + housekeeping access + guest access + maintenance access on one card) are exactly what DESFire's file-system model is designed for.

Migration math across a 500-property chain

• Assume 500 properties, average 200 cards in issue per property (guest-use + staff + master), 5-year card lifecycle. Annual card volume = 500 × 200 / 5 + 20% re-issuance = ~24,000 cards/year.
• Classic at €0.20/card = €4,800 annual spend. Plus EV2 at €0.35/card = €8,400 annual spend (+€3,600 delta). DESFire EV3 at €0.80/card = €19,200 annual spend (+€14,400 delta over Classic).
• On a €500M+ annual revenue chain the card-fleet cost is a rounding error. On a €50M regional chain the delta is visible budget. The differentiator is lock-fleet capex: a single lock replacement is €400-800, so upgrading 500 × 200 locks = €40-80M CAPEX. This dominates every card-chip decision.
• The right strategy for mid-market chains is typically: standardize on Plus EV2 for the card fleet, mandate DESFire EV3 compatibility as a lock-vendor requirement for all new property builds and major refurbishments. This converges the fleet on DESFire over 7-10 years without a forced migration.
• Luxury chains typically standardize on DESFire EV3 and specify Saflok Quantum or Kaba 790 (both DESFire-native) for all new builds.
• Budget chains typically stay with Classic until a property's lock fleet reaches end-of-life, then jump to Plus EV2 as part of the lock refurbishment.

Operational considerations beyond the chip

• Issuance encoder compatibility: Plus EV2 and DESFire EV3 require encoders that speak the newer command sets. Legacy Saflok and Onity front-desk encoders (2015-era hardware) often need firmware updates to emit Plus SL3 or DESFire cards. Include encoder-upgrade cost in the chip-migration business case.
• Card durability: hotel-use card stock is typically 0.76 mm PVC rated for ~50-100 re-encodes per card before PVC delamination. The chip itself has ≥100,000 write cycles; card durability, not chip durability, is the operational constraint. Better PVC (+5-15 cents per card) buys more guest cycles.
• Room-service and IoT integration. DESFire EV3's multi-application model enables the card to double as the guest's in-room-IoT credential (curtain controls, climate scheduling, minibar). Plus and Classic don't support this natively; separate credentials are needed.
• Guest recovery workflows: if a guest loses a card, the front-desk reissuance workflow is identical across all three chips (card → encoder → new card). The relevant operational differences are in the audit-log richness: DESFire EV3 supports application-level audit trails; Plus and Classic provide coarser UID-level logging.
• Master-key hierarchy: DESFire EV3's application/file key model mirrors the way hotels organize key privileges (floor master, housekeeping master, management master). Plus EV2 handles this via sector-key conventions; Classic handles it via operational segregation. DESFire's native fit reduces operational risk of key-hierarchy misconfiguration.
• Staff-card differentiation: housekeeping, maintenance, minibar-service cards have different access windows and privilege sets. All three chips support this, but DESFire EV3 encodes it cleanly in per-file access rights rather than in sector-key conventions.
• For the broader hotel-card program context (artwork, material selection, encoding workflows), see `/solutions/hotel-key-cards/`, `/guides/hotel-key-card-encoding/`, and `/guides/hotel-key-card-material-selection/`.

Sampling and pilot guidance

• Pilot at 1-3 properties before fleet-wide commitment. Real-world behavior across lock firmware versions, encoder quirks, and front-desk workflow variations is always richer than the spec-sheet suggests.
• Pilot duration 30-60 days minimum. Shorter pilots miss the edge cases (wedding groups checking in 50 cards at once, the ADA-access guest who needs a card to work through a wheelchair-width range limit on a particular door).
• Pilot with the full card-issuance supply chain, not with engineering hand-samples. The bureau that actually personalizes the hotel's production fleet is a real supply-chain variable. Their encoder, their QA tolerances, their batch-level key handling.
• Verify the audit-log export path. Hotels run incident audits (lost card, unauthorized entry report, staff access review). Verify that Plus SL3 or DESFire EV3 audit logs export correctly to the property-management system (Opera, Infor HMS, Agilysys) before committing to the chip.
• For Plus EV2 specifically, pilot the SL1 → SL3 upgrade path at scale. Some Saflok and Onity reader firmwares have documented edge cases in the SL1 → SL3 transition that are invisible at prototype scale.
• For DESFire EV3 specifically, pilot the multi-application workflow even if only single-application is planned initially. DESFire EV3 cards encoded single-application at issuance time are hard to retrofit into multi-application later without a reissue; plan the application structure up front.

FAQ