MIFARE DESFire EV3

Family and part numbers

Picture the plastic card clipped to a lanyard in any large office: it opens the garage gate at eight, buys a sandwich at noon, badges into the data hall at two, and checks out a loaner laptop on the way home — and it flatly refuses to do any of it for a reader that cannot first prove it is the reader it claims to be. That card is, nine times out of ten, a DESFire EV3 — the chip teams standardise on right after 'good enough' security has flunked its first audit. DESFire EV3 silicon carries the NXP MF3D(H)x2 family prefix and sits at the apex of the MIFARE roadmap. The part-number suffix signals memory class while the rest of the functional envelope — Common Criteria EAL5+ certification, AES-128 cryptography, ISO/IEC 14443-4 compliance — is identical across the three SKUs. Procurement teams use the variant choice purely as a memory-budget exercise, matching user file capacity to the anticipated multi-application footprint over the card's ≥10-year operational life.

• MIFARE DESFire EV3 — NXP part family MF3D(H)x2. Three memory variants: 2 KB (MF3DHx2), 4 KB (MF3DHx4), and 8 KB (MF3DHx8). Same command set across all three; only user file capacity differs.
• ISO/IEC 14443-4 Type A compliant. Seven-byte UID, full APDU exchange, 106-848 kbps data rate negotiable. Bit-for-bit protocol-compatible with any ISO 14443-4 reader, including HID, Suprema, Idesco, Nedap, and transit-authority readers from Cubic and Thales.
• Operating temperature — -25 °C to +85 °C. Data retention ≥ 25 years at 55 °C. Endurance ≥ 500,000 write cycles per file.
• Generational lineage: DESFire EV1 (2008, launched the 3DES→AES migration), EV2 (2016, added MIFARE 2GO and transaction MAC), EV3 (2020, added proximity check and enhanced transaction integrity). EV3 is fully backwards-compatible with EV1 and EV2 readers.
• Complementary variants: DESFire Light (MF2DL_H10, cost-optimized single-application subset of DESFire for public transit ticketing) and DESFire EV3 EP (with 8 KB + extended performance).
• Silicon authenticity: the first two bytes of the UID are 0x04 (NXP manufacturer code); Get Version command returns hardware type 0x01, software type 0x01, and major.minor version indicating EV3 silicon. Counterfeit 'DESFire-compatible' chips often return mismatched version bytes.
• Common Criteria certification: DESFire EV3 carries CC EAL5+ augmented with AVA_VAN.5 (PP-0084) for the hardware plus the MIFARE OS; this certification envelope is what lets transit authorities and government-issued credential programmes specify DESFire EV3 in competitive tenders, where EAL4+ ends up disqualifying simpler contactless chips.
• Inlay and package formats. Wafer sawn die for delivery to NXP-licensed converters (Smartrac/Avery Dennison, Linxens, Identiv), pre-laminated PVC cards (CR80), 25 × 15 mm and 18 × 12 mm wet inlays for label converters, and pre-tested modules (M5.3 module in 0.76 mm PVC core). UID pre-personalisation and random-UID modes are selectable at converter stage via a one-time configuration.

Memory model — application, file, access rights

DESFire's file system is the feature that distinguishes it from every fixed-sector contactless chip (MIFARE Classic, MIFARE Plus, NTAG). Architects should think of the PICC as a miniature filesystem-on-a-card with a three-level hierarchy (PICC → Application → File), discretionary access-control rights at the file level, and transactional semantics (backup files plus CommitTransaction/AbortTransaction) that are closer to a database than to a memory chip. Every deployment decision (how many applications to provision, how to partition keys between departments, whether to use standard or backup files) flows from this model.

