RFID Key Fobs and Readers for EV Charging Stations
Almost every charger identifies the driver before it delivers power. A key fob, a card or a phone is presented, the charger decides whether that credential may start a session, and the backend records who drew how much energy. The credential is the cheapest item in that chain and the easiest one to specify badly.
This page is written from the reader side. Ambimat Electronics designs and manufactures contactless reader hardware in India — the AmbiTap NFC Reader Module that goes inside the charger, and the AmbiPay reader platform where a charger has to authenticate a credential rather than only read it. The fobs and cards themselves come from credential manufacturers and card bureaux; Ambimat’s products here are the readers. What follows is how to choose a credential so that the reader you deploy can do its job.
Choosing an RFID key fob or card for EV charging
Form factor. A fob on a keyring, a card in a wallet and a phone in a pocket do the same job with different trade-offs. Fobs survive a wet forecourt better than printed cards and are cheap to replace when a driver loses one. Cards carry branding, a photograph and a printed serial, which matters when the same credential doubles as a building pass. A phone removes credential logistics and replaces it with an app, a backend and an operating-system dependency.
Deployment environment. A forecourt reader sits outdoors behind a fascia, in sun, rain and cold, and is tapped tens of thousands of times. Ask for the credential’s temperature and ingress ratings, not only its chip type. The mounting arrangement matters at least as much: metal close to a 13.56 MHz antenna detunes it, and a bezel that looks right can put the tap point away from the coil. Settle the enclosure and the reader position together, not one after the other.
What the chip actually proves. This is the decision most often skipped. Every ISO/IEC 14443 credential answers a reader with a UID, a serial number it will transmit to anything that asks. A charger that starts a session on the strength of a UID alone is performing identification, not authentication, and a UID can be written onto a programmable card in seconds. Reading a key-protected file, or running a mutual cryptographic authentication against the credential, is a different operation, and it requires key material on the reader side as well. That difference is set out in why reading an RFID UID is not authentication, and it is worth understanding before a network is rolled out rather than after.
Credential family. MIFARE is the usual shortlist for access-style EV credentials, and the families are not interchangeable. MIFARE Ultralight is a low-cost, low-security token suited to disposable or low-risk use. MIFARE Classic is cheap and very widely deployed, but its proprietary cipher is broken and it should not be relied on where the credential itself has to resist attack. MIFARE Plus and MIFARE DESFire use AES and a real authentication protocol, and are what a scheme should specify when the tap has to prove something. There is a guide to the MIFARE families and an overview of MIFARE as a technology elsewhere on this site.
Reader compatibility. A credential is only as useful as the reader’s support for it. Confirm the air interface (ISO/IEC 14443 Type A or Type B, ISO/IEC 15693), confirm the family, and — if you intend to authenticate rather than identify — confirm that the reader can hold the keys and run the protocol. That last point is where hardware Secure Access Module slots or a secure element stop being a bullet on a datasheet and become a specification.
Credential lifecycle. Credentials are lost, shared, cloned and left behind when a tenant moves out. Decide in advance how one is issued, associated with a user record, blocked and re-issued, and who holds the keys when the credential is a keyed one. A charging network’s real security posture is usually set by these procedures rather than by the reader.
How RFID authorisation works in a charging station
The reader is a peripheral of the charger, not an independent device on the network. A typical implementation looks like this:
- A contactless reader is mounted behind the charger fascia and wired to the charger’s own controller.
- Each authorised driver — tenant, employee, student, fleet user, subscriber — is issued a credential that is associated with a user record in the operator’s backend.
- The driver presents the credential. The reader returns what it read to the controller.
- The controller asks the backend whether that credential may charge; in most public networks that request travels as an authorisation message over OCPP, and a local list is used when the link is down.
- On approval the controller energises the outlet, meters the session and attributes the energy to that user for billing.
What the reader returns in step three is the whole question. A UID supports identification and convenience. A cryptographically authenticated result supports a claim that the credential presented is genuine. Both are legitimate designs; they are not equivalent, and the choice belongs at the start of the project.
What RFID gives a charging network
- A quick, repeatable way for a driver to start a session without an app, an account login or an attendant.
- Access control over a charger that is physically reachable by anyone — in a car park, a campus or a residential building.
- Attribution: which credential started which session, for how long, and how much energy it drew, which is what automated billing depends on.
- Usage data per user and per charger, without manual record keeping.
- A contactless interaction with no moving parts and nothing to wear out on the user-facing surface, which suits unattended outdoor equipment.
None of this is automatic. Access control is only as strong as the credential and the authentication behind it, and billing integrity depends on the backend that owns the user records.
The reader side: what has to be true inside the charger
AmbiTap NFC Reader Module. AmbiTap is a 42 mm × 42 mm contactless reader module built on the NXP CLRC66303HNY NFC frontend, designed and manufactured in India for EV chargers and other embedded OEM equipment. It is host-controlled: the module exposes SPI, UART and I²C-style multifunction signals plus IRQ and power-down control on a ten-way group, and the charger’s own controller keeps the application logic. It is reader hardware inside a system, not a certified payment terminal. For the credential families a specific application has to work with, talk to Ambimat engineering — module-level protocol support is confirmed per application rather than published as a blanket list.
AmbiPay reader platform. Where the requirement is broader, AmbiPay is Ambimat’s finished-reader platform. The AmbiPay Secure NFC Reader is designed for an NFC reading range of approximately 7–10 cm — credential, antenna, orientation and installation dependent, never a guaranteed figure — works to ISO/IEC 14443 Type A and Type B, ISO/IEC 15693, ISO/IEC 18000-mode 3 and ISO/IEC 18092, reads the MIFARE Ultralight, Classic, Plus and DESFire EV1/EV2 families and Sony FeliCa, and takes up to five hardware SAM slots that hold the scheme keys with secure MIFARE key storage.
Hardware SAM slots are what make cryptographic authentication practical at the reader instead of a design aspiration. They do not, on their own, make a charging network secure: the credential family, the key management, the charger firmware and the backend all still have to hold up. The reader is one layer of that, and it is the layer Ambimat builds.