Fleet CMS driver auth fail

How it presents

Symptom

A driver's credential or fleet app is rejected by the Ampcontrol CMS even though the charger hardware and OCPP path both look completely healthy — other drivers may authorize and charge normally at the exact same stall within minutes, which is the clearest signal that this is an enrollment or mapping problem in software rather than a reader or connector fault.

Root causes (by observed frequency)

1. #1 The driver's RFID or credential isn't in the allowlist, or is enrolled under the wrong organization/depot group

   This is the single most common cause — check enrollment and org mapping before touching anything else

2. #2 A mismatch in the auth profile handshake between the CMS and the CSMS, so a valid credential on one side isn't recognized on the other
3. #3 An expired credential or an incorrectly entered PIN on the driver's end
4. #4 Reader hardware intermittently failing to read the credential cleanly, producing what looks like an auth rejection but is actually a read error

Diagnostic procedure

1. 1. Test a known-good driver credential against the same stall the failing driver used

   Expected: Known-good credential authorizes normally, isolating the problem to the specific credential rather than the stall

   Tools: Test badge/credential

2. 2. Check the CMS enrollment record and organization mapping for the failing credential

   Tools: CMS admin console

3. 3. If enrollment looks correct, confirm the OCPP Authorize path end to end between CMS and CSMS

   Tools: CSMS admin console

4. 4. Check credential expiration date and confirm the driver is using the correct PIN if applicable

   Tools: CMS admin console, driver interview

5. 5. If all credentials fail at that specific reader, only then suspect reader hardware and schedule reader service

   Tools: Reader diagnostics

The fix

Fix the enrollment or mapping issue before considering any hardware RMA — the overwhelming majority of these tickets resolve with a CMS-side correction.

1. Correct the driver's enrollment record, organization mapping, or credential status in the CMS as identified during triage.
2. Retest the Authorize flow immediately with the same credential at the same stall to confirm the fix actually resolved it end to end.
3. If the issue was an auth profile mismatch between CMS and CSMS, coordinate with whoever owns that integration to correct the profile rather than patching around it per-driver.
4. Only schedule reader hardware service if every credential — not just the original driver's — fails to authorize at that specific stall after enrollment is confirmed correct.
5. Document which layer (enrollment, profile mismatch, or hardware) was the actual cause so recurring patterns at a given depot become visible over time.