# MIFARE DESFire EV3 — Command Set Reference

URL: https://proudtek.com/guides/mifare-desfire-ev3-commands-reference/
Source URL: https://proudtek.com/guides/mifare-desfire-ev3-commands-reference/
Generated: 2026-03-16T01:42:30.697Z
Kind: article
Publisher: Proud Tek Co., Limited
Author: Proud Tek Editorial Team (RFID & NFC Technical Content Team)
Published: 2026-04-18
Last Modified: 2026-06-10T18:00:00Z
Last Reviewed: 2026-06-10T18:00:00Z
Credentials: ISO 9001:2015, ISO 14001:2015, RoHS Compliant, CE Marking, REACH Compliant
Image: https://proudtek.com/landing-images/mifare-desfire-ev3-card.jpg
Image Alt: MIFARE DESFire EV3 card with command protocol diagram

## Description
The NXP MF3D(H)x2 — MIFARE DESFire EV3 — is the current flagship AES-128 enterprise smart-card chip: the silicon behind corporate access control,...

## Summary
- The NXP MF3D(H)x2 — MIFARE DESFire EV3 — is the current flagship AES-128 enterprise smart-card chip: the silicon behind corporate access control,...

## Buyer Guidance
- Best for: MIFARE DESFire EV3 — Command Set Reference supports RFID and NFC evaluation, comparison, and sourcing decisions.
- Compare first: Compare MIFARE DESFire EV3 — Command Set Reference against reader compatibility, chip family, material, and deployment environment.
- What to confirm: Confirm target application, compatibility requirements, customization needs, quantity, and sample expectations before quoting MIFARE DESFire EV3 — Command Set Reference.

## FAQ
- Q: How many applications and files can a DESFire EV3 card hold?
  A: Up to 28 applications per PICC, each with up to 32 files and up to 14 AES application keys. Total memory is the limit: a 2 KB card cannot hold 28 × 32 files at meaningful size, so in practice deployments plan around the memory budget rather than the maximum counts. Typical multi-application campus cards use 3-5 applications with 2-4 files each, leaving significant headroom on a 4 KB or 8 KB chip.
- Q: What is the difference between AuthenticateEV2First and AuthenticateAES?
  A: AuthenticateAES (0xAA) is the legacy EV1/EV2 AES authentication. Three-pass mutual auth, session keys derived from RndA and RndB, no forward secrecy across multiple authentications. AuthenticateEV2First (0x71) is the EV2-introduced mode that adds forward-secure session keys and a transaction counter, making it harder for an attacker who compromises one session to retroactively decrypt earlier sessions. For new deployments, always use AuthenticateEV2First. AuthenticateAES is retained for backwards compatibility with EV1-era reader firmware.
- Q: Do I need proximity check for typical access control?
  A: For most corporate door access — no. Proximity check defeats NFC relay attacks where an attacker uses two phones (one near the victim's card, one near the reader) to extend the card's effective reach by tens of meters. Relay attacks are realistic against high-value transit and contactless-payment targets but rare against corporate access control. Enterprises with executive-protection requirements or high-secrecy deployments (classified, pharma high-value storage, etc.) do enable PC; mainstream corporate deployments leave it off and rely on physical security + video verification instead.
- Q: Can DESFire EV3 be used for transit ticketing alongside existing Calypso cards?
  A: Yes. DESFire EV3 is the native choice for new transit deployments in the EU and North America; ISO/IEC 14443-4 Type A makes it interoperable with existing fare-collection reader networks. Coexistence with Calypso (ISO 14443 Type B, different command set) requires the reader to probe both protocols, which is standard in multi-card transit networks. DESFire Light is the cost-optimized variant specifically for single-application transit ticketing.
- Q: How does Transaction MAC protect a cashless-payment flow?
  A: Transaction MAC chains a cryptographic MAC across a sequence of commands within an authenticated session. A typical cashless-payment flow is: (1) Authenticate, (2) ReadBalance, (3) Debit(amount), (4) CommitTransaction. Without TMAC, an attacker intercepting between step 3 and step 4 could splice a different Debit command. With TMAC, the MAC is computed over the ordered sequence of commands and values; any mid-transaction tampering makes the CommitTransaction MAC verification fail. The card rejects the commit and the transaction is rolled back.
- Q: Can I read DESFire EV3 from an Android phone without special hardware?
  A: Yes for unencrypted file reads and for public information (UID, application list via GetApplicationIDs). ISO 14443-4 Type A is native to Android's NFC stack. However, to perform authenticated operations (ReadData on protected files, Credit/Debit, ChangeKey) the phone needs the per-application AES key. Which is a secret shared with the card's issuing authority. Typical consumer-facing flows don't give phones this key; they instead make network API calls where the server holds the keys and verifies or returns authentication data.
- Q: Is MIFARE DESFire EV3 the right choice for EU Digital Product Passport (DPP)?
  A: Usually no. DPP regulation (ESPR 2023/2102) specifies a persistent, machine-readable data carrier that consumers can scan with a smartphone. DESFire EV3 requires per-application AES keys for authenticated access, which does not fit the 'any smartphone can read it' model DPP assumes. NTAG424 DNA is the NXP-recommended chip for DPP (smartphone-friendly, URL-based, cryptographic authenticity via SUN + CMAC). DESFire EV3 is the right choice for closed-loop enterprise access control, transit, and cashless payment. Applications with dedicated reader infrastructure and proprietary keys.

## Machine Routes
- JSON: https://proudtek.com/machine/guides/mifare-desfire-ev3-commands-reference.json
- Text: https://proudtek.com/machine/guides/mifare-desfire-ev3-commands-reference.txt