DESFire EV1 vs EV2 vs EV3 — an architectural evolution.

Three generations of the same platform spaced over twelve years. Each refines the same trust model, but the operational consequences for what you ship in 2026 are real. Here is what changed at the architecture level — and what an issuer should pick on greenfield, why, and how to keep an installed estate alive while migrating.

The lay of the land

MIFARE DESFire is a contactless smart card platform widely used in closed-loop transit and building access. It is not a single product but a family: DESFire EV1 (released around 2008), EV2 (announced March 2016), and EV3 (announced June 2020). All three sit on top of ISO/IEC 14443 Type A; all three speak ISO 7816-style APDUs at the wire; all three model the on-card data as applications containing files. What changed is the cryptography, the transaction integrity, and the certification level (Common Criteria EAL4+ for EV1, EAL5+ for EV2 and EV3).

If you take one thing away: EV2 is the architectural pivot. EV1 was the AES-capable platform; EV2 is where the security model became modern enough to be the default for new closed-loop deployments. EV3 is EV2 with refinements such as the Transaction Timer and SUN messaging; in most deployments it is the chip you actually buy today, often personalised in EV2 mode for back-compat with installed validator estates.

EV1 — the AES generation

EV1 was the first DESFire generation that could run real AES. It supports DES and 3DES with 56-, 112- and 168-bit keys (DES, 2K3DES, 3K3DES), carried over for compatibility with older MIFARE DESFire products, alongside AES-128. Authentication uses a three-pass mutual challenge-response: the card emits an encrypted random nonce, the reader returns it shifted along with its own random nonce encrypted, the card returns the reader’s nonce shifted back. After authentication, both sides derive session keys from the random material.

EV1 uses per-application keys. The application has up to 14 keys; each file in the application points at a key for read access, write access, read+write, and the special “change access rights” key. Diversification — deriving a per-card key from a master key — is recommended but not enforced; many EV1 deployments still ship with a static application key, which is fine until it isn’t.

The on-the-wire secure messaging on EV1 is per-command and per-file: you can read a public-data file in plain text, then write a sensitive file under fully-enciphered messaging in the same session. Useful, but it puts the policy on the validator’s shoulders — the card will not refuse a plaintext read of a file marked for plaintext reads.

EV1 is still in production fleets. New deployments should not start on it. Existing fleets should plan migration during the natural validator-refresh cycle.

EV2 — the architectural pivot

EV2 retained backward compatibility with the EV1 command set but introduced a parallel EV2 secure messaging scheme that is now the default for closed-loop production. The differences from EV1-style messaging are not subtle.

Per-session keys with a command counter

After an EV2-mode authentication, both sides derive a pair of session keys (one for encryption, one for MAC) from the negotiated random material. Every subsequent APDU in the session is wrapped: encrypted under the session encryption key, MACed under the session MAC key, with a command counter bound into the MAC. Replay a captured APDU and its counter no longer matches the current session position; the card rejects it.

Transaction MAC (TMAC)

EV2 added a transaction-level integrity primitive: the TMAC. When a session containing one or more value-file or backup-file commits is closed, the card emits a CMAC over the transaction, signed under the application’s TMAC key. The reader (and through the reader, the back office) can verify the TMAC after the fact — including hours later, against a transaction record uploaded at end of shift. This is the primitive that makes offline-first transit deployments auditable.

Multiple keys per access right, and key sets

On EV1 each file access right (read, write, read+write, change) maps to one key. EV2 lets each access right be assigned to up to 8 keys, and adds multiple key sets per application (up to 16) with a fast key-rolling mechanism. Different validator classes can each hold their own read key without ever holding the write key, and keys can be rotated without re-issuing cards. EV2 can also access files from two applications in a single transaction.

Practical implication

EV2 is the right starting point for any closed-loop deployment in 2026. The default secure-messaging mode is good enough that even a sloppy validator implementation gets the headline integrity properties for free. The EV2 transaction MAC is what makes the depot-sync model tractable.

EV3 — refinements, SUN and the Transaction Timer

EV3 keeps EV2’s architectural shape and tightens it.

• Certification. IC hardware and software certified to Common Criteria EAL5+ (the same level as EV2; EV1 is EAL4+). NXP does not publish a side-channel countermeasure delta between EV2 and EV3, so we don’t claim one.
• Performance and range. NXP states improved transaction speed and a greater operating distance than earlier generations, which matters when your tap-to-decision budget is 300 ms.
• Transaction Timer. Limits how long an in-progress transaction may take; NXP positions it against man-in-the-middle attacks.
• Secure Unique NFC (SUN). Secure Dynamic Messaging produces a fresh, authenticated message on each tap, for NFC-tag style use cases.

