MIFARE DESFire Cards

What is a MIFARE DESFire card?

A MIFARE DESFire card is a 13.56 MHz contactless smart card built on an NXP DESFire chip, which stores data in separate applications and files protected by their own keys, with AES-128 mutual authentication on EV1 and later generations. System integrators, distributors and card issuers specify DESFire for access control, hotel keys, campus and transport cards when a credential must be authenticated rather than simply read by its UID. The selection rule is short: specify DESFire EV3 for a new system, and match the generation, memory and application profile already approved for an existing one.

DESFire is a family, not one part. EV1, EV2, EV3 and DESFire Light differ in security features, memory and NXP lifecycle status, and the reader firmware and software decide which of those features the project can actually use. This page is the family decision guide; for a repeat order of the EV2 generation, the MIFARE DESFire EV2 card page covers part numbers, file types, commands and EV2 acceptance testing in depth.

• New access, campus or multi-application system: DESFire EV3, with memory sized from the application plan; qualify EV3 samples with the reader and software vendor.
• Existing EV2 installation: the exact EV2 part and approved credential profile.
• Existing EV1 installation: the installed EV1 specification, or EV3 in the backward-compatible mode your system uses after the readers pass a compatibility test.
• Single application, limited memory, lower-cost credential: DESFire Light, if the reader and software support it and its fixed file structure fits the application.
• Key fob, wristband or sticker instead of a card: the same generation with the high-capacitance “H” chip variant (70 pF for EV1, EV2 and EV3; 50 pF for DESFire Light) where the smaller antenna needs it.
• Upgrade from MIFARE Classic: DESFire EV3, or MIFARE Plus if the readers must keep a Classic-compatible mode, with a planned dual-technology period and key management.

DESFire EV1 vs EV2 vs EV3 vs DESFire Light

All four share the ISO/IEC 14443 Type A air interface and ISO/IEC 7816-4 file commands. What changes between generations is the security feature set, the certification level and whether NXP still recommends the chip for new designs. The table summarises NXP’s public product information; a feature helps only when the reader firmware and the application implement it.

D40 (MF3ICD40) is the original DESFire generation, now discontinued, with DES and 3DES only. EV1, EV2 and EV3 can run its secure-messaging mode for legacy readers, so a D40 estate is normally resupplied with a newer chip after the readers pass a sample test in that mode.

EV3 is NXP’s current mainstream DESFire generation: it keeps the EV2 feature set, adds SUN and the Transaction Timer, and NXP quotes an operating distance of up to 100 mm depending on the reader’s field and antenna geometry. SUN lets a phone tap produce a fresh, verifiable code in a URL, the same mechanism used by NTAG 424 DNA labels; it proves authenticity only when your backend verifies the code. Common Criteria ratings cover the chip and its operating system, not a finished card or a deployment that still uses default keys.

Which DESFire generation should I specify?

• Why EV3 for new builds: it is the generation NXP currently recommends for new designs, keeps the EV2 feature set and can run EV2, EV1 and D40 compatibility modes in a mixed estate.
• Why match an existing EV2 estate: the readers, keys and issuing software are already approved for it; the DESFire EV2 page lists the 2K, 4K and 8K parts and EV2 acceptance checks.
• Why test before replacing EV1: EV3 can replace EV1 through its EV1-compatible secure-messaging mode, but only after the installed readers, software and key configuration pass a sample test; availability of an exact EV1 part is confirmed in the quotation.
• Why DESFire Light is not a drop-in: it has one predefined application and a fixed file set, so it cannot replace a multi-application EV2 or EV3 card.
• Tender or security specification: confirm the Common Criteria level, required features (Transaction MAC, Proximity Check, SUN) and any Random ID setting in writing with the integrator before the sample stage.

DESFire 2K, 4K or 8K: how much memory do you need?

The number in “DESFire 4K” or “DESFire 8K” is the chip’s EEPROM in kilobytes. The right size depends on how many applications the card carries, their file sizes and record counts, key storage and file-system overhead, plus room for applications added later. A card with more memory than needed costs more without improving security; a card with too little cannot take the next application. Treat the table as a starting point for the discussion with your integrator.

The standard parts suit ID-1 card antennas; the “H” parts have higher input capacitance for the smaller antennas in fobs, wristbands and stickers. The chip variant and inlay are chosen together, and read range is confirmed with a sample on your reader.

Card formats, materials and personalisation

The same DESFire generation can be supplied in several credential formats, so a site can issue cards to staff and fobs or wristbands to other users on one system. For each order our factory in Shenzhen pairs the chip with a matching inlay and produces the card body, so the format is chosen for the user and the environment rather than for a fixed production line.

