How To Choose A MIFARE Chip: Classic Vs Plus Vs DESFire Vs Ultralight

The right choice depends on what the credential must do, the security level required, the readers and software already installed, how long the credential will remain in use, and whether the system needs one application or several.

A disposable event ticket, for example, has very different requirements from a five-year employee credential or a reusable transit card. The same chip should not automatically be used for all three.

This guide compares the main MIFARE families and gives you a practical way to narrow the choice before ordering RFID cards, wristbands, key fobs, tickets or other contactless credentials.

Quick Answer: Which MIFARE Chip Should You Evaluate?

This table is a starting point, not a purchase specification. The final IC must still be checked against your reader, firmware, software, application architecture and key-management requirements.

What Is a MIFARE Chip?

MIFARE is a family of contactless IC products used in applications such as access management, public transportation, hospitality, ticketing, loyalty and closed-loop payment.

MIFARE products operate in the 13.56 MHz contactless environment, but the word "MIFARE" does not identify one single chip. Different MIFARE families use different memory structures, authentication methods and application models.

The IC is also separate from the physical credential. The same technology may be integrated into plastic cards, paper tickets, RFID wristbands, RFID key fobs, badges or other form factors.

That distinction matters because chip selection and credential construction solve different problems. The IC controls contactless functionality, while antenna geometry, material, dimensions and product construction influence physical durability and RF performance.

MIFARE Chip Comparison Matrix

The Main MIFARE Families Explained

MIFARE Classic EV1: Mainly a Legacy Compatibility Decision

MIFARE Classic remains widely recognized because large numbers of access-control, membership, campus and transportation systems were built around its sector-and-block architecture.

MIFARE Classic EV1 is available in 1 KB and 4 KB variants and operates at 13.56 MHz with a 106 kbit/s data rate.

Its main advantage today is often compatibility with an installed system rather than superior security.

If an organization already has readers, software and credential data designed around Classic sectors, changing the credential technology may require modifications to more than the card itself. This is why MIFARE 1K cards can still be relevant for replacement and maintenance projects.

However, NXP currently states that MIFARE Classic EV1 is not recommended for new designs. For security-sensitive new deployments, that lifecycle position should be considered before making Classic the default choice. See the official MIFARE Classic EV1 product information from NXP.

Practical decision: use Classic when the existing system requires it. Do not select it for a new project only because it is familiar, inexpensive or widely available.

MIFARE Plus EV2: A Migration Tool, Not Simply a "Better Classic"

MIFARE Plus EV2 becomes particularly relevant when an organization wants stronger security but cannot replace an entire Classic-based infrastructure at the same time.

Its strategic value is migration.

A large access or transit operator may have readers in hundreds or thousands of locations. Replacing all credentials, readers, firmware and back-end components in a single changeover can be impractical.

MIFARE Plus EV2 supports AES-128 security and is designed to help existing contactless infrastructures move toward a more secure architecture.

This makes the key question:

Do you need to preserve a controlled transition from an existing Classic-oriented system?

If the answer is yes, Plus EV2 deserves serious evaluation. If the answer is no and you are designing a completely new multi-application platform, DESFire may provide a more natural starting point.

MIFARE DESFire Light: Secure and Simpler for One Main Application

DESFire Light fills the space between very simple limited-use products and the more flexible multi-application DESFire EV3 architecture.

It provides 640 bytes of user memory, AES-128 security, ISO/IEC 14443 Type A communication and a predefined file structure.

The key word is single application.

If a credential needs secure access, loyalty, a transport entitlement or another defined application but does not need a large multi-service architecture, DESFire Light can reduce unnecessary complexity.

It can therefore be a more logical choice than selecting DESFire EV3 simply because EV3 has more memory and features.

MIFARE DESFire EV3: For Secure and Flexible Multi-Application Systems

DESFire EV3 is designed for applications where security, flexible data organization and multiple services may need to coexist on the same credential.

It supports ISO/IEC 14443 Type A communication, data rates up to 848 kbit/s, flexible file structures and memory variants including 2 KB, 4 KB, 8 KB and 16 KB.

NXP lists Common Criteria EAL5+ certification for the product. Current technical details can be checked on the official MIFARE DESFire EV3 product page.

The main reason to choose DESFire is not simply "more memory." Its architecture is useful when separate applications, files, keys and access permissions need to be managed within the same credential.

