How to Set Up RFID Access for Commercial EV Chargers

To set up RFID access for commercial EV chargers, confirm that the reader supports your credential, capture the identifier the charger actually reports, register that value in the charging platform, assign the required access rights, and test the complete charging session. Then test what happens when connectivity fails and when a card is revoked.

Order the production batch after a representative sample passes this workflow. A successful tap establishes only part of the result. Your acceptance record should also show the correct charging point, account, energy record and stop behavior.

This guide covers access management after the charging equipment has been installed and commissioned by a qualified installer. It is intended for the team connecting physical credentials to a charging management system.

Understand which system makes each decision

In an online authorization flow, the RFID reader obtains an identifier, the charging station passes it to a charging station management system, or CSMS, and the platform returns an authorization result. OCPP governs communication between the station and that management system. The card-to-reader radio interface is a separate part of the integration. See the Open Charge Alliance protocol overview.

Give one person ownership of each layer. A card supplier can provide the agreed physical credential and identifier file; the charger integrator confirms reader behavior; the platform operator controls account registration and permissions. Record who resolves a mismatch before commissioning begins.

1. Confirm the reader and authorization capabilities

Ask for the reader specification for the exact charger model, hardware revision and installed firmware. Record its supported contactless standards, the credential mode it uses, and any configurable identifier conversion. A description such as “RFID enabled” leaves these questions open.

NFC operates at 13.56 MHz and encompasses several contactless technologies, including ISO/IEC 14443 Type A, Type B and ISO/IEC 15693. A frequency match alone is therefore an incomplete purchasing specification. Match the actual card technology and reader implementation. The NFC Forum technical overview explains these underlying protocols.

Next, establish what the station and backend actually implement:

OCPP certification needs to be read at the feature level. OCA's December 2025 update places Local List Management among the optional features within the OCPP 2.0.1 Core profile. The updated certification program therefore does not make every certified station a guarantee of local-list support. OCA's OCPP 2.Lite application note, section C also explains that an authorization cache can be omitted and that implementations can support different authorization methods.

Ask for the certificate scope and the Protocol Implementation Conformance Statement, where available, and check them against the installed software. Keep this evidence with the site configuration.

OCA currently publishes OCPP 1.6, 2.0.1 and 2.1 packages. The examples below address 1.6 and 2.0.1 specifically; use the matching specification for a 2.1 installation. Check the official downloads and errata when commissioning or upgrading.

2. Capture the identifier from the actual charger

Begin with a small set of identifiable test cards. Keep the printed card reference separate from the electronic value: a visible serial such as CRF-TEST-0042 is useful for support, but its relationship to the backend identifier must be documented.

For an online OCPP authorization request, these are illustrative payload fragments using a fictional identifier:

OCPP 1.6

{"idTag":"04A1B2C3D4E5F7"}

OCPP 2.0.1

{"idToken":{"idToken":"04A1B2C3D4E5F7","type":"ISO14443"}}

These fragments omit WebSocket message framing. The official schemas define a maximum of 20 characters for the 1.6 idTag and 36 for the 2.0.1 idToken string; 2.0.1 also requires its token type. Validate against the OCPP 1.6 package or OCPP 2.0.1 Edition 4 package used for your integration.

A locally authorized start may follow a different message sequence. Have the integrator identify where the credential and authorization decision are recorded for that mode.

3. Agree the UID representation before importing cards

For an ISO14443 token, OCPP 2.0.1 recommends hexadecimal UID bytes with byte 0 first. Legacy product behavior still needs checking: Wallbox's OCPP activation guide specifies little-endian hexadecimal values without separators for the products covered by that guide. That is a product-specific instruction, not a universal conversion rule. See OCPP 2.0.1, authorization section C.1.1 and the Wallbox activation guide, pages 14 and 20.

For this fictional seven-byte sequence, the representations are:

The table shows transformations, not four interchangeable backend values. Import the representation required by the integration. Reversing bytes changes their order in pairs; reversing individual characters produces a different result.