• ISO ID-1 cards (85.6 × 54 mm): PVC, PET or composite bodies, with offset or digital printing, gloss or matte finish, signature panel, magnetic stripe and variable numbering. See printed RFID cards for artwork and print options.
• Alternative materials: wooden RFID cards in woods such as cherry, bamboo, maple or black walnut with laser engraving or UV printing, and PLA or paper-based eco cards; confirm the chip and water-resistance finish for the use.
• Key fobs and tags: ABS, epoxy, FR4 and other bodies on the DESFire tag and key fob page, for residents and staff who prefer a keyring credential.
• Wristbands: silicone wristbands for pools, gyms and resorts, and hotel wristbands for guest rooms and cashless spending.
• Stickers and labels: MIFARE stickers with DESFire chips for devices and phone cases, including on-metal constructions.
• Transition cards: a combi card can pair a 13.56 MHz chip such as DESFire with a 125 kHz chip while an estate moves from proximity readers; confirm the chip pair in the quotation.

Printed numbers, barcodes or QR codes that must match the encoded chip data need a defined matching and inspection rule; state it in the RFQ so it is confirmed in the quotation and checked on the sample.

Encoding and key management: who holds the DESFire keys?

DESFire security depends on keys, so agree the delivery state before ordering. Cards can be supplied in the chip’s factory-default transport state for your own personalisation, with a UID list if required, or prepared through our RFID encoding service with the applications, files and access rights your system expects. Application and master keys stay with the system owner unless a key scheme and a handover method are agreed in writing; if your policy keeps keys in-house, order blank cards and encode them on your own equipment.

• Describe the application layout, key type and diversification scheme without sending secret values in the enquiry or artwork.
• Decide whether Random ID is enabled. It hides the fixed UID during card selection, but a reader or software that identifies cards only by UID will stop working with it.
• Agree who changes the default card master key, who loads production keys into readers or SAMs, and who enrols the finished cards.
• Keep the approved configuration on file so repeat orders are prepared identically.

Will DESFire cards work with my reader or lock?

A reader that shows a card number has only read the UID; it has not authenticated to a DESFire application. Before a volume order, ask the reader, lock or software provider to confirm the points below, then test a sample in the complete issuing and access workflow.

• Protocol: the reader supports ISO/IEC 14443-4 (ISO-DEP) and the DESFire command set, not only 13.56 MHz UID reading.
• Generation and mode: the firmware supports the secure-messaging mode your application uses (D40, EV1 or EV2 mode, AES or legacy 3DES keys) and, for EV3 features such as the Transaction Timer, the newer commands; SUN needs an encoder that configures Secure Dynamic Messaging and a backend that verifies the code.
• Credential format: some access platforms use their own DESFire application formats. We supply cards for systems that accept a standard or project-defined DESFire credential; confirm with your system provider whether their format can be issued on third-party cards.
• Mixed estates: readers must continue to accept the cards already in the field during a generation change.
• Phones: with a suitable NFC app, most NFC-enabled Android phones and iPhones can detect a DESFire card, but reading a protected application needs your app and the keys; a phone tap alone does not confirm system compatibility.

Migrating from MIFARE Classic or MIFARE Plus to DESFire

MIFARE Classic uses the Crypto-1 algorithm, whose published weaknesses make Classic cards easy to copy, and many Classic systems grant access on the UID alone. DESFire replaces this with AES-128 application authentication, but only when the readers are reconfigured to authenticate the application. MIFARE Plus is the alternative when readers must keep a Classic-compatible security level during migration; DESFire suits projects moving to an application-and-file model.

• Upgrade reader firmware so it authenticates the DESFire application with project keys instead of accepting a UID.
• Generate and store master keys securely, with a per-card diversification scheme agreed with the integrator.
• Run a dual-technology period, reissue credentials on a planned schedule, then disable the legacy card types in the access software.
• Keep the card number or printed ID scheme consistent so the database migration is straightforward.

DESFire for hotel keys and access control

In hotels, the lock system decides the credential. Some lock platforms use DESFire to separate room access from other applications such as spa or cashless spending; the card must match the lock manufacturer’s encoding and the front-desk encoder, which is confirmed with the lock provider and a sample. See the hotel key card guide for lock-specific requirements. For offices, residences and campuses, the access-control key fob guide compares 125 kHz proximity fobs with MIFARE Classic and DESFire credentials.

Ordering DESFire cards and samples

Standard DESFire samples are free through the sample pack; customised samples with your artwork or encoding carry a setup fee confirmed before work starts. Standard products generally ship in two to three weeks, and large orders are scheduled individually. We reply within one business day and send a quotation within one business day of a workable inquiry. MOQ, freight and the availability of a specific DESFire part are confirmed in the quotation. Strong chip supply channels and our own production let us quote competitively against the specification, quantity and quality you set; see how we manufacture and supply RFID cards for certification scope and process.

• DESFire generation and exact part if known, memory size, and whether the order is new or must match an installed specification.
• Reader or lock brand, model and firmware, and the software that issues the cards.
• Delivery state: factory default with UID list, or encoded to an agreed application profile.
• Card format and material, dimensions, artwork, numbering, quantity, destination and target date.

Send these details through the contact page. Chip references: NXP MIFARE DESFire EV3 and NXP MIFARE DESFire EV2. Chip documentation describes IC capabilities; it does not establish stock or a finished card’s compatibility with your system.