Product News
How to Choose the Right RFID Chip for a Smart Card Project
How to Choose the Right RFID Chip for a Smart Card Project
Choosing an RFID chip for a smart card project is not simply a matter of selecting the chip with the largest memory or highest security level. The correct choice depends first on the reader infrastructure, frequency, communication protocol, security requirements, application architecture, and whether the project is a legacy replacement, a migration program, or a completely new deployment.
For a new high-security smart card project, MIFARE DESFire EV3 is generally a stronger starting point than MIFARE Classic because it is designed for secure, multi-application deployments. For projects that must transition from an existing MIFARE Classic infrastructure, MIFARE Plus can provide a migration path. NTAG is usually better suited to NFC and NDEF-based applications, while ICODE is aimed at ISO/IEC 15693 vicinity applications. UCODE belongs to the UHF RAIN RFID ecosystem and should be considered when long-range, multi-tag identification is required rather than conventional 13.56 MHz smart card interaction.
The key principle is simple:
Choose the RFID technology that fits the complete system, not just the card.

Start With the System, Not the Chip
Before selecting a chip, identify the RFID architecture already used or planned for the project.
The first questions should be:
·What frequency does the reader use?
·Which RFID protocol does it support?
·Is the project based on an existing card system?
·Does the reader require MIFARE Classic compatibility?
·Is card authentication required?
·Does the application need one function or multiple independent applications?
·Does the card need to interact with smartphones?
·Is long-range reading required?
·Will the cards be produced and encoded in large quantities?
These questions often eliminate unsuitable chip families before detailed chip comparison even begins.
Legacy systems
A legacy system should normally be treated as a compatibility project rather than a blank-sheet design.
For example, NXP states that MIFARE Classic EV1 is not recommended for new designs and recommends MIFARE DESFire Light instead. However, an installed MIFARE Classic reader environment may still make compatibility a practical requirement.
This means:
An existing system may justify retaining or migrating from a legacy technology even when that technology is not the preferred choice for a new project.
Migration projects
Migration projects have a different priority.
The goal is usually to keep existing infrastructure working while improving security or preparing for a future architecture.
MIFARE Plus is specifically positioned for this type of transition. MIFARE Plus EV2 supports a security-level concept that enables migration from legacy MIFARE-based infrastructure toward AES-128 security, while retaining compatibility features for existing environments.
New projects
A new project should not automatically reproduce the technology used by an older system.
For new high-security applications, modern secure architectures should be evaluated first. NXP’s current product information positions MIFARE DESFire EV3 as a secure multi-application contactless IC, while DESFire EV2 is marked as not recommended for new designs with EV3 identified as the replacement.
That distinction is critical for procurement teams:
“Compatible with the old system” and “recommended for a new system” are two different questions.
The Main RFID Chip Families Used in Smart Card Projects
Different RFID chip families solve different engineering problems.
MIFARE
MIFARE is a broad 13.56 MHz contactless smart card family. Depending on the product, MIFARE solutions can address access control, transportation, loyalty, identification, and other card-based applications.
MIFARE Classic is strongly associated with legacy deployments and existing installed infrastructure. NXP currently marks MIFARE Classic EV1 as not recommended for new designs.
MIFARE Plus
MIFARE Plus is particularly relevant when a project needs to move from an existing MIFARE Classic environment toward stronger security.
MIFARE Plus EV2 supports AES-128 security and a migration architecture intended to help existing infrastructures move toward higher security levels. MIFARE Plus SE is also designed for compatibility with MIFARE Classic 1K environments and can introduce AES-ready credentials into existing systems.
MIFARE DESFire
MIFARE DESFire is intended for secure, flexible smart card applications where authentication, secure messaging, and multi-application functionality matter.
The DESFire family supports ISO/IEC 14443-based contactless communication and is designed for applications including identity, access control, loyalty, micropayment, and transportation. DESFire EV3 provides support for AES-based cryptography, multiple applications, flexible file structures and advanced security features.
For new projects requiring strong security and application separation, DESFire deserves evaluation early in the design process.
NTAG
NTAG 213, NTAG 215 and NTAG 216 are NFC Forum Type 2 Tag compliant ICs designed for 13.56 MHz ISO/IEC 14443 Type A applications.
Their available user memory differs:
IC | User Memory |
NTAG 213 | 144 bytes |
NTAG 215 | 504 bytes |
NTAG 216 | 888 bytes |
NXP positions these chips for applications such as smart advertising, product authentication, NFC interaction, digital information and mobile companion applications.
NTAG is therefore often a better fit when the card’s main function is:
·NFC interaction
·URL or NDEF storage
·smartphone interaction
·digital business cards
·product information
·lightweight authentication or engagement
An NTAG card should not automatically be treated as a replacement for a secure DESFire credential.
ICODE
ICODE products use the 13.56 MHz band but are based on ISO/IEC 15693 rather than the same architecture used by conventional ISO/IEC 14443 smart card applications.
For example, NXP’s ICODE SLIX-L is designed for smart-label applications and supports ISO/IEC 15693 and ISO/IEC 18000-3. Depending on the antenna and operating conditions, NXP specifies operation distances up to approximately 1.5 m.
ICODE can therefore be attractive for applications such as:
·library identification
·smart labels
·item identification
·asset tracking
·document management
·applications where longer HF operating distance is useful
The important point is that ICODE is not simply “MIFARE with longer range.” The reader ecosystem and communication architecture are different.
UHF / UCODE
UHF RAIN RFID belongs to a different RFID architecture again.
NXP’s UCODE family is built around GS1 EPC Gen2v2 / RAIN RFID standards and is intended for applications such as retail, supply chain logistics, healthcare and industrial identification. Current UCODE products include UCODE 9 and UCODE X.
UHF should be considered when the project requires:
·longer read distances
·rapid inventory
·reading many tags
·logistics identification
·supply chain tracking
·item-level identification
A UHF card can have the physical form factor of a card, but the reader infrastructure and system architecture are different from a conventional 13.56 MHz NFC/MIFARE smart card.
MIFARE vs DESFire vs NTAG vs ICODE vs UHF
Technology | Typical Frequency | Main Architecture | Typical Strength | Typical Applications |
MIFARE Classic | 13.56 MHz | ISO/IEC 14443 Type A | Legacy compatibility | Existing access, transport |
MIFARE Plus | 13.56 MHz | ISO/IEC 14443 | Security migration | Legacy upgrades, access, transport |
MIFARE DESFire | 13.56 MHz | ISO/IEC 14443 / secure application architecture | High security, multi-application | Access, ID, transport, payment |
NTAG 213/215/216 | 13.56 MHz | NFC Forum Type 2 | NFC / NDEF interaction | Mobile interaction, marketing, product information |
ICODE SLIX family | 13.56 MHz | ISO/IEC 15693 | Vicinity identification | Labels, libraries, asset identification |
UCODE / RAIN RFID | 860–960 MHz | EPC Gen2v2 | Long range / multi-tag reading | Inventory, logistics, supply chain |
The comparison should not be interpreted as a simple ranking.
There is no universal “best RFID chip.”
The correct chip depends on the system architecture and the business requirement.
How to Choose Based on Frequency and Reader Compatibility
Frequency should be the first technical filter.
A 13.56 MHz chip cannot simply be substituted into a UHF reader system because both systems use RFID.
Likewise, two 13.56 MHz chips may still be incompatible at the application layer.
For example:
·MIFARE Classic uses one memory/security architecture.
·DESFire uses a different application and file architecture.
·NTAG is designed around NFC Forum Tag functionality.
·ICODE uses ISO/IEC 15693.
·UCODE uses UHF RAIN RFID protocols.
Therefore, checking the frequency alone is not enough.
Check these compatibility points
Before ordering samples, confirm:
Reader hardware
Which reader IC, reader model and antenna are being used?
Protocol
Does the reader support the protocol used by the selected card?
Application commands
Does the software expect sector/block commands, DESFire application commands, or NFC NDEF records?
Authentication
Does the system depend on Crypto-1, AES authentication, passwords or another security mechanism?
UID handling
Does the backend identify the card using the UID, or does it use application-level data?
Data structure
Does the application expect sectors and blocks, files and applications, or NDEF records?
Mobile compatibility
Does the card need to be read by smartphones?
A card that is electrically compatible may still fail at the software or credential layer.
How Much Memory Do You Need?
Memory should be selected based on the data model rather than simply choosing the largest available capacity.
Small NFC data
If the card stores a short URL, contact information or a simple NDEF record, a small NTAG may be sufficient.
NTAG 213, 215 and 216 provide 144, 504 and 888 bytes of user memory respectively.
Structured credential data
A secure access credential may require more than raw memory capacity.
The design may need:
·multiple applications
·multiple files
·access permissions
·authentication keys
·secure messaging
·transaction protection
This is where DESFire’s application-oriented architecture becomes more important than simply counting bytes.
Inventory identification
For UHF applications, the important memory areas may include:
·EPC
·TID
·user memory
·access password
·kill password
The selection should be based on how the RFID infrastructure manages item identification and inventory operations rather than comparing memory capacity with an HF smart card. UCODE products use the EPC Gen2v2 ecosystem for this type of deployment.
How Much Security Do You Need?
Security is one of the most common reasons for choosing the wrong RFID technology.
A project should distinguish between:
Identification
The card simply provides an identifier.
Basic data protection
The card protects selected memory or data through simple controls.
Mutual authentication
The reader and card verify each other before sensitive operations.
Encrypted communication
Data exchanged over the RF channel is protected.
Multi-application security
Different applications have separate access rights and keys.
For high-security applications, modern cryptographic architectures should be evaluated instead of assuming that any RFID card provides sufficient security.
MIFARE DESFire products support cryptographic mechanisms including AES, while MIFARE Plus provides a migration route toward AES-based security for compatible legacy environments.
Which RFID Chip Should You Choose for Common Applications?
Access Control
For an existing MIFARE Classic-based access control system, compatibility may be the first requirement.
For a migration project, MIFARE Plus may be appropriate when the infrastructure needs a transition toward stronger security.
For a new high-security deployment, DESFire should be evaluated rather than automatically reproducing a legacy Classic architecture.
Hotel Key Cards
Hotel applications depend heavily on the installed locking system.
The card supplier should first confirm the lock brand, reader technology, card technology, encoding requirements and key management architecture.
The correct decision is therefore not simply “choose the most secure card.”
The card must be compatible with the hotel lock system and issuance workflow.
Employee ID Cards
Employee cards may have very different requirements.
A simple identification credential may require only an identifier, while a secure enterprise credential may require protected authentication and multiple functions.
For a new secure identity project, the security architecture should be specified before selecting the card body or printing process.
Membership Cards
Membership systems often need:
·member identification
·loyalty data
·NFC interaction
·mobile engagement
·access control
·transaction records
An NFC-oriented system may fit an NTAG architecture, while a system requiring secure multi-application credentials may be better suited to DESFire.
Transportation
Transportation projects have demanding requirements for speed, security and large-scale deployment.
MIFARE Plus and DESFire are particularly relevant to modern contactless transportation architectures, while existing deployments may still impose legacy compatibility constraints. NXP continues to document migration and multi-application approaches for transportation systems.
Product Authentication
For product authentication and customer interaction, NFC technologies such as NTAG can be attractive because smartphones can interact directly with NFC Forum-compatible tags.
For higher-security authentication requirements, secure NFC variants should be evaluated instead of assuming that a standard NTAG is sufficient.
Asset Tracking and Smart Labels
ICODE can be useful when the application is based on ISO/IEC 15693 vicinity operation.
It can be appropriate for:
·library items
·archives
·documents
·industrial assets
·smart labels
Inventory and Supply Chain
UHF RAIN RFID is often the more appropriate architecture when the system needs long-range identification and high-volume multi-tag reading.
NXP’s UCODE portfolio is designed around standards-based RAIN RFID and EPC Gen2v2 deployments.
What Changes When You Replace a Legacy RFID Card?
Replacing an RFID card should never be treated as a simple card-material change.
A migration project may affect:
·reader hardware
·firmware
·card authentication
·application software
·backend databases
·key management
·card encoding
·issuance equipment
·personalization
·field operation procedures
This is why a replacement card that “looks the same” may still fail in the actual system.
Example: MIFARE Classic migration
Suppose a customer has an installed MIFARE Classic infrastructure.
There are at least three possible approaches:
Continue the legacy technology
This may maximize compatibility but does not necessarily represent the preferred architecture for a new security design.
Move to MIFARE Plus
This can provide a migration path toward AES-based security while preserving compatibility-oriented characteristics of the existing ecosystem.
Redesign around DESFire
This can make sense when the project is ready to move to a more flexible, secure multi-application architecture.
The right decision depends on the infrastructure, software and business transition plan.
What Should You Test Before Bulk Production?
Never begin a large RFID card order based only on a datasheet.
A professional B2B project should validate the actual card construction and encoding process.
1. Reader compatibility test
Test the actual card on the actual reader.
2. Authentication test
Verify that authentication and key handling work correctly.
3. Data encoding test
Confirm that the required UID, sectors, applications, files, NDEF data or EPC data are encoded correctly.
4. Physical construction test
The antenna position, chip placement, material and lamination structure can affect RF performance.
5. Personalization test
Confirm that printed serial numbers, QR codes, barcodes and encoded data correspond correctly.
6. Environmental test
Where the card will be exposed to moisture, heat, bending, chemicals or other conditions, validate the finished card rather than relying only on chip-level specifications.
7. Production consistency test
Before mass production, check whether the first production batch performs consistently with the approved samples.
A manufacturer should be able to support sample evaluation and a pre-production approval process before volume manufacturing. This is especially important when cards are encoded or personalized in bulk.
RFID Card Manufacturing Considerations
The RFID IC is only one part of the finished smart card.
A production specification may include:
Manufacturing Factor | What to Confirm |
Chip | Exact IC family and model |
Frequency | 125 kHz, 13.56 MHz or UHF |
Protocol | Supported reader protocol |
Antenna | Design and tuning |
Material | PVC, PET, PETG, PC, paper, etc. |
Card size | CR80 or custom |
Thickness | Standard or custom |
Printing | Offset, digital, UV, laser, etc. |
Encoding | UID, memory, NDEF, application data, EPC |
Personalization | Numbering, QR, barcode, photo, variable data |
Packaging | Quantity per pack / project requirement |
Sampling | Engineering sample / production sample |
QC | RF and data verification |
Quantity | Pilot, batch or bulk order |
Delivery | Confirmed production lead time |
RFID cards that use the same IC can still behave differently when card construction, antenna design or reader conditions change.
That is why sample validation is valuable before committing to a large production run.
RFID Chip Selection Decision Tree
Use the following logic when starting a new project.
Do you already have RFID readers?
→ Yes
Start with reader and protocol compatibility.
→ No
Continue from application requirements.
Do you need long-range multi-tag reading?
→ Yes
Evaluate UHF / RAIN RFID.
→ No
Continue with HF/NFC options.
Does the project require smartphone NFC interaction?
→ Yes
Evaluate NTAG or NFC-capable secure smart card technologies.
→ No
Continue with the smart card architecture.
Is the system based on ISO/IEC 14443 smart cards?
→ Yes
Evaluate MIFARE, MIFARE Plus or DESFire according to compatibility and security.
→ No
Check whether ISO/IEC 15693 or another RFID architecture is more appropriate.
Is this a legacy MIFARE Classic environment?
→ Yes
Evaluate compatibility first, then consider MIFARE Plus migration or a larger system migration to DESFire.
→ No
For a new secure project, evaluate current DESFire options before selecting a legacy architecture.
Does the project require multiple applications and strong security?
→ Yes
Evaluate DESFire.
→ No
A simpler technology may be sufficient.
What Should You Ask an RFID Manufacturer Before Ordering?
A good RFQ should provide more than:
“Please quote 10,000 RFID cards.”
The manufacturer needs enough information to identify the correct card technology.
Provide:
1. Application
2. Reader model
3. Existing card/chip type
4. Frequency
5. Protocol
6. Required security level
7. Required memory
8. Data format
9. Encoding requirements
10. Card material
11. Card dimensions
12. Printing requirements
13. Personalization requirements
14. Quantity
15. Packaging requirements
16. Sample requirements
17. Delivery target
For example:
50,000 CR80 cards, 13.56 MHz, DESFire EV3, existing reader model XXX, encoded credentials required, custom CMYK artwork, variable numbering, sample approval required before bulk production.
That is much easier for a manufacturer to evaluate accurately than a generic request for an “RFID card.”
Frequently Asked Questions
What is the most important factor when choosing an RFID chip for a smart card?
The most important factor is compatibility with the complete RFID system. Start by checking the reader, frequency, communication protocol, security architecture, application requirements and data structure. A chip should not be selected based on memory capacity or price alone.
Should I use MIFARE Classic for a new RFID smart card project?
MIFARE Classic may still be relevant when compatibility with an existing system is required, but it should not automatically be selected for a new design. NXP currently marks MIFARE Classic EV1 as not recommended for new designs. For a new project, newer security architectures should be evaluated based on the application’s requirements.
What is the difference between MIFARE Classic and MIFARE DESFire?
MIFARE Classic is widely used in legacy contactless systems and is particularly relevant when compatibility with existing infrastructure matters. MIFARE DESFire is designed for more advanced secure applications, with features such as application separation, stronger cryptographic options and flexible data structures.
For a new high-security multi-application project, DESFire is generally a more appropriate technology to evaluate than MIFARE Classic.
When should I use MIFARE Plus?
MIFARE Plus is particularly relevant when an existing MIFARE Classic-based system needs a migration path toward stronger security. MIFARE Plus EV2 supports AES-128 security and is designed to support migration from legacy MIFARE infrastructure.
The key question is not simply whether MIFARE Plus is more secure, but whether it fits the existing reader, software and migration plan.
Is MIFARE DESFire EV3 suitable for new projects?
DESFire EV3 is designed for secure multi-application contactless applications and is a current option for new projects requiring stronger security and flexible application management. NXP identifies DESFire EV3 as the recommended successor to DESFire EV2 for new designs.
The final choice should still be based on the project’s reader infrastructure, security architecture, application requirements and implementation environment.
What is the difference between MIFARE and NTAG?
MIFARE products are generally associated with contactless smart card applications such as access control, identification, transportation and secure multi-application systems.
NTAG products are more commonly used for NFC applications involving NDEF data, smartphone interaction, URLs, digital information and product engagement.
The right choice depends on whether the project needs a secure smart card architecture or a simpler NFC interaction model.
When should I use ICODE instead of MIFARE?
ICODE is worth evaluating when the application is based on ISO/IEC 15693 and requires vicinity-style HF RFID operation, such as smart labels, libraries, asset identification or document tracking.
MIFARE is generally more appropriate when the application is based on the ISO/IEC 14443 smart card ecosystem.
The reader and software architecture should be confirmed before making the final selection.
When should I use UHF RFID instead of a 13.56 MHz RFID chip?
UHF RFID should be considered when the project requires longer read distances, rapid identification or simultaneous reading of many tags, such as inventory, logistics and supply chain applications.
13.56 MHz technologies such as MIFARE, DESFire, NTAG and ICODE are generally more suitable when the application involves close-range card interaction, NFC or HF smart card functionality.
UHF and 13.56 MHz RFID normally require different reader infrastructure and should not be treated as interchangeable technologies.
How do I know whether an RFID card will work with my existing reader?
First confirm the reader’s supported frequency, protocol, chip families, authentication methods and application commands.
You should also verify whether the existing system depends on specific UID behavior, memory structures, keys, sectors, applications, files or NDEF records.
The safest approach is to test actual card samples on the actual reader and software environment before approving bulk production.
How much RFID chip memory do I need?
The required memory depends on the application’s data structure.
A simple NFC application may require only enough memory for a short NDEF record, while a secure smart card may require multiple applications, files, permissions and credential data.
For NTAG 213, NTAG 215 and NTAG 216, the available user memory is 144, 504 and 888 bytes respectively. For DESFire-based projects, application architecture and security requirements are often more important than comparing raw byte capacity.
What should I test before ordering RFID cards in bulk?
At minimum, test:
·Reader compatibility
·Authentication
·Data encoding
·UID or credential handling
·Card antenna performance
·Printing and personalization
·Environmental durability where required
·Production consistency
For customized cards, approve representative samples before committing to volume production.
What information should I provide when requesting an RFID card quote?
A useful RFQ should include the application, existing reader model, RFID technology or chip requirement, frequency, security requirements, data or encoding requirements, card material, card size, artwork, personalization requirements, quantity, packaging and sample requirements.
The more technical information the manufacturer receives, the less likely the project is to experience compatibility problems during production.
Can the same RFID chip be used for every smart card application?
No. Different applications require different combinations of frequency, protocol, security, memory, reader compatibility and communication architecture.
For example, a chip suitable for NFC marketing may not be appropriate for secure access control, and a UHF chip designed for inventory tracking is not a direct replacement for a 13.56 MHz contactless smart card.
The chip should always be selected according to the complete project architecture.
Final Recommendation
The best RFID chip is not necessarily the newest chip, the cheapest chip, or the chip with the largest memory.
Use this decision logic:
Project Situation | Starting Point |
Existing MIFARE Classic infrastructure | Check compatibility first |
MIFARE Classic security migration | Evaluate MIFARE Plus |
New high-security multi-application card | Evaluate DESFire EV3 |
Lightweight single-application secure card | Evaluate DESFire Light |
NFC / NDEF / smartphone interaction | Evaluate NTAG |
HF vicinity / smart label applications | Evaluate ICODE |
Long-range inventory / logistics | Evaluate UHF / UCODE |
Unknown system | Obtain reader and protocol information before selecting the chip |
The most important procurement rule is:
Do not approve the chip until the reader, protocol, security architecture, data structure and finished-card construction have been validated together.
For bulk smart card projects, request samples first, verify interoperability with the real system, approve the encoding and personalization process, and only then move to mass production.
Need help selecting a chip for a specific smart card project? Request a Quote with your reader model, application, required security level, card quantity and encoding requirements so the card technology can be evaluated against the actual project conditions.
For project evaluation, you can also Get Samples before committing to a bulk order.

+86-13006626869
+86-(0)755-82619866
info@chinaiccard.com