Picking a generation in 2026

For greenfield closed-loop deployments: buy EV3 chips, personalise in EV2 mode. EV2 mode is what installed validator estates are most likely to accept; you get EV3’s silicon improvements regardless. Keep EV3-only features (Transaction Timer, SUN messaging) in your “light up when validators catch up” list.

For brownfield estates: stay on whatever generation your existing validators handle, plan the migration during your next validator refresh, and don’t roll EV3-only features in cards before EV3-aware firmware in validators. A card-side feature your readers ignore is not a feature.

A word on diversification

Across all three generations, the practical security depends on diversified keys. The application key K_app should never appear directly on a deployed card; instead, the SAM derives a per-card key K_card[i] = KDF(K_app, UID_i) at personalisation, and the same SAM derives the same K_card[i] at every authentication in the field. Crack one card, and you have one card — not the system. All three generations support it; NXP documents the CMAC-based method in AN10922.

If your deployment doesn’t do diversification, you have a single point of catastrophic failure regardless of which generation you bought.

Secure messaging modes, side by side

A note on the APDU envelope

DESFire commands ride on top of standard ISO 7816-4 APDUs over the 14443-4 transport. The application-select uses SELECT (CLA=00 INS=A4); subsequent DESFire-native commands are wrapped with proprietary CLA 0x90. We have a free APDU parser that handles the envelope, and a dedicated DESFire status decoder for the response status bytes (OPERATION_OK, AUTHENTICATION_ERROR, ADDITIONAL_FRAME, etc.). For the opcodes themselves, our DESFire command set reference lists every native command, its code, and which generation (EV1/EV2/EV3) supports it.

Migration paths that have shipped

1. EV1 → EV2 in-place. Keep the validator estate; ship EV2 cards personalised in EV1 mode for compatibility. Schedule a coordinated firmware update on validators that lights up EV2-secure messaging. Re-personalise cards over their natural refresh cycle.
2. EV1 → EV3. Ship EV3 in EV2 mode; personalise validators’ SAMs to the new K_app. Older EV1 cards continue to work in EV1 mode until natural attrition retires them.
3. Greenfield. EV3 chip, EV2 mode, diversified per-UID keys, EV2 secure messaging, TMAC on every transaction, SAM-protected validators. There is no remaining argument for not doing this.

What actually changed the most

If you pull back from the chip-level differences, the real evolution between EV1 and EV3 is not in the cryptographic primitives. AES-128 is the same primitive across all three. The change is in how the platform forces you to use it well.

• EV2 added multiple key sets with fast key rolling, so rotating diversified keys no longer means re-issuing cards.
• EV1 made secure messaging available per file. EV2 made per-session, counter-bound secure messaging the default.
• Transaction-level integrity (TMAC) didn’t exist on EV1. It does on EV2/EV3, and it changes what an offline transit deployment can prove to an auditor.
• Certification moved from Common Criteria EAL4+ (EV1) to EAL5+ (EV2 and EV3).

What this means for your deployment

If you are designing for 2026: pick EV3 for the silicon, run it in EV2 mode for compatibility, and use the EV2 secure-messaging plus TMAC features as your default. Diversify keys per UID. Keep your issuer key in a SAM (see the SAM architecture page); never put it in validator firmware. Pair this generation choice with the 300-ms tap budget — the topic of our pillar on low-latency validators — and you have an architecture that will stay credible for the next decade.

Primary sources

• NXP: MIFARE DESFire EV1 product page (EAL4+, key sizes, 14 keys per application; marked not recommended for new designs)
• NXP: MIFARE DESFire EV2 product page (EV2 Secure Messaging, Transaction MAC, key sets, keys per access right, EAL5+)
• NXP: MIFARE DESFire EV3 product page (EAL5+, Transaction Timer, SUN, backward compatibility with EV2, EV1 and D40)
• NXP AN12752: MIFARE DESFire EV3 feature and functionality comparison
• NXP: MIFARE DESFire EV2 announcement (March 2016) · EV3 announcement (June 2020)
• NXP AN10922: symmetric key diversifications

Related reading

• Technology: DESFire architecture
• Reference: DESFire command set (EV1/EV2/EV3)
• Technology: SAM architecture
• Architecture: Card ↔ Reader ↔ SAM flow
• Solution: Closed-loop ticketing knowledge center
• Pillar: Why SAMs matter in closed-loop transit systems
• Pillar: Designing low-latency secure transit validators