Keep a written mapping between supplier data, the station log and the backend import field. Include byte length, hexadecimal or decimal notation, byte order, separators, and any explicitly documented transformation. Preserve the raw source file. Avoid undocumented truncation or guessing missing bytes.

Check for device settings that transform identifiers. The Wallbox eM4 WebAdmin manual, for example, includes a “Shorten UIDs” option and warns that authorization settings can be changed from either the local interface or the backend. See the Wallbox WebAdmin manual, page 23. Record the effective configuration after both systems have connected.

Import identifier columns into spreadsheets as text. Excel can remove leading zeros and limits numeric precision to 15 significant digits; our decimal example has 16 digits. Applying a display format after data has been altered does not recover the original identifier. Follow Microsoft's guidance for preserving identifier data.

Use the ChargeRFID UID converter to inspect representations and the credential reconciliation tool to compare production and backend files. Confirm the proposed mapping against an actual charger log before applying it to the batch.

4. Register credentials and assign commercial permissions

Create the credential record using the platform's documented enrollment or import process. Link it to the intended driver, vehicle, department or customer account according to how your operation attributes charging.

For each pilot credential, record:

Keep these as separate acceptance questions. A credential can appear in the database while still lacking the intended location permission or account assignment. Likewise, a successful start does not establish that the correct billing arrangement was applied.

Use an enrollment register with a batch reference, import result, exception reason and reviewer. Resolve duplicate values and conflicting assignments before release. Adapt the UID handoff template to your platform's actual import contract; its example row is test data.

For shared vehicles, agree who can stop a session. OCA's OCPP 1.6 test cases explicitly cover stopping with the initiating card and stopping with another card linked by a matching parent identifier. Test the group behavior you intend to enable. See the OCTT 2026-02 test cases, sections 2.3.1 and 2.3.2.

5. Set an explicit offline access policy

Decide whether charging should continue when the station cannot reach its management system. For a restricted fleet depot, a sensible starting policy is to admit the intended locally authorized credentials and reject unknown cards during an outage. Confirm that the equipment can implement that policy before relying on it.

An authorization cache holds authorization information learned through previous exchanges. A local authorization list is managed and synchronized from the backend. These are distinct mechanisms. Clearing one does not establish that the other has been updated. OCPP 1.6 describes their relationship in section 3.5 of the specification.

These are examples of version-specific names to discuss with the integrator, rather than a configuration file to paste into a charger:

The names are not a declaration that every feature is implemented, enabled or writable. OCPP 2.0.1 uses component and variable addressing; the device model and applicable use case determine how each setting operates. See the Edition 4 authorization and referenced-variable sections.

Record the local-list capacity, update acknowledgement, expiry handling, persistence after reboot and behavior when storage is full. Test a known credential that has never previously been used on the station, as well as one already authorized there. This helps establish which local mechanism the deployment actually relies on.

Include reconnection in the test. Check how offline transactions reach the backend, how they are reconciled, and what happens to an ongoing session if the backend rejects its credential after connectivity returns. Agree the acceptable operational and financial exposure with the site owner.

6. Choose the credential security model deliberately

Ask whether the reader simply reads an identifier or performs cryptographic authentication with the credential. In a UID-only design, acceptance of a matching identifier does not demonstrate possession of a cryptographic secret. Buying a chip with security capabilities provides value only when the deployed reader and application use those capabilities.

Where cryptographic card authentication is required, document the supported application, key ownership, provisioning process, replacement procedure and migration responsibilities. Keep secrets out of UID handoff files. NIST's RFID security guidance, section 5.3.1 describes the distinction between identifiers and authentication controls. It is foundational guidance published in 2007; use current product documentation to select supported algorithms and key-management mechanisms.

Secure the station-to-backend connection separately. OCA's current Security Operations Guide, sections 4.2 and 4.4 describes Security Profile 2 as TLS with Basic Authentication and Profile 3 as TLS with client-side certificates, and addresses credential storage. Confirm the deployed transport profile, certificate validation and station credential management. These settings protect a different connection from the card-to-reader link.

7. Add roaming authorization only when the service requires it

