How card based MFP authentication works with HID MIFARE and DESFire

Card based authentication on an office MFP lets users tap a card against a reader on the device to log in, releasing their print jobs and authorising their copy, scan, and fax operations under their own user account. The card replaces the awkwardness of typing a PIN on the front panel and produces a much faster authentication flow that office users adopt willingly. The technology behind the card varies across three main format families: HID Prox, MIFARE Classic and Plus, and DESFire EV1 or EV2. Each format carries different security properties, and the choice between them affects both how the office issues cards and how secure the authentication actually is.

How the authentication actually flows

HID Prox in detail

HID Prox uses 125 kHz radio frequency identification, with the card returning a fixed unique identifier when the reader queries it. The format dates from the early 1990s and remains widely deployed in office building access control systems. The advantage of HID Prox for MFP authentication is that most offices already have HID Prox infrastructure for building access, which means existing employee badges can authenticate users at the MFP without any additional cards being issued.

The disadvantage is that HID Prox cards have no built in security. The card returns the same identifier each time it is read, and the identifier can be cloned to a blank card using readily available equipment. The cloned card authenticates at the MFP exactly the same as the original. Offices accepting HID Prox for MFP authentication need to accept that any employee badge can be cloned by anyone with brief physical access to the original.

MIFARE Classic and MIFARE Plus in detail

MIFARE Classic uses 13.56 MHz contactless smart card technology with Crypto1 encryption. The card stores user data in encrypted memory sectors, with each sector protected by a key. The reader and card perform a mutual authentication using the key before any data exchange. MIFARE Classic improved on HID Prox by adding encryption, and the format saw widespread deployment in public transit systems and in some office environments through the 2000s.

MIFARE Classic's Crypto1 cipher has documented weaknesses that allow the key to be extracted with reasonable effort using academic research published in 2008 onward. Cloning a MIFARE Classic card is more difficult than HID Prox but possible with the right equipment. MIFARE Plus replaced MIFARE Classic's Crypto1 with AES encryption, addressing the cryptographic weakness. MIFARE Plus cards are appropriate for MFP authentication in environments that need more security than HID Prox but where DESFire is not deployed.

DESFire EV1 and EV2 in detail

DESFire is the current generation of secure contactless smart cards from NXP Semiconductors. The EV1 variant uses 3DES or AES 128 encryption, while EV2 adds AES 256 support and additional security features. The card supports mutual authentication, secure messaging, and resistance to the cloning attacks that affect older formats. DESFire is the standard format for new office authentication deployments where security is a meaningful requirement.

DESFire cards cost more than HID Prox or MIFARE Classic, typically €4 to €12 per card depending on volume and configuration. The price difference is small relative to the security improvement, particularly for offices handling sensitive data. Most new MFP authentication system deployments specify DESFire as the card format, with HID Prox or MIFARE Classic accepted for backward compatibility with existing building access cards.

Format comparison matrix

The card reader hardware

Card readers attach to the MFP through a USB port on most modern devices, with serial or network connections used on some older models. The reader needs to support the same card format as the deployed cards: a HID Prox reader will not read MIFARE cards, and a MIFARE reader will not read DESFire EV2 unless specifically configured for it. Multi format readers exist that handle several card families through a single device, useful for environments with mixed legacy and current cards.

The OEM that supplies the MFP usually offers a compatible card reader as an accessory. Third party readers from specialist suppliers also work on most office MFPs, often at lower cost and with broader format support. Choosing between OEM and third party readers comes down to support relationship preferences and to the specific format requirements of the deployment.

The card management backend

Behind the cards and readers sits a card management system that holds the mapping between card identifiers and user accounts. The system can be as simple as a flat file imported into the MFP's local user directory, or as sophisticated as a dedicated print management server integrated with Active Directory and the office's HR system. The choice affects how cards are issued, how lost cards are handled, and how the authentication scales across multiple devices.

Small offices often start with the simple approach: card identifiers imported manually into the MFP's local user list, with each device maintaining its own copy. The approach works for one or two devices and a stable user list but breaks down at scale. Larger offices benefit from a centralised card management server that synchronises card mappings across all MFPs and integrates with the office's identity directory.

Common deployment challenges

Three challenges appear consistently during card authentication deployments. The first is the gap between building access cards and MFP authentication cards: an office that issues separate cards for each system multiplies the inventory and complicates the user experience. Using the same card for both, where format compatibility allows, simplifies the deployment substantially. The second is the user enrolment process: assigning each existing card to its user takes time at first deployment, and offices benefit from a structured enrolment day rather than ad hoc per user setup.

The third is the fallback authentication path: cards can be left at home, broken, or lost. The deployment needs a fallback that lets users authenticate without their card, usually a username and password or a PIN. The fallback should remain available but should be slightly less convenient than the card, to encourage routine card use without preventing emergency access.