OCPP (Open Charge Point Protocol) is the communication protocol between an EV charging station and its charging station management system (CSMS). It lets the charger report status and sessions and lets the CSMS send supported commands. A shared OCPP version does not by itself prove that a specific charger, firmware release, and backend will work together; buyers should verify certification scope and test that exact combination. 1
For a network operator, the key question is not simply whether a charger is “OCPP-enabled.” It is whether the exact model and firmware can connect securely to the intended CSMS and perform the functions the site needs. OCPP concerns charger-to-backend communication; connector fit and electrical installation are separate checks covered in this EV charging station overview.
Table of Contents
- What is OCPP in EV charging?
- How does OCPP work between a charger and a CSMS?
- What can an operator manage through OCPP?
- Which OCPP version should you specify?
- Is OCPP the same as ISO 15118, OCPI, or a payment system?
- Does OCPP certification prove compatibility with your CSMS?
- Is OCPP secure, and what should a buyer verify?
- How do you use an OCPP compatibility acceptance card?
- What does a real charger-network migration show buyers?
- How should you choose an OCPP charger for a project?
- Conclusion: approve the tested charger-CSMS combination
- Frequently Asked Questions
- References
What is OCPP in EV charging?
OCPP is an open protocol for exchanging messages between a charging station and a central charging system. The charger is also called the charge point (CP); the backend that manages its operation is commonly called a CSMS. OCPP defines how they communicate, while the CSMS decides how the network operator presents, bills, and manages the service. 1
The protocol sits above the electrical and vehicle-connection layers. It does not determine whether a connector fits a vehicle, whether a site has enough electrical capacity, or whether the complete EVSE meets local installation requirements. It provides a common communication method that can reduce dependence on a single proprietary charger-and-software bundle, subject to the versions, functions, security setup, and implementation being used.
How does OCPP work between a charger and a CSMS?
OCPP uses structured messages so the charger and CSMS can exchange operational information. A typical networked charging session follows this sequence:
- The charger connects: it identifies itself to the CSMS and reports that it is online.
- The charger reports availability: the backend receives connector state and any fault or unavailable status.
- A driver requests a session: the charger or CSMS checks an RFID token, app identity, or another supported identifier.
- The charging session runs: the system records transaction events and meter readings according to the implementation and configuration.
- The CSMS monitors or controls the charger: supported commands may change a setting, apply a charging limit, or request a remote action.
- The session ends: the charger reports the final state and available transaction or meter data.
The exact messages and available functions depend on the OCPP version and implementation. For example, transaction handling and device management differ between OCPP 1.6 and 2.0.1; a purchase specification should state the functions required rather than assuming all versions behave identically. 1
What can an operator manage through OCPP?
Depending on the version and the tested feature set, an operator can use OCPP to monitor chargers, authorize sessions, collect meter data, receive faults, manage settings, and issue supported remote commands. Smart charging can help schedule or limit charging, but the site’s electrical capacity still has to be established by its electrical design and load-management controls.
| Operator task | What the CSMS may receive or request | What the buyer should confirm |
|---|---|---|
| Availability and faults | Connector status, fault information, and availability changes | The states and fault codes exposed by the exact charger firmware |
| Authorization | Approval or rejection of supported user identifiers | Online and offline authorization behavior required by the site |
| Transactions and metering | Session events and energy readings | Required readings, units, intervals, and how missing data is handled |
| Remote operation | Supported remote start, stop, reset, or unlock actions | Which commands are supported and how results are reported |
| Configuration and updates | Supported configuration, device-management, or firmware workflows | Firmware baseline, update ownership, recovery path, and change records |
| Smart charging | Supported charging limits or schedules | Whether the charger, CSMS, and site controller support the required control loop |
OCPP may carry a charging limit, but it does not replace the site meter, energy controller, or electrical capacity assessment. For multi-charger sites, review the related EV charging load management requirements alongside protocol support.
Which OCPP version should you specify?
Specify the version that is supported by the target CSMS and the exact charger firmware, then confirm the needed functions. OCA currently lists OCPP 1.6, 2.0.1, and 2.1; 2.0.1 and 2.1 add capabilities beyond 1.6, but a later version is not automatically the better choice for an existing network. 1
| Version | Why buyers encounter it | Decision check |
|---|---|---|
| OCPP 1.6 | Common in installed networks and existing CSMS deployments | Confirm the required JSON-over-WebSocket implementation, security setup, and backend support for the exact model and firmware |
| OCPP 2.0.1 | Adds a broader device model, updated transaction handling, and additional security and management functions | Confirm the CSMS supports the required 2.0.1 functions and the supplier’s firmware baseline |
| OCPP 2.1 | Extends 2.0.1 for newer use cases, including bidirectional charging and DER control | Confirm the complete charger, CSMS, and test-tool support for the functions the project will use |
Protocol publication, product certification, and test-tool coverage are different milestones. OCA’s OCTT page currently lists test cases for OCPP 1.6 and 2.0.1 and says coverage for OCPP 2.1 is being extended. A tender or purchase order should therefore state the required version and functions and request the current evidence for that exact product; do not infer certification or backend support from the protocol’s publication alone. 4
Is OCPP the same as ISO 15118, OCPI, or a payment system?
No. These standards and systems address different communication paths or services:
- OCPP: communication between a charging station and its CSMS.
- ISO 15118: communication between a vehicle and charging equipment, including supported Plug & Charge or bidirectional charging use cases.
- OCPI: commonly used for roaming and information exchange between e-mobility service providers and charge point operators.
- Payment systems and driver apps: handle payment processing and user-facing functions through their own platform integrations.
OCPP may carry authorization and transaction data, but that does not make it a complete payment service. Likewise, OCPP support does not prove that a charger has the vehicle-to-charger functions of ISO 15118 or the roaming integrations an operator needs. OCA’s version descriptions identify these as related but separate capabilities. 1
Does OCPP certification prove compatibility with your CSMS?
No. OCA certification is evidence that an implementation was tested against the specified OCPP version and certification scope. It is useful evidence, but the buyer still needs to establish that the exact charger model and firmware work with the intended CSMS, its configuration, security setup, and required functions. OCA’s migration guidance calls for testing charger models against the new CSMS and identifying implementation differences before migration. 2 5
For an OCPP 2.0.1 certificate, check the exact certificate record and profile—not only a logo or a supplier statement. The Core profile remains mandatory. OCA’s December 2025 update states that Core includes baseline functions such as booting, authorization, configuration, transactions, remote control, secure firmware updates, and Security Profile 2; Reservations, Local Authorization List Management, Advanced Device Management, and Advanced User Interface are optional features in the Core profile. Advanced Security, Smart Charging, and ISO 15118 Support are optional certification profiles. 2 3
Ask the supplier for the certificate number, listed product designation, software or firmware version, OCPP version, and the exact profile or feature scope shown by OCA. Then compare that evidence with the functions in the purchase specification. A certificate covering one version or software release should not be treated as proof for a different release or every optional feature.
Is OCPP secure, and what should a buyer verify?
OCPP provides security mechanisms, but a secure deployment depends on the selected security profile, certificates, configuration, firmware, backend, and operating process. Before approval, agree who provisions and renews certificates, who controls credentials, how firmware updates are authenticated and recovered, and what the charger does when the network is unavailable. 2 3
| Security item | Evidence to request |
|---|---|
| OCPP security profile | Supported profile on the exact charger firmware and target CSMS |
| TLS and certificates | Certificate chain, trust configuration, expiry and renewal process, and owner for each step |
| Credentials | How credentials are provisioned, changed, stored, and revoked |
| Firmware | Signed or otherwise controlled update process, version history, recovery path, and support term |
| Connectivity loss | Documented behavior for reconnect, offline authorization, queued records, and recovery |
| Operational roles | Named owner for charger configuration, CSMS settings, certificates, and incident response |
How do you use an OCPP compatibility acceptance card?
Use one acceptance card for each charger model + hardware revision + firmware version + CSMS version/environment combination. Mark optional functions as “required” only when the project needs them; attach the test log or configuration record to each result. A product should not pass because another model in the same catalogue connected successfully.
OCPP charger–CSMS acceptance card
| Check | Pass condition agreed before testing | Evidence to retain | Result |
|---|---|---|---|
| Product identity | Model, hardware revision, serial range, and firmware match the quoted and sampled units | Datasheet, nameplate photo, firmware screen or report | ☐ Pass ☐ Fail |
| Protocol and certificate | OCPP version and transport match the CSMS; any OCA certificate identifies the same product/software scope and required profiles | Certificate number and listing, supplier declaration, configuration export | ☐ Pass ☐ Fail |
| Endpoint and security | Charger reaches the agreed test URL using the required WebSocket/TLS and authentication settings | Redacted endpoint settings, certificate-chain result, connection log | ☐ Pass ☐ Fail |
| Startup and recovery | CSMS accepts the charger identity; heartbeat/status is visible; reconnect and offline recovery meet the project’s stated target | Timestamped message log and CSMS event record | ☐ Pass ☐ Fail |
| Connector status and authorization | Available, occupied, faulted, and unavailable states display correctly; required RFID/app authorization is accepted or rejected as expected | Test steps, token result, charger and CSMS logs | ☐ Pass ☐ Fail |
| Session and meter records | Start, stop, transaction state, and required meter readings appear in the CSMS with agreed units and timing | Session export and matching meter/message log | ☐ Pass ☐ Fail |
| Faults and remote actions | Required fault notification and each contracted remote command produce the expected charger and backend result | Fault injection or safe test procedure, command response, event log | ☐ Pass ☐ Fail |
| Optional project features | Smart charging, firmware update, reservation, device management, or ISO 15118 works only if explicitly required | Feature-specific test record and profile evidence | ☐ Required ☐ N/A; ☐ Pass ☐ Fail |
| Closure | Open issues have an owner, resolution date, retest result, and approved firmware/configuration baseline | Signed exception list and final approval | ☐ Approved ☐ Hold |
Do not use production credentials in a sample test unless the operator’s security process authorizes it. Record the CSMS test tenant, test date, people responsible, network conditions, and any simulator or adapter used; a result obtained through an adapter is not the same evidence as a direct charger-to-CSMS connection.
What does a real charger-network migration show buyers?
The Eneco–GreenFlux migration shows why buyers should evaluate the actual fleet and firmware mix instead of approving a protocol label. In OCA’s 2025 case study, Eneco moved 3,461 legacy chargers to GreenFlux. The group included OCPP 1.5 SOAP, OCPP 1.5 JSON, and OCPP 1.6 JSON across two charger generations, with protocol customizations accumulated in the former backend. The teams tested representative device groups, planned firmware or configuration remediation, and moved the chargers in phases; OCA reports no systemic outage during the initial cutover. 5
For a buyer facing the same kind of backend change, the decision is not “replace everything with the newest OCPP version.” First inventory model, firmware, OCPP variant, security setup, and required functions. Then select a representative unit from every model/firmware group, run the acceptance card against the target CSMS, resolve mismatches, and approve a controlled pilot with a rollback path before a larger order or migration.
Yirox sourcing decision for a comparable program: treat each model and firmware combination as a separate approval line. Require the supplier or CSMS owner to provide the test record and close any firmware change against the agreed baseline before volume approval. Approve the tested configuration, not a protocol label. 5
How should you choose an OCPP charger for a project?
Start with the CSMS and the function the site needs, then choose a charger configuration that passes the project’s acceptance criteria. The right version is the one the actual backend and firmware can support reliably for the required use—not automatically the newest protocol release.
| Project situation | Selection approach |
|---|---|
| Existing CSMS and installed chargers | Match the CSMS-supported version and required features; test each proposed model and firmware against that live platform |
| New network with no CSMS selected | Shortlist the CSMS and charger together; compare required authorization, monitoring, security, smart charging, and update functions before selecting a version |
| Multi-brand fleet or backend migration | Inventory hardware/firmware cohorts, pilot each representative cohort, retain configuration and rollback records, then move in controlled batches |
| Equipment-only sourcing | Specify OCPP version, transport, target CSMS, required profiles/functions, product firmware baseline, connector/cable configuration, and evidence expected with the sample |
Keep physical fitment separate from software compatibility. Confirm region, connector, cable, voltage/current, and installation requirements in addition to the OCPP card; compare the relevant EV charging cable and connector types.
Conclusion: approve the tested charger-CSMS combination
OCPP gives a charger and CSMS a shared communication protocol, but version support, certified scope, optional functions, firmware, security configuration, and backend behavior still determine whether a project works. Verify certification against the exact product, then test the exact charger–firmware–CSMS combination with recorded results. If you are defining an EV charging product program, share the charger specification for a sourcing review with the target market, OCPP version, intended CSMS, required functions, and physical configuration.
Frequently Asked Questions
What does OCPP stand for?
OCPP stands for Open Charge Point Protocol. It is the communication protocol used between a charging station and a charging station management system.
Can any OCPP charger connect to any OCPP backend?
No. The charger and CSMS need compatible versions, functions, transport and security settings, and configuration. Test the exact model and firmware against the intended CSMS and retain the logs.
Does an OCPP certificate guarantee that every feature works?
No. A certificate identifies a tested version and certification scope. Check the listed product/software and required profiles, then verify project-specific functions and backend integration separately. 2
Is OCPP 2.1 certified in the same way as OCPP 2.0.1?
Do not assume that a published version and a certification or test program have identical coverage. OCA’s OCTT page currently lists conformance test cases for OCPP 1.6 and 2.0.1 and says 2.1 coverage is being extended; confirm current product-specific evidence before contracting. 4
Does OCPP handle EV driver payments?
OCPP can carry authorization and transaction information, but it is not by itself a complete payment processor, roaming service, or driver app. Confirm those integrations with the CSMS and payment providers.
What should be written into an OCPP charger purchase order?
State the OCPP version and transport, exact model and firmware, target CSMS, required functions, security responsibilities, certification evidence, sample acceptance tests, and how firmware changes will be controlled. Attach the completed acceptance card to the approved sample record.
References
[1] Open Charge Alliance. “OCPP Protocols.” Accessed September 2026.
[2] Open Charge Alliance. “Certification OCPP 2.0.1.” Accessed September 2026.
[3] Open Charge Alliance. “Updated certification program 2.0.1.” December 11, 2025.
[4] Open Charge Alliance. “Test Tool (OCTT).” Accessed September 2026.
[5] Open Charge Alliance. “Migrating Charging Stations.” November 2025.
