Which RFID Chip Is Right for EV Charging? A Plain-English Guide

Most EV charging operators we talk to come in with the same question: "Which chip do we put in our cards?" It sounds technical, but it's really a procurement decision dressed up as an engineering one. The wrong chip costs you in security incidents and roaming rejections. The right chip costs you a few cents more per card and disappears into the background, which is exactly what good infrastructure is supposed to do.

This guide walks through the three RFID chip families that matter for EV charging, why one of them is no longer recommended for new deployments, and how to pick between the remaining two based on what your network actually needs.

The Three Chips You'll Be Asked About

Every conversation about RFID cards for EV charging eventually narrows down to three NFC chip families, all operating at 13.56 MHz on the ISO 14443A standard:

MIFARE Classic 1K / 4K

The original mass-market RFID chip. Cheap, fast to manufacture, and still produced in the tens of millions of units per year — mostly for hotel keycards, public transport, and access control. Classic uses a 4-byte UID and a proprietary CRYPTO1 cipher.

**Where it still makes sense:** hospitality, low-stakes building access, disposable event credentials.

**Where it no longer makes sense:** EV charging. We'll come back to why in the next section.

MIFARE Ultralight EV1

The "middle tier" of the family. Ultralight EV1 was designed to be more secure than Classic without the cost and provisioning overhead of DESFire. It supports 7-byte UIDs (the format Hubject and most modern roaming hubs now expect), has a 32-bit user-defined password, and authenticates fast enough that drivers don't notice a pause at the charger.

**Where it makes sense:** the majority of EV charging deployments in 2026. Octopus Electroverse, a wide range of regional CPOs, and most new roaming networks default to Ultralight EV1 unless they have a specific reason to go higher.

MIFARE DESFire EV2 / EV3

The high-security end of the family. DESFire uses AES-128 mutual authentication, supports multiple applications per card, and is genuinely hard to clone. It's what's underneath transit cards in major metros, payment wearables, and high-value corporate access.

**Where it makes sense:** networks with elevated fraud exposure (large roaming networks paying on each authenticated session), corporate fleets billing back to a parent company, or any deployment where a compromised card unlocks more than a single charge.

**The trade-off:** DESFire cards cost more per unit, the provisioning workflow is more involved, and the authentication round-trip at the charger is a few hundred milliseconds slower. None of these are dealbreakers — they're just things to know.

Why Classic Is No Longer the Default

For about a decade, MIFARE Classic was the default chip for most contactless deployments, including EV charging. That has shifted. The cryptography behind Classic (CRYPTO1) has been publicly broken for years, and the tooling required to exploit it has steadily become cheaper, smaller, and more accessible. What was once a research-grade attack is now within reach of off-the-shelf consumer hardware.

This matters for EV charging in a specific way. A cloned charging card doesn't just give someone a free charge — it gives them a free charge that bills to your customer's account, on a network you don't control, potentially in another country via a roaming partner. The dispute resolution is painful, the goodwill cost is real, and the per-incident fraud loss compounds across a roaming network of millions of sessions.

The practical guidance across the EV industry today is clear: do not deploy new charging credentials on MIFARE Classic. The chip itself still ships in volume for hospitality and event use — applications where the consequence of a clone is bounded. EV charging is not one of those applications.

What Hubject and Other Roaming Hubs Actually Receive

Roaming is the part of EV charging where chip choice has the most downstream consequence. When a card taps at a charger that belongs to a Charge Point Operator (CPO) outside your network, the flow is roughly:

The UID format is the part that trips operators up. The legacy MIFARE Classic UID is 4 bytes. Modern Ultralight EV1 and DESFire UIDs are 7 bytes. Hubject's OICP 2.3 specification accepts both 4-byte and 7-byte UIDs as well as 10-byte UIDs through its UIDType regex, and the RFIDType enum operates at the chip-family level rather than the part-number level — so the choice does not lock you out of roaming.

What does matter: be deliberate about UID length when you pick your chip, communicate the format to your roaming partners during integration, and confirm that your backend handles both lengths if you plan to issue cards on more than one chip family over time. Several operators we work with started on 4-byte Classic, migrated to 7-byte Ultralight EV1, and had to retrofit their database key length mid-flight. The fix is small if you catch it early; expensive if you find it during an interoperability incident.

A Quick Decision Matrix

If you're choosing a chip in 2026, here's a compressed version of how we'd think about it:

There is no "correct" answer that ignores your deployment. The right chip is the one that matches the security exposure of your sessions, the speed expectations at your chargers, and the roaming hubs you intend to integrate with.

What to Do Next

If you're sourcing cards for a deployment, the fastest way to make this concrete is to see and tap the actual chips. We send free sample packs containing all three chip families in real card form factors — recycled PVC, FSC wooden, and bio-based — so your engineering team can read the UIDs into your test backend before you commit to a production run.

Request a sample pack — ships in 7 days, no commitment, no sales call required. Or read how Octopus Electroverse scaled their roaming credential to see one operator's chip choice in context.