A campus credential, for example, could require access, attendance, cafeteria functions and another service. That is a different architecture from a card that only sends an identifier to a back-end database.

MIFARE Ultralight EV1: For Simple Limited-Use Credentials

MIFARE Ultralight EV1 is designed for high-volume, limited-use applications where simplicity and credential cost are important.

Typical use cases include single-trip transport tickets, event admission, day passes, loyalty applications and other short-life credentials.

It uses a simpler memory architecture than DESFire and provides password-based protection rather than the more advanced security model of DESFire or AES-based Ultralight products.

Ultralight EV1 makes sense when the value and risk associated with the credential are limited and advanced multi-application functionality would add complexity without solving a real requirement.

MIFARE Ultralight AES: Limited Use Does Not Have to Mean Low Security

A short-life ticket or guest credential can still carry meaningful security risk.

MIFARE Ultralight AES addresses this gap by combining limited-use positioning with AES-128 cryptographic authentication.

NXP identifies applications including public transport, hospitality, access, event ticketing and loyalty. Technical details are available in the official MIFARE Ultralight AES data sheet.

This makes Ultralight AES particularly useful when the application does not require a full DESFire architecture but basic password-based protection is not sufficient for the project requirements.

MIFARE DUOX: For More Advanced Security Architectures

MIFARE DUOX sits at the higher-security end of the current MIFARE portfolio.

It combines symmetric and asymmetric cryptography, including AES and elliptic-curve cryptography, and NXP positions it for use cases including advanced access management, secure vehicle access and EV charging.

NXP also lists Common Criteria EAL6+ certification. More details are available on the official MIFARE DUOX product page.

That does not mean DUOX should replace DESFire or Ultralight in every project. A simple membership credential rarely benefits from the additional architecture required for certificate-based or advanced key-management models.

Use higher complexity only when the threat model and system requirements justify it.

Classic vs Plus vs DESFire: The Fastest Way to Understand the Difference

The most useful distinction is therefore:

Classic is usually about compatibility. Plus is often about migration. DESFire is usually about building a more flexible secure application architecture.

Ultralight AES vs DESFire Light: Which One Should You Choose?

These two products can be confusing because both can appear in projects that need more security than a basic low-cost ticket.

Do not choose between them based on the word "AES" alone. The application model is just as important as the cryptographic feature.

A Practical MIFARE Selection Decision Path

1. Are you replacing credentials in an existing MIFARE Classic system?
2. If yes, first determine whether you need exact legacy compatibility or a phased migration. Exact compatibility may keep Classic relevant. A phased security upgrade may make Plus EV2 more appropriate.
3. Is the credential short-lived or limited-use?
4. If yes, evaluate Ultralight. Use the security requirement to decide whether a basic Ultralight product or Ultralight AES is more appropriate.
5. Do you need one main secure application?
6. If yes, evaluate DESFire Light before automatically moving to a larger multi-application product.
7. Do you need several applications, flexible files or future expansion?
8. If yes, DESFire EV3 becomes a stronger candidate.
9. Does the system require certificate-based, asymmetric or unusually high-security capabilities?
10. If yes, evaluate whether DUOX fits the broader security architecture.

How to Choose the Right MIFARE Chip Step by Step

Step 1: Define What the Credential Actually Does

Do not begin with a chip catalogue. Write down the user action first.

• Open a door
• Record attendance
• Unlock a hotel room
• Enter an event
• Store a transport entitlement
• Maintain stored value
• Support access plus payment
• Interact with a smartphone
• Replace an existing Classic credential

A one-day ticket and a reusable employee card should not be evaluated using the same priorities.

Step 2: Define the Security Requirement as a Threat

"We need a secure card" is not a complete requirement.

Instead, ask what you are trying to prevent:

• Simple credential duplication
• Unauthorized changes to stored data
• Manipulation of stored value
• Unauthorized reader access
• Communication interception or manipulation
• Cross-application access
• Poorly controlled key distribution

This immediately creates a more useful chip-selection discussion.

A loyalty credential with no stored value and a corporate access credential protecting restricted areas should not automatically use the same security model.

Step 3: Check Reader Compatibility Before You Order Cards

This is one of the most important procurement steps.

Two products can both operate at 13.56 MHz and still require different protocol, authentication, firmware or software support.

If you already have an installed system, collect:

• Reader manufacturer
• Reader model
• Firmware version
• Current card or chip model
• Software platform
• Authentication method
• Existing key structure

Use the exact reader information rather than assuming that any product listed under an RFID reader category can support every MIFARE family.

What Is Not Enough to Confirm Compatibility?

The following descriptions alone are not sufficient:

• "13.56 MHz reader"
• "NFC compatible"
• A photograph of the existing card
• The physical card dimensions
• A statement that the reader already works with "MIFARE"

You need the exact reader and credential specification.

Step 4: Decide What Data Must Be Stored

More memory is not automatically better.

Start with the data model.

Example 1: UID or Identifier Lookup

If the credential only identifies a user and all permissions are stored in a back-end database, the on-card data requirement may be small.

Example 2: Access Plus an Entitlement

If the card stores an access credential plus another entitlement or value, memory organization and access permissions become more important.

Example 3: Several Independent Services

If one credential supports access, transport, payment, loyalty or campus services, separate applications, files and keys may become more important than the total byte count.

This is one reason DESFire should not be evaluated only as "a card with more memory."

Step 5: Decide Whether Smartphone NFC Interaction Matters

Do not treat "13.56 MHz," "RFID" and "NFC" as interchangeable procurement terms.

If a smartphone must interact with the credential, confirm support for the exact IC, phone platform and application design.

Dedicated access-control readers and consumer smartphone interactions solve different problems.

Step 6: Match the Chip to the Credential Lifetime and Form Factor

A one-day event ticket has a different cost model from an employee credential expected to remain in use for several years.

The final product may be a PVC card, paper ticket, key fob, silicone wristband, woven wristband or another form factor.

For example, projects that require wearable credentials can compare options such as plastic MIFARE wristbands in addition to conventional cards.

Remember that chip capability is only one part of the finished credential. Antenna design, material, dimensions and the reader environment can affect actual RF performance.

Step 7: Compare Total System Cost, Not Only Chip Price

The cheapest credential is not always the lowest-cost system.

Total project cost may include:

• Credential cost
• Reader replacement
• Firmware upgrades
• Software changes
• Key management
• Personalization
• Encoding
• System integration
• Testing
• Migration
• Credential replacement

A slightly more expensive credential that supports a practical migration path may be less costly than a lower-priced card that forces the replacement of an entire reader infrastructure.

Step 8: Test the Real Credential Before Mass Production

Never treat a datasheet as a substitute for system testing.

Test the exact combination of:

• Chip
• Antenna
• Credential material
• Reader
• Firmware
• Software
• Encoding
• Keys
• Installation environment

For development and verification work, a suitable 13.56 MHz NFC reader and writer may be useful, but production compatibility must still be validated against the reader that will actually be deployed.

Which MIFARE Chip Fits Different Applications?

Access Control

For a new security-sensitive access-control system, begin with the security architecture and reader capability rather than automatically specifying Classic.

DESFire is often worth evaluating when a secure modern credential is required, while Plus becomes especially relevant if an installed Classic infrastructure needs a migration path.

Classic may still be required for legacy replacement projects.

When planning the physical credential, relevant product options include MIFARE access cards. Reader-side planning should be treated separately; an RFID access-control reader must support the chosen credential architecture.

Event Ticketing

For simple short-term admission, start by evaluating the Ultralight family.

If stronger authentication is required, Ultralight AES may be a more appropriate limited-use option.

If the event credential also handles access zones, stored value, hotel functions or multiple applications, DESFire may become more relevant.

The IC can then be integrated into products such as RFID event wristbands.

Hotel Key Cards

Hotel projects require extra caution because compatibility depends heavily on the lock system.

Do not choose a hotel credential from a generic chip table alone.

First obtain:

• Lock manufacturer
• Lock model
• Existing credential type
• Supported chip specification
• Required personalization or encoding process

Only then should you select the card construction, such as an RFID hotel key card.

Public Transportation

Transit projects can range from inexpensive single-trip tickets to reusable multi-service credentials.

Limited-use tickets may fit the Ultralight family. Reusable secure credentials may require DESFire or another stronger architecture. Existing Classic deployments may need Plus as part of a staged migration.

Campus and Membership Cards

If a card simply identifies a member and the back end stores all permissions, the on-card application requirement may be modest.

If one credential supports access, attendance, library services, cafeteria payment and other functions, the value of a structured multi-application architecture increases significantly.

