RFID Charging Card Authorization in OCPP: A Complete Guide

RFID cards are still the most common way to start a charging session at workplaces, depots, hotels and residential sites. The driver taps a card, the charger asks the central system for permission, and charging begins a moment later. Behind that simple experience is a well-defined OCPP message flow and a set of decisions about access rules, offline behavior and security.

This guide explains how RFID charging card authorization works in OCPP, how to manage cards well, how chargers authorize drivers when the connection is down, why authorizations are rejected, and what the real security risks are. It also compares RFID with other identification methods.

How RFID authorization works in OCPP

In OCPP 1.6, the identifier presented by the driver is called an idTag. For an RFID card, this is usually the card's UID (unique identifier), encoded as a hexadecimal string. In OCPP 1.6 an idTag can be up to 20 characters long.

A typical flow looks like this:

1. The driver taps the card on the charger's reader.
2. The charger sends an Authorize request containing the idTag to the CSMS.
3. The CSMS checks the card against its rules and returns idTagInfo with a status.
4. If the status is Accepted and a vehicle is connected, the charger sends StartTransaction with the same idTag. The CSMS again returns idTagInfo, so it can still refuse the session at this point.
5. At the end, StopTransaction reports the final meter value and, if the driver tapped again to stop, the idTag used.

If a card is already in the charger's local list or cache, the charger may start without waiting for the CSMS, depending on its configuration. In that case, a refusal can only arrive in the StartTransaction response, after the transaction was opened.

The idTagInfo status values

The idTagInfo can also contain an expiryDate, which tells the charger how long it may cache the result, and a parentIdTag, which groups several cards together. A common use of parentIdTag is to let any card of the same group stop a session.

What changes in OCPP 2.0.1

OCPP 2.0.1 replaces idTag with IdToken, which carries both a value and a type, such as an ISO 14443 RFID card, an eMAID for contract-based charging, or a key code. The set of authorization statuses is also richer, so a CSMS can explain more precisely why an identifier was refused, for example that it is not allowed at this location. The logic of the flow stays the same.

Best practices for card management

• Register cards before issuing them. Record the UID exactly as the charger reads it. Some readers send the UID in a different byte order or format, so test one card on each charger model.
• Assign every card to a person. Anonymous cards make cost allocation and incident handling difficult.
• Link drivers to vehicles. Recording the license plate on each session simplifies fleet reporting.
• Use allowed stations. Restrict each driver to the sites where they should charge.
• Suspend instead of deleting. A suspended or blocked card keeps its history and can be reactivated.
• Review the card list regularly. Remove access for employees who left and for cards that were replaced.

In Üreticy, RFID cards are assigned to drivers, can be suspended or blocked at any time, and each driver can have a list of allowed stations and kWh limit rules. For a broader view of driver and vehicle rules, see our fleet charging management guide.

Offline authorization: local list and cache

A charger that loses its internet connection still needs to decide whether to let a driver charge. OCPP offers two mechanisms for this.

OCPP 1.6 configuration keys such as LocalAuthListEnabled, AuthorizationCacheEnabled, LocalAuthorizeOffline and AllowOfflineTxForUnknownId control this behavior. The last one decides whether an unknown card may charge when the charger is offline, which is a trade-off between driver convenience and cost control. Transactions made offline are sent to the CSMS when the connection returns.

A practical risk: a card that was blocked in the CSMS may still work offline if it remains in the cache or local list. After blocking an important card, update the local list and consider clearing the cache on affected chargers.

Common rejection reasons and how to handle them

For the driver, every rejection looks the same: the charger does not start. For the operator, the reason matters, so a good CSMS records each rejection with its cause. Üreticy lists every rejected authorization with a reason such as an unknown card, a limit reached, a station not allowed or a blocked card.

• Unknown card: Check whether the card is registered and whether the UID format matches what the reader sends.
• Limit reached: The driver has used their kWh quota. Explain the policy, or adjust the limit if it is too low.
• Station not allowed: The driver is not permitted at this site. Confirm whether this is intended.
• Blocked card: Confirm the card status with the administrator, especially if the driver reports it as lost.
• Reader problems: If no authorization request arrives at all, the reader may be faulty. A ReaderFailure error in StatusNotification points to hardware; see our guide to OCPP error codes.

Security considerations

Most OCPP chargers read only the UID of an RFID card and send it as the idTag. The UID is not secret. With widely available tools, a UID can be read and written to another card. This means that a basic RFID card identifies a user, but it does not strongly authenticate them.

Practical mitigations:

• Set kWh hard limits so that a copied card cannot consume unlimited energy.
• Restrict cards to allowed stations to reduce the area where a copied card works.
• Watch for ConcurrentTx rejections and sessions at unusual times or places, which can indicate a duplicated card.
• Block lost cards immediately and update offline lists.
• Use TLS (wss://) between charger and CSMS so identifiers are not sent in plain text over the network.

Cards with cryptographic features exist, but they only help when the charger's reader verifies those features. Ask the charger vendor what the reader actually checks.

Alternatives to RFID cards

• Mobile app: the driver starts a session from an app, and the CSMS sends a remote start command to the charger.
• QR code: a code on the charger opens a web page or app for that connector. Üreticy generates print-ready QR code labels per connector.
• Plug & Charge (ISO 15118): the vehicle authenticates itself with digital certificates when the cable is connected. It offers strong security and good convenience but needs compatible vehicles, chargers and certificate infrastructure. Plug & Charge is on the Üreticy roadmap.

RFID remains a good choice where users are known and cards are managed centrally.

Frequently asked questions

Manage RFID cards, drivers and rejection reasons for any OCPP charger in one dashboard. See the Üreticy OCPP platform or review the full feature list.