Fleet credential programme

Fleet Authentication

RFID credentials for depot, workplace and public charging, with controlled driver or vehicle assignment, platform-ready identifiers and replacement records.

Programme outcome

A credential record that can be assigned, traced, replaced and reconciled across depot and public charging.

Review recommended product

Designed for

Fleet operators, leasing teams, depot managers and mobility providers

01

Assignment model

Driver, vehicle, pool or cost centre

02

Station handoff

RFID reader → OCPP → CSMS

03

Operating estate

Depot, workplace and public charging

04

Lifecycle

Issue, activate, block, replace, replenish

Operating model / 01

Follow the credential across the complete authorization chain.

The physical card is one controlled input. Reader behaviour, platform records and operating rules determine whether the correct account is authorized and traced.

Fleet Authentication
A credential record that can be assigned, traced, replaced and reconciled across depot and public charging.
  1. 01

    Driver or vehicle

    The programme owner decides whether the credential follows a person, a vehicle, a shared pool or an operating account.

  2. 02

    Physical credential

    The card or keyfob presents the identifier and, where supported, secure application data to the station reader.

  3. 03

    Charging station

    The reader captures the supported credential data and the station passes an authorization request to its management system.

  4. 04

    Fleet and charging platforms

    The identifier is mapped to the correct fleet record, entitlement, tariff or cost centre before the session is accepted.

  5. 05

    Session record

    Energy and session data return through the operating platform; reporting quality depends on the assignment and data model, not the card alone.

Specification matrix / 02

Decisions to close before production.

A production-ready brief states what must be decided, how it will be implemented and what evidence will count as acceptance.

01

Assignment model

What to define

Choose driver, vehicle, pool-card or account assignment and document the handover rules.

Acceptance evidence

A sample identifier resolves to the intended record without duplicate ownership.

02

Reader estate

What to define

List representative depot AC/DC readers and any public networks where the credential will be used.

Acceptance evidence

Samples are read consistently across the agreed test set.

03

Identifier format

What to define

Confirm UID or application identifier, length, byte order, character format and leading-zero treatment.

Acceptance evidence

The manufactured value and platform import remain identical end to end.

04

Security level

What to define

Decide whether UID-only identification is sufficient or a reader-supported secure application is required.

Acceptance evidence

The target readers complete the agreed authentication path; key ownership is documented.

05

Transaction attribution

What to define

Define the driver, vehicle, department and cost fields expected in session exports.

Acceptance evidence

Pilot sessions appear against the correct operational and finance records.

06

Visible identity

What to define

Add a human-readable serial, vehicle reference, QR code or support number only where operationally useful.

Acceptance evidence

Printed and encoded records match the approved variable-data file.

07

Lifecycle rules

What to define

Define activation, blocking, return, replacement and reorder procedures before launch.

Acceptance evidence

A lost-card scenario can be resolved without creating an ambiguous replacement record.

Failure controls / 03

Design out the common failure points.

Most failed launches are not caused by print quality. They come from unclear identifiers, untested readers, incomplete data ownership or weak lifecycle control.

01

Avoid shared identities

A shared card may be convenient, but it removes driver-level accountability. Use it only where the reporting model permits.

02

Test offline behaviour

Authorization cache and local-list behaviour are station and CSMS decisions. Include a disconnected-station test when depot continuity matters.

03

Separate card from billing claims

The card identifies an account. Tariffs, reimbursement, tax treatment and consolidated invoicing are controlled elsewhere.

04

Keep a replacement trail

Link old and new serials, block status and issue dates so the physical inventory agrees with the platform record.

Delivery path / 04

Move from brief to controlled operation.

Each phase should close with evidence that can be reviewed by operations, platform and procurement teams.

  1. 01

    Discovery

    Map users, vehicles, sites, readers, platforms and public-network requirements.

    Evidence

    Approved fleet credential brief

  2. 02

    Reader sample

    Build representative cards or keyfobs using the proposed chip and identifier rules.

    Evidence

    Physical test set and UID file

  3. 03

    Data pilot

    Import sample records, run depot and public-network sessions, and inspect the returned attribution.

    Evidence

    Pilot authorization and session log

  4. 04

    Controlled issue

    Produce the launch batch, assign credentials and retain an issuance register.

    Evidence

    Production QC and assignment file

  5. 05

    Lifecycle operation

    Manage blocks, replacements, returned cards, new drivers and repeat batches against the retained specification.

    Evidence

    Versioned reorder record

Responsibility boundary / 05

Separate manufacturing from platform operation.

A precise boundary prevents the card from being blamed for configuration, entitlement or settlement decisions that live elsewhere.

01

ChargeRFID / manufacturer

Controls the approved material, chip, antenna, artwork, encoding, variable data, batch QC and production record.

02

CPO, eMSP or CSMS team

Defines accepted identifier format, reader behaviour, token import, authorization states, security application and technical acceptance.

03

Programme owner

Owns assignment, activation, contracts, access policy, tariffs, customer support, replacement approval and end-of-life decisions.

Programme questions / 08

Questions procurement and technical teams usually resolve.

01Should a fleet card be assigned to the driver or the vehicle?

Use driver assignment when accountability and expense reporting follow the person; use vehicle assignment when the asset is the stable reporting unit. Pool cards need an additional booking or handover record if individual accountability is required.

02Can the same credential work at depot and public chargers?

It can, provided the identifier is accepted and registered in every relevant authorization system. Reader compatibility and public-network entitlement must both be tested; manufacturing the card alone does not create roaming access.

03Is AES-authenticated 13.56 MHz credential always required for fleet charging?

No. AES-authenticated 13.56 MHz credential supports AES-based applications, but that security is useful only when the target readers and backend implement the same application and key scheme. A UID-only estate should be specified honestly and assessed for its risk.

04Does the RFID card calculate fleet charging costs?

No. The credential identifies the assigned record. The CSMS, mobility platform or fleet system applies tariffs, cost centres, reimbursement and reporting rules to the resulting sessions.

Turn ev fleet charging cards into a controlled programme specification.

Share the reader estate, identifier rules, security requirement, platform handoff, volume and rollout markets. We will return the questions needed for samples and production approval.