Closed-Loop Payment

Stored value increases the impact of credential copying, manipulation or weak key management.

Security architecture, transaction integrity, authentication and operational key management should therefore carry more weight than the price of the card alone.

How to Approach a Legacy MIFARE Classic Migration

Do not treat migration as a simple card-replacement order.

Build an inventory first:

1. Existing reader models
2. Reader firmware
3. Back-end software
4. Current credential model
5. Current key architecture
6. Number of active credentials
7. Whether old and new credentials must coexist
8. Migration period
9. Target security requirement

If legacy readers and upgraded readers must operate during the same transition period, MIFARE Plus EV2 deserves particular attention because migration is one of its core use cases.

If you are replacing the entire architecture and do not need Classic-oriented migration behavior, compare that approach directly with a DESFire-based redesign rather than assuming Plus is automatically required.

Common MIFARE Selection Mistakes

Choosing the Lowest-Priced Chip First

Start with the application and system requirements. Unit price should be considered after compatibility, security and architecture.

Comparing Only Memory Size

A larger memory value does not automatically make one chip more suitable. File structure, authentication, reader support and application separation can be more important.

Assuming Every 13.56 MHz Credential Is Compatible

Frequency does not guarantee protocol, authentication, firmware or software compatibility.

Using Classic as the Default for a New System

Classic remains common in installed systems, but installed-base popularity and suitability for a new security-sensitive design are two different questions.

Ignoring Reader Firmware and Software

A capable contactless IC cannot deliver its intended functionality if the reader or system software does not support the required commands and security model.

Ignoring Key Management

A strong cryptographic feature does not automatically produce a secure system.

Default keys, poorly distributed keys, insecure personalization and weak back-end controls can undermine a technically capable credential.

Security is a system-level responsibility, not only a chip specification.

Ordering Mass Production Before Testing

Always validate real cards, readers, firmware, software and encoding before committing to large production quantities.

MIFARE or NTAG: Do You Actually Need MIFARE?

Not every 13.56 MHz project is really a MIFARE selection problem.

If the main objective is consumer smartphone interaction, such as opening a URL, sharing a digital profile, launching a review page or triggering a simple NFC action, a product from the NFC tag category may be a better fit.

For example, a simple smartphone-facing application may use an NTAG213 NFC card rather than a secure MIFARE access credential.

MIFARE becomes more relevant when the system involves controlled access, dedicated readers, authentication, ticketing, stored value or structured smart-card applications.

The better question is not:

Which RFID chip is best?

It is:

Which chip matches the application, reader, security requirement, system architecture and credential lifecycle?

What Should You Send Your RFID Supplier Before Requesting a Quote?

A supplier can make a more accurate recommendation when the technical requirement is clear.

Prepare the following information:

1. Application: access, ticketing, hotel, transport, loyalty, membership or another use
2. Current reader manufacturer and model: if the system already exists
3. Current card or chip model: especially for replacement or migration projects
4. Required security level: including what threats the system must address
5. Data requirement: what actually needs to be stored on the credential
6. Application structure: one application or several
7. Smartphone requirements: whether mobile NFC interaction is needed
8. Physical format: card, wristband, key fob, ticket or another credential
9. Expected lifetime: one day, several months or multiple years
10. Quantity: sample quantity and expected production quantity
11. Personalization: printing, UID handling, encoding or other data requirements
12. Testing: reader and software validation required before production

If you cannot provide the exact chip model, send the existing credential sample together with reader and system details rather than guessing from appearance.

Final MIFARE Selection Checklist

• Define the application before selecting the chip.
• Define the actual security threat rather than using the word "secure" as a generic requirement.
• Confirm the exact reader, firmware and software environment.
• Determine what data actually needs to be stored.
• Decide whether one or several applications are required.
• Confirm whether smartphone NFC interaction matters.
• Match the IC to credential lifetime and physical format.
• Compare total system cost, not just chip price.
• Separate legacy compatibility requirements from new-system requirements.
• Test real samples before mass production.

If you are building a new system, do not choose the credential in isolation.

If you are upgrading an existing system, begin with compatibility and migration requirements.

And if you are still unsure between MIFARE Classic, Plus, DESFire, Ultralight or another contactless IC, provide the supplier with your reader model, current credential, application and security requirement first. Those details are far more useful than simply asking for "the best MIFARE chip."