OCPP 2.0 is the most significant update the EV charging protocol has seen since the standard was first published. If you are building software that talks to EV charging stations — a fleet management platform, a demand response system, a property management tool — the jump from OCPP 1.6 to 2.0 is not just a version bump. It changes how authentication works, how device management is structured, and how you think about the security model of your entire integration.
This walkthrough covers what changed, what it means for developers building on top of OCPP, and where teams typically get stuck.
What actually changed between 1.6 and 2.0
The headline changes in OCPP 2.0 are worth understanding before you write a line of code.
| Area | OCPP 1.6 | OCPP 2.0 |
|---|---|---|
| Security | Optional TLS, basic auth | Mandatory TLS 1.2+, security profiles 1-3 |
| Device management | Limited configuration keys | Full device model with typed components and variables |
| Smart charging | Charging profiles, basic schedule | ISO 15118 support, bidirectional charging (V2G) |
| Transaction model | Single transaction lifecycle | Revised transaction model with multiple EVSE states |
| Message format | JSON over WebSocket | JSON over WebSocket (with schema validation) |
The transport layer is the same — JSON over WebSocket — so the basic connectivity model transfers. But the message structure, the device model, and especially the security requirements are substantially different.
Security profiles: what they mean and which you need
OCPP 2.0 defines three security profiles, and the one you implement determines what your integration can connect to.
Profile 1 is basically OCPP 1.6 security — basic HTTP authentication over TLS. Acceptable for development environments and some legacy deployments, but not what modern public charging networks expect.
Profile 2 adds client-side certificate authentication. The charging station presents a certificate to the CSMS during the TLS handshake. This is the baseline for most utility-connected and fleet deployments in 2024. Implementing Profile 2 means your server needs to handle certificate issuance, renewal, and revocation for each charging station. Not trivial.
Profile 3 adds end-to-end message signing on top of Profile 2. Individual OCPP messages are signed with the charging station's private key, giving you tamper detection at the application layer. Required for some regulatory frameworks and high-security fleet contexts.
In our experience, teams underestimate the certificate management infrastructure required for Profile 2. It is not just TLS configuration — it is a PKI problem that touches provisioning workflows, renewal automation, and revocation handling.
The device model: variables all the way down
OCPP 1.6 had a flat list of configuration keys — strings like HeartbeatInterval and MeterValuesSampledData. OCPP 2.0 replaces this with a hierarchical device model built around Components and Variables.
A charging station in OCPP 2.0 is modeled as a tree: the station has Components (like ChargingStation, EVSE, Connector, and SmartCharging), and each Component has Variables (like Available, MaxChargingCurrent, PhaseRotation). Getting or setting a configuration value means traversing this tree with a GetVariables or SetVariables message.
The device model is more expressive than OCPP 1.6's key list — it can represent the actual physical structure of a multi-port charging station. But it also means your CSMS needs to understand the device model structure for each charger make and model it connects to, since vendors extend the base spec with custom components and variables.
Transaction handling: what broke between versions
The transaction lifecycle changed enough in OCPP 2.0 that code ported directly from 1.6 will have subtle bugs. The most important changes:
- EVSE-level state — In 2.0, status is tracked per EVSE (the physical connector unit), not per charging station. A station with four ports maintains four EVSE state machines simultaneously.
- TransactionEvent replaces StartTransaction/StopTransaction — The 1.6 pattern of a single start and stop message is replaced by a continuous event stream (
Started,Updated,Ended) that lets the CSMS track mid-session events like cable unplug, SoC updates, and cost accumulation. - Offline transaction handling — OCPP 2.0 specifies clearer semantics for transactions that start while the charger is offline and sync when connectivity is restored.
Smart charging and ISO 15118
One of the major additions in OCPP 2.0 is proper support for ISO 15118 — the standard that governs plug-and-charge authentication and vehicle-to-grid communication. If you are building software for bidirectional charging or demand response programs that need to signal directly to the vehicle, OCPP 2.0 plus ISO 15118 is the path.
The practical implication for developers: your CSMS needs to be able to relay ISO 15118 messages between the vehicle and the backend. The charger acts as a bridge. OCPP 2.0 defines the Get15118EVCertificate and SignCertificate messages that support this relay. Implementing it correctly requires your backend to participate in the Plug and Charge PKI certificate chain, which is a meaningful integration project on its own.
Where teams actually get stuck
Based on what we have seen in the field, the most common failure points are worth naming directly.
Certificate management at scale. Getting a single charger to authenticate with Profile 2 is not the hard part. Managing certificate renewal for a fleet of 500 chargers across multiple sites, with different expiry dates and different provisioning flows, is where the operational complexity bites.
Device model variance across vendors. The OCPP 2.0 spec defines a base device model, but vendors extend it liberally. A ChargePoint station and a Delta charger will have different component trees, different custom variables, and different behaviors for edge cases like partial failures. Your CSMS code needs to handle this variance.
Testing against real hardware. OCPP 2.0 compliance is not binary. A charger can be spec-compliant while having idiosyncratic behavior in edge cases that only appear in production. Sandbox environments with simulated OCPP chargers cover the happy path, but they miss vendor-specific quirks.
The chargers that cause the most integration headaches are usually not broken — they are compliant with the spec while interpreting the ambiguous parts differently than you expected.
OCPP 2.0 is a better protocol than 1.6. The security model is sounder, the device model is more expressive, and the smart charging capabilities open up use cases that were not practical before. But better does not mean easy. The implementation surface is larger, the security requirements are harder, and the vendor variance is real. Build time estimates accordingly, and test against actual hardware before you ship.