• PICC-level: the root layer. Contains a 7-byte UID, a PICC Master Key, configuration bytes, and up to 28 applications (identified by 3-byte AID, Application ID).
• Application level: each application has its own keys (up to 14 keys per application for EV3, vs. up to 14 for EV2). The PICC Master Key can create/delete applications; each application's Application Master Key (key 0) can manage keys within it.
• File level: each application holds up to 32 files (file IDs 0x00-0x1F). File types: Standard Data File (fixed-length binary), Backup Data File (with commit/abort), Value File (32-bit signed integer with credit/debit semantics), Linear Record File (fixed-length records), Cyclic Record File (circular buffer).
• Access rights per file. Four fields: Read Access, Write Access, Read & Write Access, Change Access Rights. Each can be set to one of the 14 application keys, or to 'free' (no authentication required), or to 'deny' (no access at all).
• Backup vs. standard files: standard files commit writes immediately; backup files maintain a shadow copy and commit atomically on CommitTransaction, allowing rollback on AbortTransaction. Critical for transit applications where a partially-written fare balance must never leave the card in an inconsistent state.
• Value files: native credit/debit semantics with configurable limits and a 'limited credit' mode where an unauthenticated writer can credit up to a pre-configured maximum without authentication, useful for top-up kiosks.
• Free memory tracking: GetFreeMemory returns remaining bytes in the PICC, a useful sanity check during provisioning of multi-application cards.
• Delegated Application Management (DAM). EV2 and EV3 expose a delegated key-hierarchy model where an OEM holds the DAM Authentication Key and can pre-authorise third parties (campus departments, transit operators, service bureaux) to create applications on deployed cards without the PICC Master Key ever leaving the HSM. Card issuance workflows use DAM to delegate a fixed quota of applications to each tenant, bounded by MasterDAMAuthKeyVersion and DAMPreAuth structures.
• ISO file name support. When the PICC-level ISO_DF_NAMES_SUPPORT bit is set, applications accept an additional ISO 7816-4 AID (up to 16 bytes) alongside the 3-byte DESFire AID; this allows GlobalPlatform-style multi-app AID namespaces so that a DESFire EV3 can live side-by-side with Java Card and EMV applets in a dual-interface form factor without AID collisions.

Command set — organized by authentication level

The DESFire command set is the union of the native DESFire APDU framing (CLA=0x90 wrapper plus single-byte INS) and the ISO/IEC 7816-4 framing (CLA=0x00, full ISO APDUs). Reader stacks may choose either; most NXP TapLinx and PC/SC middleware wrap native commands in ISO 7816-4 headers so that standard smartcard transport (T=CL on 14443-4) carries the payload. The commands below are grouped by the authentication state they require. Unauthenticated commands always work, authenticated commands require an active session key bound to the selected application.

