Authorize rejected — invalid idTag

How it presents

Display

Authorize rejected — invalid idTag

OCPP

Faulted / StatusNotification

Symptom

Authorize rejected — invalid idTag on protocol: CSMS StatusNotification + connector LEDs shows OCPP-F03. Techs see session abort or stall Unavailable until the ranked cause is cleared. Correlate OCPP websocket / SECC / vehicle logs as applicable before opening the cabinet.

Root causes (by observed frequency)

1. #1 Backhaul or CSMS path instability for OCPP-F03

   DNS, TLS, NAT keepalive, and MTU before board RMA

2. #2 Wrong OCPP URL / chargePointIdentity after board or SIM swap
3. #3 CSMS-side rate limit or Auth storm after mass reconnect

Diagnostic procedure

1. 1. Capture CSMS StatusNotification + connector LEDs message for OCPP-F03, connector ID, and last successful session time

   Expected: Exact display string + OCPP status/errorInfo if present

   Tools: phone photos (scrubbed), CSMS

2. 2. Pull OCPP websocket / SECC / vehicle logs as applicable; confirm whether Authorize rejected — invalid idTag follows one gun, one cabinet, or the whole site

   Expected: Fault correlates to one path

   Tools: CSMS export, OEM cloud

3. 3. On hardware, isolate power quality / protective devices before opening HV for OCPP-F03

   Expected: Voltage in band; no unexpected trips

   Tools: DMM, IR gun, LOTO kit

4. 4. Execute rank-1 cause check for “Authorize rejected — invalid idTag”; swap known-good cable/gun or stall if available

   Expected: Fault moves with cable or stays with cabinet

   Tools: known-good cable, IR, OEM service menu

5. 5. If unresolved, escalate with OCPP-F03 evidence pack (HMI photo, OCPP snippet, readings) — Stay OEM-agnostic until the protocol stage pins a hardware path

   Tools: ticket template

The fix

Clear OCPP-F03 (Authorize rejected — invalid idTag) by correcting the ranked cause on protocol, then run a full validation session.

• Suspect module or controller indicated by rank-1 cause

  OEM protocol service channel; keep serial for RMA

  OCPP-F03

1. LOTO and verify zero energy per protocol HV procedure before any bus work
2. Correct rank-1 cause for OCPP-F03; do not shotgun-replace modules
3. Clear fault latches in HMI/CSMS; confirm StatusNotification returns to Available/Preparing as appropriate
4. Run validation: authorize → handshake → ≥5 minutes energy → clean stop; capture MeterValues
5. Document firmware, part lots, and scrubbed HMI photos for confirmations