A private workplace installation may need only its own platform's credential register. Roaming adds another boundary: the charge point operator, or CPO, must obtain authorization from the relevant e-mobility service provider, or eMSP, through the supported integration and commercial arrangement.

In OCPI 2.3.0, a token record contains the owning provider's country and party identifiers, a token UID, type, validity and whitelisting policy. Its ALLOWED_OFFLINE policy concerns communication between the CPO and eMSP. A charger losing its connection to the CSMS is a separate outage. Test both boundaries if both exist.

The Tokens module also distinguishes a valid token from one allowed at a specific location. Invalidation is propagated using an updated token with valid: false; deleting tokens through that interface is not the mechanism. Check the official OCPI 2.3.0 Tokens module against the version agreed with your partner.

For the pilot, name the issuer and participating network, establish the expected authorization path, and check the resulting session and charging record. Reusing the same physical card across services still requires the appropriate registration, permissions and agreements.

8. Commission the complete access lifecycle

Use a test matrix with expected results written before the test. Run it on each distinct hardware, firmware and backend configuration, then spot-check the installed fleet against that approved configuration.

For each run, retain the time, station and connector identifiers, firmware, test-card reference, effective configuration, expected result, actual result and relevant transaction record. Mask personal data in evidence shared outside the operating team.

When a card is lost, record when the report arrived and when each connected system acknowledged the change. A disconnected station cannot receive a new revocation immediately. The practical exposure depends on its stored authorization state, expiry rules and reconnection behavior. Address that interval in the operating procedure.

Diagnose a failed tap at the right boundary

Collect one failed attempt with its timestamp and card reference, then work through the evidence. These checks narrow the investigation without assuming that every rejection has the same cause.

Example rollout for a fleet depot

Consider a fictional depot with 60 drivers, 12 charging points and two charger models. The operator wants access attributed to individual drivers, restricted to the depot, with approved drivers able to charge through a backend outage.

Start with five sample credentials. On each charger model, capture the reported identifier and agree the mapping to the supplier file. Register the samples in a pilot account, assign depot access and confirm the intended cost center.

If the equipment supports a managed local list, preload the pilot credentials and record the acknowledged version. Keep unknown offline credentials disabled for this proposed policy. Disconnect the station from the CSMS through a controlled test, then try a preloaded card, an unknown card and a revoked card with a deliberately documented stale local state. Restore connectivity and verify the update and transaction records.

Complete the online rejection, session-stop and billing tests on both models. Once the pilot passes, reconcile the 60-card production file against the backend register, resolve exceptions and distribute the cards with a simple lost-card reporting process. Repeat the relevant acceptance tests after material firmware, reader-mode or platform changes.

Questions to resolve before ordering

Do RFID charging cards need programming?

For a design that reads the card's existing UID, setup can consist of registering that value and assigning access in the platform. A design using a protected application may require card personalization and coordinated reader configuration. Specify the exact reader workflow before ordering either service.

Can an existing employee badge also unlock a charger?

It may be possible when the reader supports the badge technology, the required identifier is available and stable, and the platform permits registration. Obtain approval from the badge-system owner and test actual samples. For an example of platform-specific enrollment, the Easee account and local-key documentation describes distinct enrollment scopes and cautions about changing identifiers.

Will one card work on every charging network?

Establish the intended networks individually. Physical readability, credential registration, account rights and any roaming agreement all form part of the acceptance criteria. Test the participating network rather than assuming coverage from the card's appearance.

What should the card supplier receive?

Provide the reader requirements, approved sample identifier mapping, visible numbering scheme, material and print specification, quantity and agreed data-delivery format. Include the person responsible for backend import and sample acceptance. Transfer application secrets through a separately agreed secure provisioning process when the design requires them.

Prepare a sample specification for your deployment

Bring the charger model and firmware, backend name and protocol version, required credential mode, confirmed identifier representation and intended offline policy into one specification. Use the ChargeRFID credential lab to review the data handoff and request finished samples for your pilot. Approve the physical credential and its full access workflow together before releasing the production order.