• Unauthenticated (PICC level): GetVersion (0x60, returns 28 bytes of version info), GetCardUID (0x51, returns 7-byte UID), GetApplicationIDs (0x6A, returns list of 3-byte AIDs on the PICC), SelectApplication (0x5A AID), FreeMem (0x6E), GetKeySettings (0x45), GetKeyVersion (0x64).
• Authentication: AuthenticateEV2First (0x71) for fresh mutual auth with forward-secure session keys, AuthenticateEV2NonFirst (0x77) to authenticate additional keys without repeating the first-pass RndA exchange, AuthenticateAES (0xAA) for legacy three-pass AES (EV1-compatible mode), AuthenticateLRP (0x71 with LRP flag) for Leakage-Resilient Primitive mode (side-channel hardened).
• Application management: CreateApplication (0xCA AID, keySettings, numberOfKeys), DeleteApplication (0xDA AID), ChangeKeySettings (0x54), ChangeKey (0xC4 keyNumber, newKey, keyVersion).
• File management: CreateStdDataFile (0xCD), CreateBackupDataFile (0xCB), CreateValueFile (0xCC), CreateLinearRecordFile (0xC1), CreateCyclicRecordFile (0xC0), DeleteFile (0xDF), GetFileSettings (0xF5), ChangeFileSettings (0x5F), GetFileIDs (0x6F).
• Data operations: ReadData (0xAD file, offset, length), WriteData (0x3D file, offset, length, data), GetValue (0x6C), Credit (0x0C value), Debit (0xDC value), LimitedCredit (0x1C value), ReadRecords (0xBB), WriteRecord (0x3B), ClearRecordFile (0xEB).
• Transaction integrity: CommitTransaction (0xC7), AbortTransaction (0xA7), CommitReaderID (0xC8 for reader-binding in session), ReadSig (0x3C for the card's ECDSA originality signature).
• EV3-specific: ProximityCheck (0xFD pre-check, 0xFC main check, 0xFF verification), Transaction MAC support via the TMCounter file (0x0F) and the associated ChangeTransactionMACKey flow.
• ISO 7816-4 SELECT — the standard smartcard SELECT command (00 A4 …) is supported in parallel for reader stacks that prefer ISO APDU framing over native DESFire APDUs.
• Additional Frame (0xAF): DESFire splits long payloads across multiple T=CL frames by returning 0xAF as the status word to signal 'more data follows'; readers respond with a bare 0xAF command to collect the next frame. All long responses (GetVersion, large ReadData, large GetApplicationIDs) use this continuation protocol, so reader middleware must implement a 0xAF loop rather than assuming single-frame responses.
• Status-word vocabulary — 0x9100 success, 0x919D permission denied, 0x917E length error, 0x911C illegal command, 0x919E parameter error, 0x9140 no such key, 0x91F0 file not found, 0x91AE authentication error, 0x91BE boundary error (out-of-range read/write), 0x910E transaction integrity error. DESFire middleware should map these to human-readable errors for operator diagnostics.

Authentication — the three-pass mutual AES flow

DESFire authentication is mutual, challenge–response, and stateful. The reader and card each prove that they know the shared AES-128 key by exchanging encrypted random challenges; once both sides verify, both derive independent session encryption and MAC keys that bind every subsequent command in the session. The three-pass handshake takes about 20 ms on an average reader (HID Signo, OMNIKEY 5422, Feitian bR500) and completes inside a single tap. Key agility is a first-class feature. Readers can authenticate to multiple application keys in one session, and key rotation is supported live via ChangeKey.

• Step 1 — Reader issues AuthenticateEV2First with the target key number (e.g. 0x00 for app master key). Card returns 16-byte encrypted RndB (random challenge B) using the pre-shared AES-128 key.
• Step 2 — Reader decrypts RndB using the key, generates its own 16-byte RndA, computes RndA'||RndB' (where B' is RndB rotated left one byte), encrypts the concatenation, and sends 32 bytes back to the card.
• Step 3 — Card decrypts, verifies that the received RndB' matches RndB rotated, extracts RndA, rotates it one byte left, encrypts, and returns 16 bytes. Reader decrypts and verifies.
• Session keys: post-authentication, both sides compute session encryption key (SessEncKey) and session MAC key (SessMACKey) from RndA and RndB using the standard DESFire key derivation function. All subsequent commands in the session are either plain, MAC'd, or fully encrypted depending on file communication settings.
• Communication modes: Plain (no crypto, still requires session to be authenticated for access-controlled files), MACed (CMAC appended to every command/response), Fully Enciphered (entire command + response encrypted with SessEncKey and signed with SessMACKey). File creation specifies which mode the file uses for each operation.
• AuthenticateEV2First vs AuthenticateEV2NonFirst — EV2First clears any prior session and establishes a fresh one with new random challenges. EV2NonFirst lets the reader authenticate a second or third key within the same session without repeating RndA; useful when a single transaction uses multiple keys (e.g. one for reading balance, another for decrementing).
• Key versions: each key slot has a 1-byte version number. ChangeKey requires knowing the current version. Rotating keys in a deployed fleet is coordinated by version numbers; a card may reject a ChangeKey if the provided version is stale.
• Leakage-Resilient Primitives (LRP) mode. DESFire EV3 introduces the option to derive per-command encryption keys using LRP, a side-channel-hardened key-schedule that reduces the usable leakage from a single AES-128 master key across many authentications. LRP is enabled by a PICC-level configuration bit and selected at AuthenticateEV2First time; deployments that worry about nation-state differential power analysis (high-value transit, government access) switch LRP on at personalisation.
• Cryptographic diversification: production keys are almost never used as-is. Card issuance derives per-card keys from a master key and the card's UID using AES-CMAC diversification (NXP AN10922). A reader network then only needs the master key plus the UID from each card to compute the expected per-card key. This is the fleet-management model that keeps master keys inside HSMs while letting every reader authenticate every card without pre-loading 100,000 individual keys.

Transaction MAC and proximity check — EV3 signature features

Two security upgrades define the EV3 generation and justify the migration from EV2 silicon: Transaction MAC (TMAC) and Proximity Check (PC). TMAC addresses a class of attacks where a compromised reader or man-in-the-middle splices malicious commands into an authenticated session; PC closes down NFC relay attacks where an attacker uses a pair of smartphones to bridge a victim's card to a distant reader. Neither feature is enabled by default. Both require explicit configuration at card personalisation and corresponding reader firmware support.

• Transaction MAC (TMAC): a cryptographic counter stored on-card that chains a MAC across all commands within an authenticated session. The reader can include 'transaction reader ID' + TMAC value in the session, and the card verifies the TMAC at CommitTransaction. Prevents mid-transaction tampering where an attacker intercepts a partial transaction and tries to splice in a modified command.
• TMCounter file (0x0F): a special file type that EV3 introduces for TMAC. Holds a 4-byte transaction counter and a 16-byte TMAC value, both cryptographically bound. Reading this file returns the counter to the reader, which uses it as part of the session integrity checks.
• Proximity check: a challenge-response round-trip time measurement that detects NFC relay attacks. Reader issues PreparePC, then a sequence of 1-7 PC challenges, each measured for round-trip latency. If the latency exceeds a configurable threshold (typically 1-3 ms), the proximity check fails. Indicating the card might be behind a relay attacker instead of physically present.
• Proximity check integration: the reader firmware must support PC because the feature is activated by the reader. Building access controllers from HID Signo series, Suprema Bioentry W2, and similar recent systems do support PC on EV3 cards. Older reader firmware simply skips PC, degrading to EV2-level transaction integrity.
• Originality signature: DESFire EV3 carries an ECDSA signature over its UID, signed by NXP's production key. ReadSig (0x3C) returns the signature; the reader can verify against NXP's published public key to prove the card is authentic NXP silicon. Used in high-value deployments to reject counterfeit cards before they enter the access-control issuance workflow.
• Transaction session vectors: EV3 binds each CommitTransaction to a monotonically-increasing TMC (Transaction MAC Counter) and a TMV (Transaction MAC Value). Server-side audit logs store the tuple {UID, AID, TMC, TMV, timestamp} so any later dispute about whether a transaction occurred can be resolved cryptographically rather than by trusting reader logs alone. Transit revenue-assurance teams use this to settle fare-evasion disputes.
• Proximity check timing budget. The card-internal ProximityCheck round-trip budget is typically set between 500 µs and 3 ms depending on reader firmware. Over-tightening the budget causes legitimate taps to fail on slow CPU readers; too loose lets a nearby relay succeed. NXP AN12752 recommends 2 ms as a practical default for HID Signo-class hardware; high-security deployments tighten to 1 ms after field-calibrating 200+ taps.

Application deployment scenarios

DESFire EV3 covers the spectrum from single-application access cards to ten-application multi-tenant campus credentials. The common factor is that all of these deployments need strong cryptography, reliable transactional semantics, and long operational life. Qualities that make DESFire EV3 the default answer when the card's lifetime exceeds three years or the access-control network spans multiple buildings. Each scenario below pairs the DESFire capability that matters most to that application with a real-world reader or system integrator that has certified support.

• Corporate access control: primary DESFire EV3 use case. Single application on the card holds a 16-byte credential number protected by an AES key shared between the card and the reader network. HID Signo, Suprema, Nedap AEOS and every modern enterprise access system support DESFire EV3 natively.
• University / campus credential: multi-application: door access (one AID), library checkout (another AID), meal plan value file (third AID), printing/copying vending (fourth AID). Each application's master key is held by the issuing department, and a central IT team holds the PICC Master Key.
• Transit ticketing: DESFire EV3 or DESFire Light. Value files with credit/debit semantics and backup/commit/abort for atomic fare deductions. TransBay TransLink, SEPTA Key, Ventra (Chicago), and Clipper II (Bay Area) are all DESFire or DESFire-variant deployments.
• Closed-loop cashless payment. Stadium vendor systems, resort plastic cards, gym chain member cards. Value file plus credit/limited-credit for kiosks plus debit for vendor terminals. Transaction MAC is the security advantage over older MIFARE Plus deployments.
• Event multi-day wristbands (VIP tiers, all-access badges). DESFire EV3 on an epoxy key tag or wristband insert, one application for entry control and one for cashless beverage vending. Proximity check catches ticket-reseller relay attacks at gate entry.
• Industrial access (controlled-rated areas in pharma, aerospace MRO). DESFire EV3 for dual-factor badge-plus-PIN flows. The PIN is not on the card; DESFire carries only the cryptographic credential and the reader combines it with a PIN entered at the keypad.
• Regulated pharmaceutical cleanrooms and data centres. DESFire EV3 integrates with mantrap controllers (Boon Edam Circlelock, Alvarado EDC) that cross-check the badge AID against a SCIF (Sensitive Compartmented Information Facility)-style access policy. Proximity check is mandatory in these deployments to prevent 'card shoulder' relay attacks where an attacker bridges from the car park to the reader.
• When DESFire EV3 is not the right choice. Single-application consumer authentication (use NTAG424 DNA for smartphone tap-to-verify), cost-sensitive loyalty cards (use MIFARE Classic or Ultralight EV1 for closed-loop, non-secure applications), ultra-low-cost transit disposables (use DESFire Light rather than full EV3).

Migration from DESFire EV1 / EV2 to EV3

DESFire EV3 was designed for drop-in migration: every EV2 reader works with EV3 cards immediately, and only deployments that want to opt in to the new security features (Proximity Check, enhanced Transaction MAC, LRP mode) need to upgrade reader firmware. Large enterprise campuses and transit operators typically plan a two-to-three year migration on natural attrition. Issue EV3 for all new cards, keep the EV1/EV2 reader network unchanged, and retrofit PC-capable readers only at high-value choke points first.

• Reader firmware: EV3 is fully backwards-compatible with EV1 and EV2 command sets. A reader that works with EV2 cards works with EV3 cards unchanged, treating them as EV2 cards. To exploit EV3 features (proximity check, enhanced transaction MAC) the reader firmware needs updating.
• Card personalization workflow: EV3 silicon accepts the same application and file creation commands as EV2. Existing personalization scripts work without changes. To enable EV3 features (e.g. ProximityCheck) the script must create a TMCounter file (0x0F) with appropriate access rights.
• Key migration: existing EV1 / EV2 AES keys can be transferred to EV3 without change. Card issuance stays the same.
• PICC-level configuration byte. EV3 introduces additional configuration bits in the PICC settings; set ISO_DF_NAMES_SUPPORT, RANDOM_UID, and MIRROR_UID as needed for the deployment. Legacy scripts that don't set these continue to work; the EV3 card uses sane defaults.
• Coexistence: EV1, EV2, and EV3 cards can coexist in the same deployment. Readers implement a fallback chain (try EV3 first, then EV2, then EV1) so a single reader network can handle a mixed fleet. Most enterprises migrate by attrition: new issuance is EV3, old cards continue to work until they're replaced on natural expiry.
• Version-gate rollout: reader firmware images typically probe GetVersion hardware-major/minor before selecting the feature profile: hardware version 0x33 indicates EV3, 0x12 indicates EV2, 0x01 indicates EV1. The reader picks the strongest feature set the card supports, so a single firmware binary handles the entire install base for the migration window.
• Mutual attestation during migration. Some regulated deployments (pharma, data centres) require the card-management system (CMS) to cross-check ReadSig (0x3C) against NXP's published Originality Check public key at every issuance. For a mixed EV1/EV2/EV3 fleet this means the CMS must carry all three generations' root public keys. NXP publishes a bundled trust anchor in AN11350 that auditors can reference.

NXP reference documents

Every DESFire EV3 integration project traces back to the same small stack of NXP application notes. Product data sheets and the core protocol note (AN10787) live under NDA on NXP's DocStore. Distributors such as NXP Design Partners (Proud Tek included) can sponsor customer access. The feature-hints notes (AN12752, AN11004, AN12343) are typically available without NDA and cover the implementation-level details a reader firmware engineer needs.

• MIFARE DESFire EV3 MF3D(H)x2 Product Data Sheet (NDA-wrapped via NXP's DocStore). The canonical chip reference.
• AN12752 — DESFire EV3 features and application hints. Transaction MAC, proximity check, and communication-mode implementation details.
• AN10787 — DESFire protocol reference (applies to EV1/EV2/EV3). The command-set opcodes and APDU layouts.
• AN11004 — DESFire authentication and session key derivation reference. Pseudocode for the three-pass AES authentication and SessEncKey / SessMACKey computation.
• MIFARE SDK / TapLinx: NXP's Android and iOS SDKs that abstract the DESFire command set into higher-level Java/Swift APIs. Reference implementations for reader integration.
• ISO/IEC 14443 Parts 1-4 — the air-interface and transport-protocol standards. DESFire EV3 implements Parts 1, 2, 3 and 4 in full.
• ISO/IEC 7816-4 — the smartcard command framework. DESFire EV3 accepts ISO 7816-4 APDUs in parallel to the native DESFire APDUs.
• AN12343 — MIFARE SAM AV3 integration guide. Covers the PC/SC APDU chain between host, SAM, and DESFire card for offline key-injection flows and ChangeKey rollouts.
• AN10922 — AES-based key diversification. The normative reference for deriving per-card keys from a master key and UID; every large-fleet DESFire deployment uses this derivation scheme.

SAM-assisted personalisation and key injection

Production-grade DESFire EV3 issuance never exposes master AES keys to reader firmware, encoding PCs, or operators. Instead, the master keys live inside a MIFARE SAM AV3 (Secure Access Module) (a tamper-resistant SmartMX silicon module in an ID-000 cutout card) that sits between the host PC and the contactless reader. The host sends the DESFire UID to the SAM; the SAM performs AN10922 diversification internally, builds the ChangeKey or CreateApplication APDUs with the derived key, encrypts them under the current session key, and hands the prepared APDUs back to the host to forward to the card. The plaintext master key never leaves the SAM. This pattern satisfies Common Criteria, PCI-DSS, and ISO 27001 key-custody requirements.

• SAM AV3 architecture — Common Criteria EAL5+ silicon with up to 128 AES-128 key slots, a hardware DRBG, and its own anti-tamper sensors (temperature, voltage, light). Installed in a USB-connected contactless reader such as the Feitian bR500, HID OMNIKEY 5422, or Identiv SCM uTrust 4701 F. The host talks PC/SC to the SAM; the SAM talks PC/SC to the DESFire card.
• Personalisation recipe: (1) SelectApplication 0x00000000 PICC-level, (2) AuthenticateEV2First with PICC Master Key (via SAM offline-lookup by UID), (3) CreateApplication 0xCA with AID 0xF00001 + 0x0F key settings + 0x86 (3 keys + AES) + 0x00 (AES) + 0x00000000 (ISO DF) + '' (ISO Name), (4) SelectApplication 0xF00001, (5) AuthenticateEV2First with AppMasterKey0 (all zeros by default), (6) ChangeKey 0xC4 keyNumber=0x00 + diversified AES-128 key derived by SAM from UID+masterKey0 + version 0x01, (7) repeat ChangeKey for key 1 (Read key) and key 2 (Write key), (8) CreateStdDataFile 0xCD for credential file, set access rights to require Key-0 for Read and Key-1 for Write, (9) WriteData 0x3D with the credential number, (10) SelectApplication 0x00000000 and ChangeKey on the PICC Master Key to lock the card.
• Dual-interface/NDEF bootstrap. For EV3 cards that double as NFC NDEF tags, the personalisation also creates a standard-data file 0x02 with ISO File ID 0xE104 and access rights 'Read=free, Write=Key0' so that any NFC phone can tap-read a URL without authentication but only an authenticated issuer can update it.
• Audit evidence: the SAM's PC/SC log captures {SAM serial, operator PIN, timestamp, UID, AID, commands, response SW} for every ChangeKey and every write. A write-once logger (USB HSM, blockchain ledger, or append-only SIEM sink) archives this log for the card's 10-year lifetime. ISO 27001 Annex A.14.2.1 and PCI-DSS 3.6 both require this audit trail for chip-card key rotations.
• Error-recovery procedures: if a personalisation step fails mid-card (reader dropout, antenna interference, Commit failure), the operator protocol is: (1) attempt AuthenticateEV2First with all-zero key (fresh card), (2) if that fails, try with the partial-diversified key, (3) if both fail, quarantine the card to a 'reject' bin; DO NOT attempt random authentication as it can trigger the ten-failed-auth lockout on the application master key. Typical reject rates in a well-tuned line are 0.1-0.3 %.
• Reader selection: the reader must provide stable 13.56 MHz field for the 200 ms personalisation window. Tabletop reader antennas with a 40-50 mm read range perform best; smartphone readers are not used for personalisation because their low-power PN533 antennas drop out during the AuthenticateEV2First + ChangeKey round-trips.
• Throughput: a well-tuned SAM + reader + host pipeline personalises 2,000-3,000 DESFire EV3 cards per hour on a single lane. Large credential bureaux (HID Global Personalization Services, Oberthur/IDEMIA, Proud Tek itself) run 8-16 lanes in parallel in an ISO 27001-certified room.

Specifications at a glance

The memory-variant table below lets procurement teams match the DESFire EV3 part number to the application footprint. In practice, 2 KB fits single-application access-control deployments; 4 KB fits mixed access-plus-cashless multi-application; 8 KB is reserved for full campus credentials with door access, transit, library, cashless payment, and loyalty all on the same card. All three variants are mechanically identical (standard CR80 card body, 0.76 mm thickness) and carry the same EAL5+ certification. Across all three SKUs the cryptography and the certification stay the same; only the memory changes — which makes this a refreshingly honest line-item: size the card to the applications you will actually load, because there is no premium security tier waiting to be upsold.

FAQ