Chip Types We Offer
NFCKEY is available with multiple NXP chip types because different systems require different levels of security, memory, and programmability. Use this guide to understand and narrow down suitable chip options based on your use case.
Single Application Technology
Optimized for single-application use, these chips provide reliable and cost-efficient performance
NXP MIFARE® Classic
NXP MIFARE® Classic
Classic EV1 — 1K
- Memory: 1 KB
- Structure: 16 sectors
- UID: 4-byte or 7-byte
- Security: Crypto-1 (legacy)
Classic EV1 — 4K
- Memory: 4 KB
- Structure: 40 sectors
- UID: 4-byte or 7-byte
- Security: Crypto-1 (legacy)
Classic EV1 — 1K and 4K
- Access control credentials in systems based on MIFARE® Classic
- Transport, event, and ticketing deployments where Classic readers are already in use
- Loyalty and membership programs built on existing Classic infrastructure
Classic EV1 — 1K and 4K
- Desktop RFID / NFC writers
- System-managed enrollment
- Not programmable by smartphone
- Based on legacy Crypto-1 security
- Widely deployed in existing systems
- Used where Classic reader compatibility is required
- UID length must match the original credential
NXP NTAG®
NXP NTAG®
NTAG® 213 / 215 / 216
- Memory: 144 / 504 / 888 bytes
- UID: 7-byte
- Data format: Standard NDEF
- Security: Basic (password protection)
NTAG® 223 DNA / 224 DNA / 424 DNA
- Memory: 144 / 208 / 256 bytes
- UID: 7-byte
- Security: AES-128
- Authentication: Secure Unique NFC (SUN), dynamic messaging
NTAG® 213/215/216
- Digital business cards
- Marketing links
- IoT tap interactions
- Profile sharing
- Brand engagement
- General NFC content
NTAG® DNA line
- Anti-counterfeit checks
- Secure authentication
- Event ticket verification
- Brand protection
- Loyalty interactions
NTAG® 213/215/216
NTAG® DNA line
- Secure NFC/RFID encoders
- Backend SUN platforms
- Requires issuer enrollment
- Phone alone not sufficient
- Modern phones support NTAG® 213 / 215 / 216 natively
- DNA variants provide cloning resistance through dynamic authentication
- Access or transport use depends on system configuration and must be confirmed by the system operator
- Refer to NXP documentation for full technical details
NXP ICODE®
NXP ICODE®
ICODE® 3
- Memory: 304 bytes
- UID: 8-byte
- Improved performance over earlier ICODE generations
- Newer-generation ICODE® chip
ICODE® DNA
- Memory: 256 bytes
- UID: 8-byte
- Security: AES-128
- Authentication: DNA secure messaging
ICODE® SLIX2
- Memory: 320 bytes
- UID: 8-byte
- Frequency: 13.56 MHz (HF RFID)
- Optimised for extended HF RFID read range and fast inventory
ICODE® 3
- Asset identification and tracking systems
- Industrial and enterprise RFID deployments
- Event and hospitality environments
- Education and healthcare asset systems
- Badge-based identification and access workflows
ICODE® DNA
- Brand protection and product authentication systems
- Secure asset identification
- Event, hospitality, and enterprise environments requiring authenticated identification
- Healthcare and education systems requiring verified credentials
- Identification-based access systems with encrypted tag authentication
ICODE® SLIX2
- Asset and inventory tracking systems
- Industrial and supply-chain applications
- Event and logistics environments
- Education and campus asset systems
- Identification-based access systems (e.g. staff or visitor badges)
ICODE® 3
- Programmed using HF RFID readers and encoders
- Data written and managed through backend or enterprise software
- Typically configured during system enrollment
- Not intended for end-user smartphone programming
ICODE® DNA
- Programmed using secure HF RFID readers and encoders
- Requires backend platforms supporting DNA / AES authentication
- Secure keys and configuration managed by the system operator
- Smartphone alone is not sufficient
ICODE® SLIX2
- Programmed using HF RFID readers and encoders
- Supports fast writing and inventory-based operations
- Managed through industrial or logistics software platforms
- Not designed for consumer phone-based programming
- ICODE® chips are designed for reader-based HF RFID systems (ISO/IEC 15693), not phone-centric NFC interactions
- Some ICODE® tags may be readable by NFC-enabled phones for basic inspection (e.g. UID or chip type), but phones are not intended as the primary interface
- Programming, configuration, and system logic are handled by dedicated RFID readers and backend systems
- ICODE® DNA adds cryptographic authentication for applications requiring secure verification
- Actual functionality depends on the reader infrastructure and system implementation
- Refer to NXP documentation for detailed technical specifications
NXP MIFARE® Ultralight
NXP MIFARE® Ultralight
MIFARE® Ultralight AES
- Memory: 144 bytes
- UID: Manufacturer-programmed 7-byte UID
- Security: AES-128 cryptographic authentication
MIFARE® Ultralight EV1 — 48B / 128B
- Memory: 48 bytes / 128 bytes
- UID: Manufacturer-programmed 7-byte UID
- Security:
- 32-bit password protection for memory operations
- 32-bit user-definable One-Time Programmable (OTP) area
- Page-level read-only locking
- No cryptographic authentication
MIFARE® Ultralight AES
- Transport ticketing systems requiring authenticated taps
- Sport and event ticketing with secure validation
- Deployments where ticket authenticity verification is required
- Systems where tickets are validated using encrypted challenge–response checks
MIFARE® Ultralight EV1 - 48B / 128B
- Transport ticketing systems
- Sport and large-scale event ticketing
- Short-lifecycle, disposable credentials used within backend-controlled systems
- High-volume ticketing deployments (e.g. single-ride or day-pass tickets)
MIFARE® Ultralight AES
- Programmed using secure NFC / RFID readers
- Requires backend systems supporting AES authentication
- Cryptographic keys and configuration managed by the system operator
- Smartphone alone is not sufficient
MIFARE® Ultralight EV1 - 48B / 128B
- Programmed using NFC / RFID readers or writers
- Data written and managed by the issuing ticketing system
- Typically programmed during ticket issuance
- Not intended for end-user smartphone programming
- Ticket validity and reuse rules are enforced by the reader and backend, not by the chip alone
- Ultralight EV1 and Ultralight AES share similar form factors but differ in authentication capability
- Feature availability depends on reader compatibility and system configuration
- Refer to NXP documentation for detailed technical specifications and implementation guidance
Smart-City Ready Technology
Optimized for multi-application use, these chips enable shared credentials across access, transport, identity, and mobility systems
NXP MIFARE® DUOX
NXP MIFARE® DUOX
MIFARE® DUOX — 2K / 4K / 8K / 16K
- Memory options: 2 KB / 4 KB / 8 KB / 16 KB
- UID: Manufacturer-programmed 7-byte UID
- Security:
- Combination of symmetric (AES) and asymmetric cryptography
- Designed to support secure authentication and credential verification
- Secure key storage and protected memory access
- Evaluated to high security assurance levels (EAL-class certification, product-dependent)
EV version available by request
MIFARE® DUOX — 2K / 4K / 8K / 16K
- Secure access control systems
- Automotive and vehicle-related access
- Mobility and transport-related identification systems
- EV charging and e-mobility infrastructure
- Loyalty and membership credentials
- Deployments requiring strong authentication and long credential lifecycle
MIFARE® DUOX — 2K / 4K / 8K / 16K
- Programmed using secure NFC / RFID readers
- Requires backend systems supporting cryptographic key management
- Configuration and application setup performed by the system operator
- Not intended for end-user smartphone programming
- MIFARE® DUOX is designed for multi-application and high-assurance environments
- Supports advanced security concepts combining symmetric and asymmetric cryptography
- Intended for systems requiring secure credential verification
- Feature availability depends on reader compatibility, firmware, and system design
- Refer to official NXP MIFARE® DUOX documentation for detailed security architecture and certification scope
NXP MIFARE® DESFire®
NXP MIFARE® DESFire®
MIFARE® DESFire® EV3 - 2K / 4K / 8K / 16K
- Memory options: 2 KB / 4 KB / 8 KB / 16 KB
- UID: Manufacturer-programmed 7-byte UID
- Security:
- AES-128 cryptographic authentication
- Secure messaging and encrypted communication
- Application- and file-based memory structure
- Supports multiple applications on a single credential
MIFARE® DESFire® Light
- Memory: 640 bytes
- UID: Manufacturer-programmed 7-byte UID
- Security:
- AES-based cryptographic authentication
- Designed for secure, system-managed deployments where a single primary application is sufficient
- Secure messaging and protected data access
EV2 available by request
MIFARE® DESFire® EV3 - 2K / 4K / 8K / 16K
- Access control systems
- Public transport and mobility systems
- Loyalty and membership credentials
- Hospitality and service environments
- Identity-related credentials
- Multi-application secure credentials
MIFARE® DESFire® Light
- Access control systems
- Transport and mobility systems
- Service credentials
- Single-application secure deployments
MIFARE® DESFire® EV3 - 2K / 4K / 8K / 16K
- Programmed using secure NFC / RFID readers
- Requires backend systems supporting AES authentication
- Applications, files, and keys managed by the system operator
- Supports complex, multi-application configurations
- Not intended for end-user smartphone programming
MIFARE® DESFire® Light
- Programmed using secure NFC / RFID readers
- Configuration managed by the issuing system
- Intended for controlled, system-level deployment
- Not intended for end-user smartphone programming
- Security, access rules, and lifecycle management are enforced by the reader and backend system
- Supported features depend on reader compatibility, firmware, and system configuration
- Refer to NXP documentation for detailed technical specifications
NXP MIFARE® Plus
NXP MIFARE® Plus
MIFARE® Plus EV2 — 2K / 4K (4B / 7B UID)
- Memory options: 2 KB or 4 KB
- UID: Manufacturer-programmed 4-byte or 7-byte UID
- Security: AES-128 encryption
Includes migration modes for systems transitioning from MIFARE® Classic
MIFARE® Plus SE — 1K (4B / 7B UID)
- Memory: 1 KB
- UID: Manufacturer-programmed 4-byte or 7-byte UID
- Security: AES-128 encryption
MIFARE® Plus EV2 — 2K / 4K (4B / 7B UID)
- Access control systems
- Transport and mobility systems
- Loyalty and membership credentials
- Hospitality and service environments (HoReCa)
- Systems migrating from MIFARE® Classic to AES security
MIFARE® Plus SE — 1K (4B / 7B UID)
- Access control systems
- Transport and mobility systems
- Loyalty and membership credentials
- Hospitality and service environments (HoReCa)
- System-managed secure credentials
MIFARE® Plus EV2 — 2K / 4K (4B / 7B UID)
- Programmed using NFC / RFID readers and system software
- Configured and managed by system administrators
- Supports migration from MIFARE® Classic to AES-secured operation
- Not intended for end-user smartphone programming
MIFARE® Plus SE — 1K (4B / 7B UID)
- Programmed using NFC / RFID readers and system software
- Configured and managed by system administrators
- Operates directly in AES-secured mode
- Not intended for end-user smartphone programming
- Plus EV2 supports migration from legacy MIFARE® Classic systems, while Plus SE operates directly in AES-secured mode
- Actual security behavior depends on reader support, operating mode, and backend configuration
- UID length (4-byte or 7-byte) and available features depend on the specific chip variant
- Refer to official NXP documentation for detailed technical specifications and supported operating modes
NXP JCOP®
NXP JCOP®
Special Terms Apply
JCOP® ID 1 / JCOP® ID 2
- Platform: Java Card–based secure element
- Interface: ISO/IEC 14443 Type 4 (contactless)
- Memory: Platform- and configuration-dependent
- UID: Manufacturer-programmed UID (length platform-dependent)
- Security:
- Secure execution environment for Java Card applets
- Hardware-backed cryptographic key storage
- Cryptographic operations performed within the secure element
- Designed to meet high security assurance requirements - Functionality defined by installed and certified applets
JCOP® PAY
- Platform: Java Card–based secure element
- Interface: ISO/IEC 14443 Type 4 (contactless)
- Memory: Platform- and configuration-dependent
- UID: Manufacturer-programmed UID (length platform-dependent)
- Security:
- Secure execution environment for payment and financial applets
- Hardware-backed cryptographic key storage
- Designed to meet payment and scheme security requirements - Subject to payment-scheme certification and issuer configuration
JCOP® ID 1 / ID 2
- Secure identity and identification credentials
- Access control and secure authentication systems
- Government, enterprise, and institutional credentials
- Applications requiring a programmable secure element
JCOP® PAY
- Payment and micropayment credentials
- Secure financial applications
- Payment-related authentication and transaction systems
JCOP® (all variants)
- Programmed using Java Card–compatible tools and environments
- Applets installed and managed by authorized issuers or system operators
- Requires secure key management and controlled provisioning
- Not intended for end-user smartphone programming
- Deployment typically subject to issuer, scheme, or certification requirements
- Functionality depends on installed applets, configuration, and certification scope
- Use and availability may be subject to special commercial and contractual terms
- Deployment often requires coordination with issuers, system providers, or payment schemes
- Refer to official NXP JCOP® documentation for platform details, certifications, and compliance requirements
Important Notice
This page is intended as general informational guidance to help you understand the different NFC and RFID chip types NFCKEY offers.
- Technical specifications, capabilities, and limitations are defined by the manufacturer. For full and authoritative details, always refer to the official documentation on the NXP Semiconductors website.
- Compatibility with access, transport, ticketing, or other systems must be confirmed with your system provider, system administrator, or through testing.
- When replacing an existing card or credential, the chip type must match the system requirements. Incorrect chip selection may result in incompatibility.