Preserve leading zeros
Identifier conversion can silently change values. Compare raw reader output, exported data and imported records byte for byte.
RFID migration programme
Programme outcome
A phased migration that preserves service while reader behaviour, identifiers, security and replacement records are validated.
Review recommended productDesigned for
Operators replacing legacy cards, changing CSMS platforms or strengthening a UID-only estate
Starting point
Legacy UID, chip, platform or reader estate
Target
Reader-matched identifier or secure application
Transition
Pilot, mixed operation and phased reissue
Control
Key custody, mapping and retirement evidence
Operating model / 01
The physical card is one controlled input. Reader behaviour, platform records and operating rules determine whether the correct account is authorized and traced.

Inventory active, inactive, lost and unknown credentials together with their chip, UID and assignment records.
Document what each reader actually supports; nominal frequency alone does not prove application compatibility.
Compare legacy UID representation and platform fields with the proposed identifier, mapping or secure application.
Run old and new credentials through representative readers, authorization states and operational exceptions.
Issue replacements in controlled groups, retain cross-references and remove legacy entitlement only after acceptance.
Specification matrix / 02
A production-ready brief states what must be decided, how it will be implemented and what evidence will count as acceptance.
Capture chip, UID length, identifier representation, reader, firmware, CSMS and active-card status.
Unknowns and unsupported combinations are visible before target selection.
Test legacy and target credentials across representative hardware and software combinations.
Every rollout group has a supported reader path or remediation plan.
Define whether the existing account keeps its identifier, receives a mapped replacement or is recreated.
Old and new serials resolve to one intended account during transition.
Choose UID-only, secure application data or a staged combination based on reader capability and risk.
Authentication and key responsibilities are documented and tested.
For secure applications, define key generation, diversification, loading, storage, rotation and recovery ownership.
No production key depends on an undocumented person or export.
Set the period and rules for accepting old and new credentials together.
Revocation, cache and local-list behaviour is predictable throughout the overlap.
Record delivery, activation, old-card block, destruction or return, and unresolved exceptions.
The programme can prove which legacy credentials remain valid.
Failure controls / 03
Most failed launches are not caused by print quality. They come from unclear identifiers, untested readers, incomplete data ownership or weak lifecycle control.
Identifier conversion can silently change values. Compare raw reader output, exported data and imported records byte for byte.
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.
A forced one-day cutover is rarely necessary. Define the overlap, rollback and exception groups before issuing replacements.
Secure cards without documented key custody, diversification and recovery can create a new form of vendor lock-in.
Delivery path / 04
Each phase should close with evidence that can be reviewed by operations, platform and procurement teams.
Inventory credentials, readers, firmware, platforms, identifier formats and active assignments.
Current-state estate register
Select the new technology, security level, data model and key-management responsibility.
Approved target credential profile
Test old and new cards across readers, sites, connectivity states and platform processes.
Compatibility and exception matrix
Replace by site or user cohort with assignment, communication and rollback controls.
Cohort issue and activation log
Block, return or destroy old credentials and close unresolved mappings.
Retirement and residual-risk report
Responsibility boundary / 05
A precise boundary prevents the card from being blamed for configuration, entitlement or settlement decisions that live elsewhere.
Controls the approved material, chip, antenna, artwork, encoding, variable data, batch QC and production record.
Defines accepted identifier format, reader behaviour, token import, authorization states, security application and technical acceptance.
Owns assignment, activation, contracts, access policy, tariffs, customer support, replacement approval and end-of-life decisions.
Credential options / 06

OCPP Workflows / idTag / idToken / UID Formatting
RFID credentials prepared for the identifier and authorization workflow used between EV charger readers and OCPP charging-management systems.
Review recommended product
Custom Engineering / OEM/ODM / Prototype Validation
Custom RFID credentials engineered around your charging readers, token data, security model, form factor, artwork and fulfilment workflow.
Review recommended product
Recycled PVC / Custom RFID / UID Mapping
Custom RFID charging cards with a recycled-PVC card body, reader-matched chip options, programme artwork and UID-to-account data handoff.
Review recommended productTechnical library / 07
These sources define the surrounding technology and operating interfaces. ChargeRFID manufactures physical credentials; platform configuration, roaming contracts and charging-station certification remain with the relevant operators and vendors.

Technology / 7 min read
A vendor-neutral method for choosing a 13.56 MHz EV charging credential by reader behavior, identifier format, authentication, backend controls and roaming requirements
Read More
Technology / 9 min read
What an RFID card for EV charging actually does, how it authenticates against OCPP stations and roaming hubs, the chip technologies used, and how to choose the right card for fleets, networks, or personal use.
Read More
Technology / 5 min read
RFID Authentication Goes Embedded: Offline-Capable Charging Stations Reshape EV Infrastructure
Read MorePrimary implementation references
Programme questions / 08
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.
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.
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.
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.
Other operating programmes
RFID credentials for depot, workplace and public charging, with controlled driver or vehicle assignment, platform-ready identifiers and replacement records.
White-label cards and keyfobs prepared around your brand, identifier format, platform import, launch volume and repeat-order workflow.
Physical RFID credentials for roaming programmes where token records, identifier formats and lifecycle status stay consistent across eMSP, CPO and hub systems.
Credential programmes for workplaces, depots, residential sites and destinations that need controlled access by employee, resident, visitor or account.
Branded credentials for vehicle delivery, dealership charging, loyalty and premium member programmes—with controlled serialization and presentation.
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.