RFID migration programme

Secure RFID Migration

A controlled route from legacy or UID-only credentials to reader-matched card technology with a practical pilot, data plan and phased reissue.

Programme outcome

A phased migration that preserves service while reader behaviour, identifiers, security and replacement records are validated.

Review recommended product

Designed for

Operators replacing legacy cards, changing CSMS platforms or strengthening a UID-only estate

01

Starting point

Legacy UID, chip, platform or reader estate

02

Target

Reader-matched identifier or secure application

03

Transition

Pilot, mixed operation and phased reissue

04

Control

Key custody, mapping and retirement evidence

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.

Secure RFID Migration
A phased migration that preserves service while reader behaviour, identifiers, security and replacement records are validated.
  1. 01

    Existing credential estate

    Inventory active, inactive, lost and unknown credentials together with their chip, UID and assignment records.

  2. 02

    Reader and firmware estate

    Document what each reader actually supports; nominal frequency alone does not prove application compatibility.

  3. 03

    Identity translation

    Compare legacy UID representation and platform fields with the proposed identifier, mapping or secure application.

  4. 04

    Controlled pilot

    Run old and new credentials through representative readers, authorization states and operational exceptions.

  5. 05

    Phased retirement

    Issue replacements in controlled groups, retain cross-references and remove legacy entitlement only after acceptance.

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

Estate inventory

What to define

Capture chip, UID length, identifier representation, reader, firmware, CSMS and active-card status.

Acceptance evidence

Unknowns and unsupported combinations are visible before target selection.

02

Compatibility matrix

What to define

Test legacy and target credentials across representative hardware and software combinations.

Acceptance evidence

Every rollout group has a supported reader path or remediation plan.

03

Identity mapping

What to define

Define whether the existing account keeps its identifier, receives a mapped replacement or is recreated.

Acceptance evidence

Old and new serials resolve to one intended account during transition.

04

Security target

What to define

Choose UID-only, secure application data or a staged combination based on reader capability and risk.

Acceptance evidence

Authentication and key responsibilities are documented and tested.

05

Key custody

What to define

For secure applications, define key generation, diversification, loading, storage, rotation and recovery ownership.

Acceptance evidence

No production key depends on an undocumented person or export.

06

Mixed operation

What to define

Set the period and rules for accepting old and new credentials together.

Acceptance evidence

Revocation, cache and local-list behaviour is predictable throughout the overlap.

07

Retirement evidence

What to define

Record delivery, activation, old-card block, destruction or return, and unresolved exceptions.

Acceptance evidence

The programme can prove which legacy credentials remain valid.

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

Preserve leading zeros

Identifier conversion can silently change values. Compare raw reader output, exported data and imported records byte for byte.

02

Do not assume AES-authenticated 13.56 MHz credential mode

A reader that detects a AES-authenticated 13.56 MHz credentials may still use only its UID. Secure applications require explicit reader and key support.

03

Plan dual-running

A forced one-day cutover is rarely necessary. Define the overlap, rollback and exception groups before issuing replacements.

04

Treat keys as infrastructure

Secure cards without documented key custody, diversification and recovery can create a new form of vendor lock-in.

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

    Audit

    Inventory credentials, readers, firmware, platforms, identifier formats and active assignments.

    Evidence

    Current-state estate register

  2. 02

    Target design

    Select the new technology, security level, data model and key-management responsibility.

    Evidence

    Approved target credential profile

  3. 03

    Representative pilot

    Test old and new cards across readers, sites, connectivity states and platform processes.

    Evidence

    Compatibility and exception matrix

  4. 04

    Phased reissue

    Replace by site or user cohort with assignment, communication and rollback controls.

    Evidence

    Cohort issue and activation log

  5. 05

    Legacy retirement

    Block, return or destroy old credentials and close unresolved mappings.

    Evidence

    Retirement and residual-risk report

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.

01Can we keep the same UID when moving to a new card technology?

Sometimes a platform can preserve the account through a mapping table, but copying or selecting a specific UID may be impossible, insecure or outside the chip supplier's intended model. Treat identity continuity as a backend migration question first.

02Can old and new credentials operate together?

Yes, if readers and the authorization platform support both and the overlap rules are tested. Mixed operation should have a defined end date, revocation process and rollback plan.

03Does moving to AES-authenticated 13.56 MHz credential automatically add AES security?

No. AES-authenticated 13.56 MHz credential supports AES-based applications, but the reader, key scheme and backend must implement that application. Reading only the card UID does not use those cryptographic capabilities.

04What is the minimum useful migration pilot?

Include every representative reader/firmware family, the intended online and offline authorization paths, at least one replacement scenario and a complete data import/export reconciliation.

Turn rfid cards for ocpp charging networks 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.