MIFARE Plus S 2K Cards

Specify MIFARE Plus S 2K precisely

Ordering from an existing specification? Keep the variant name: MIFARE Plus SE, S, X, EV1 and EV2 identify different chips. This page prioritises S 2K enquiries and compares the family below. An SE requirement must not be replaced with S 2K simply because both are called MIFARE Plus. Send the approved part or card specification when checking availability.

The MIFARE Plus family: SE, S, X, EV1 and EV2

MIFARE Plus is a family, not a single chip. The variants share the ISO/IEC 14443 Type A air interface and open-standard AES-128 cryptography, but differ in memory and in which security levels they support. Memory and security levels below are from NXP; the exact part must still be named and approved for your order.

SL0 is the initial delivery configuration used for personalisation. SL2 — AES authentication combined with MIFARE Classic Crypto1 data confidentiality — is specific to MIFARE Plus X; the SE, S, EV1 and EV2 products move directly between SL1 and SL3. Every generation is offered with a 7-byte UID or a 4-byte NUID. Because an order for S 2K should not silently become an EV2 order, the offered part is named and approved before the order is agreed.

S 2K, S 4K and later Plus generations

For a new project or a supply alternative, ask the integrator to evaluate the current Plus generation. The offered part must be named and approved; an order for S 2K should not silently become an EV2 order. Compare MIFARE DESFire cards if the project instead requires an application/file model.

What to send for an S 2K quotation

• The required S 2K part or existing approved card specification, quantity and whether alternatives are acceptable.
• Reader and software details, UID requirement and intended delivery security level.
• Blank or personalised delivery, with an agreed separate process for sensitive key handling.
• Card size, material, artwork and numbering; delivery destination and target date.

S 2K sample approval

1. Confirm that the offered sample is the approved S-generation chip and 2 kB memory option.
2. Verify the UID and delivery state expected by your issuing software.
3. Complete enrolment, authentication and the intended transaction with the installed reader.
4. If a migration is planned, test it on dedicated samples under the integrator’s procedure before applying it to an order.
5. Approve the print and physical specification, and record the accepted part for repeat orders.

Related product: MIFARE Classic cards. Browse all RFID cards for other credential technologies.

Primary references: NXP MIFARE Plus family, MIFARE Plus S lifecycle information, the MIFARE Plus X fact sheet, MIFARE Plus SE, and MIFARE Plus EV2 with its fact sheet. Chip documentation describes IC capabilities; it does not establish stock or a finished card's compatibility with your system.

SL1 and SL3: what the system must support

For MIFARE Plus S, SL1 provides a MIFARE Classic-compatible operating mode. SL3 uses AES-based authentication and protected communication over ISO/IEC 14443-4. Moving to SL3 requires a reader and application that implement the required commands and key handling. The security-level change proceeds to a higher level and cannot be reversed.

Compatibility mode does not prove that an installed reader will accept every S 2K card. UID handling, reader timing, data layout and personalisation must be checked with the actual system. Approve the sample in the delivery state intended for your order.

Migration path: MIFARE Classic to Plus SL1 to SL3

MIFARE Plus is designed as the upgrade path from MIFARE Classic. A card is delivered in SL0, the personalisation state, then committed to a working security level. In SL1 it behaves like a MIFARE Classic 1K or 4K card using the Crypto1 command set, which can support a staged migration after the exact chip, UID handling, data layout and reader firmware have been qualified. Issuing a different chip alone does not establish compatibility. When the readers and application are ready, the card is switched to SL3, where AES-128 is mandatory for authentication, communication confidentiality and integrity over ISO/IEC 14443-4. The security-level change only ever moves upward and cannot be reversed, so agree the delivery state before personalisation.

On MIFARE Plus EV2 the SL1SL3MixMode lets sectors migrate from Crypto1 to AES individually, at sector or chip level, so a system can move one application at a time rather than all at once. Whichever generation you specify, treat the move from SL1 to SL3 as a change to the approved configuration and test it on dedicated samples with the production readers first. For the Classic starting point, see the MIFARE Classic card; for a new AES-only system, compare MIFARE DESFire cards.

MIFARE Plus or MIFARE DESFire: choosing the card family

MIFARE Plus and MIFARE DESFire are NXP's two mid- to high-security 13.56 MHz families. Both use the ISO/IEC 14443 Type A air interface and AES-128, but they are built around different memory architectures and solve different problems. Plus is the sector-based upgrade path from MIFARE Classic; DESFire is a file-system chip designed for credentials that carry several independent applications. Choose the family by architecture first, then name the exact part. The table below sets the two families side by side on the dimensions that usually decide the specification.

Which family to choose usually follows from the reader estate, the number of applications, the volume and any certification requirement:

• Choose MIFARE Plus when there is a meaningful MIFARE Classic reader estate to migrate. SL1 lets you reissue cards first and move readers to SL3 AES afterwards, one device at a time, rather than a single-step cutover.
• For volume deployments, compare quotations for the approved chip, construction and personalisation on the same basis. The family name alone does not determine the finished-card price.
• Choose MIFARE DESFire for a new build whose credential must carry several independent applications — for example badge, canteen and print quota — under chip-enforced key separation.
• Choose MIFARE DESFire where the information-security requirements call for the file-level access model or a specific hardware certification; confirm the required certification from the buyer's own specification, not from assumption.
• Where both patterns exist, a reader fleet that implements both command sets can carry Plus and DESFire cards together; confirm the reader firmware supports both before mixing them.

Within the Plus family, EV1 dropped the SL2 mode and retained the proximity check that Plus X had introduced; EV2 added SL1SL3MixMode for per-sector migration, Transaction MAC and a Transaction Timer. Both EV1 and EV2 hold Common Criteria EAL5+. Whichever family and generation you specify, name the exact part and approve it on samples with the production readers before the order — an S 2K requirement should not become an EV2 or a DESFire order without your integrator's approval. For the file-model alternative see MIFARE DESFire cards; for a hospitality deployment weighing Classic, Plus and DESFire locks see hotel key cards.