If you operate or build EV charging stations, you eventually have to make a version decision: which OCPP do you commit to? The answer is more nuanced than “always pick the newest”, because the installed base, the CSMS ecosystem, the hardware roadmap, and your team’s expertise all pull in different directions.
The heart of the question is usually OCPP 1.6 vs 2.0.1. That is the real jump, the one that changes the transaction model, the device model, and security. OCPP 2.1 then layers V2G and other additions on top of 2.0.1. This article compares all three versions that matter today, the way a CPO or firmware team actually weighs them, and ends with a decision framework you can apply to your own project. If you are new to the protocol, start with what OCPP is and does before weighing versions.
The big picture
| Aspect | OCPP 1.6 | OCPP 2.0.1 | OCPP 2.1 |
|---|---|---|---|
| Released | 2015 | 2020 (2.0 in 2018, .1 with corrections) | January 2025 |
| Transport | WebSocket + JSON | WebSocket + JSON | WebSocket + JSON |
| Security model | Add-on security extension | Built-in | Refined |
| Device model | Flat / minimal | Rich, hierarchical | Refined |
| Transaction model | StartTransaction + StopTransaction | Unified TransactionEvent | Unified TransactionEvent |
| ISO 15118 integration | Not native | Native | Refined |
| Smart charging | Basic | Expanded | V2G additions |
| Where you meet it (2026) | The version most fielded hardware was commissioned against | The default specification for new installs | Pilot and first-shipment stage |
| Recommended for new? | No | Yes (today’s choice) | Yes if hardware and CSMS support is in place |
The high-level pattern: 1.6 is what is installed, 2.0.1 is what you should ship today, and 2.1 is what shipped in January 2025 and is the migration target you plan for next.
OCPP 1.6: the workhorse
What’s good about it
It works. The CSMS market understands it deeply, hardware OEMs have decade-old firmware hardened by real-world use, and integration engineers can debug it in their sleep. Documentation, tooling, simulators, and training are all abundant.
The reason 1.6 persists is structural rather than technical. A charging station is a capital asset with a ten-to-fifteen-year service life, and it speaks whatever protocol it was commissioned against unless someone pays to change that. Every AC destination and workplace charger installed between 2015 and 2021 is a 1.6 endpoint that still has years of life in it. That arithmetic, not anyone’s preference, is why your CSMS will keep a 1.6 code path for a long time.
If you are managing an existing fleet on 1.6, there is no rush to migrate. The protocol is stable, the bugs are known, and the later security extensions bring it to a workable baseline if you implement them.
What’s not great
A few things age poorly.
The transaction model. StartTransaction and StopTransaction are separate messages. Between them, MeterValues messages flow. The CSMS has to stitch them together by transaction ID. Reconciliation in the face of network failures, where the charger sent StopTransaction but the CSMS never received it, is messy.
The data model. The MeterValue object can carry a wide variety of measurands: energy, power, voltage, current, temperature, state of charge. But the format is verbose and not strongly typed in the spec. Different OEMs report different measurands at different intervals, and CSMSes end up carrying per-vendor parsing logic.
Security as a bolted-on extension. The OCPP 1.6 Security Whitepaper added profiles for TLS, basic auth, certificate-based mutual TLS, and signed firmware updates. They work, but they are optional and not consistently implemented. A vanilla OCPP 1.6 connection has no security at all. The security profiles deep-dive covers what each profile actually requires.
ISO 15118 and Plug & Charge integration is awkward. OCPP 1.6 has no first-class support for the certificate flows Plug & Charge requires. It has been retrofitted, but it is clunky.
Single-connector bias. OCPP 1.6 assumes a charger has connectors numbered from 1 upward, with connector 0 representing the whole charger. Multi-EVSE chargers, where one cabinet holds several independent charging points, are awkward to model.
Should you start new on 1.6?
In 2026, no. The only exception is a CSMS that genuinely cannot speak 2.0.1. If your CSMS supports 2.0.1, that is where new deployments should start.
When should you migrate existing 1.6 fleets?
There is no deadline, and a forced migration is rarely worth funding on its own. The pattern that works is to attach the version change to work that was already happening: new chargers ship 2.0.1, existing chargers migrate when they are due for a firmware update for unrelated reasons, and the fleet shifts gradually until only the oldest, hardest-to-upgrade hardware remains on 1.6.
Budget for the fact that this is real engineering work. Your CSMS, your monitoring, and your data pipelines all have to handle both versions for the duration of the transition, which is measured in years rather than sprints.
OCPP 2.0.1: the modern choice
What’s good about it
A lot, honestly. This is what 1.6 should have been if anyone had known in 2015 what the industry would need.
Native security. TLS is assumed. Certificate-based mutual authentication is the default profile for production. The first message on every connection, the BootNotification, already carries a richer, structured device identity than its 1.6 equivalent. Signed messages, signed firmware updates, and key rotation are in the core spec rather than a separate document.
Unified TransactionEvent. Instead of separate StartTransaction, StopTransaction, and MeterValues messages, there is one TransactionEvent message with an event type: Started, Updated, or Ended. Reconciliation is easier and the state machine is clearer.
Rich device model. A charger is no longer a flat list of connectors. It is a hierarchy of Controllers, EVSEs, and Connectors, with components and variables you can introspect and configure via SetVariables and GetVariables. The device model deep-dive explains why this beats 1.6’s flat configuration namespace.
First-class ISO 15118. Plug & Charge certificate flows are integrated. The CSMS can install, update, and delete contract certificates on the charger with standard messages, and the Authorize message understands ISO 15118 identifiers.
Better smart charging. ChargingProfile types are clearer, composite schedules can be queried, and the relationship between local energy management and CSMS-pushed profiles is actually defined. See smart charging in practice.
Multi-EVSE support. Chargers with several independent EVSEs, such as a large DC cabinet with four outlets sharing a power module pool, are first-class rather than a modelling workaround.
What’s not great
It’s bigger. Many more message types than 1.6 and a more complex device model. Implementing a 2.0.1 charger or CSMS from scratch is more work than 1.6 was.
Implementation quality varies by OEM. A first-generation 2.0.1 firmware from a vendor whose 1.6 firmware has been in the field for eight years is not automatically the better choice. Ask how long the 2.0.1 build has been shipping, and test it yourself before you commit a rollout to it.
CSMS support is not universal. Verify it rather than assuming it. There are platforms in production today that only speak 1.6, and the question to put to a vendor is not “do you support 2.0.1” but “which 2.0.1 functional blocks do you support, and which are on the roadmap”.
Some 1.6 mental models don’t transfer. Engineers who know 1.6 well sometimes write 2.0.1 code that is “1.6 with new names” instead of using the device model and TransactionEvent properly. Plan for training, not just implementation.
Should you start new on 2.0.1?
Yes. This is the right answer for most new EV charging deployments in 2026. The specification is stable, the tooling exists, and you avoid a near-term migration. Confirm two things before you commit: that your chosen OEM has 2.0.1 firmware that has been shipping long enough to be trusted, and that your CSMS supports the functional blocks you actually need.
OCPP 2.1: released, adoption growing
What’s new
OCPP 2.1’s changes from 2.0.1 are incremental but meaningful. Importantly, the Open Charge Alliance built 2.1 to be backward compatible with 2.0.1, so application logic written for 2.0.1 keeps working.
Bidirectional power flow (V2G). A dedicated functional block for bidirectional charging, built on ISO 15118-20, supporting sessions where energy flows from the vehicle back to the grid, home, or building. This is the flagship 2.1 addition.
Distributed energy resources and smarter smart charging. Better tools for coordinating charging with local solar, storage, and grid signals, and for optimizing energy distribution across a group of charging stations.
Battery swap support. New provisions for battery swap stations, aimed at two- and three-wheelers as well as cars, which matters in markets where swapping is an established model.
Ad hoc payment options. Support for prepaid cards, ad hoc credit and debit card payments, and secure dynamic QR-code payment flows initiated at the station.
Improved certificate management. Plug & Charge certificate lifecycle handling is refined.
Tariff representation on the charger. A charger can hold a structured tariff and display pricing to the driver, which previously sat outside OCPP’s scope entirely.
Refined device model and diagnostics. Device-model components are clarified, with additions for emerging hardware patterns and more granular logging and health reporting.
What’s not great yet
The stack below it is still arriving. 2.1’s V2G provisions depend on ISO 15118-20 support in the vehicle, which is itself early. A complete V2G deployment needs the vehicle, the charger, the CSMS, and a grid-services framework to line up, and that is a four-way dependency rather than a protocol decision.
Support is a question to ask, not to assume. As of August 2026, treat both “our hardware supports 2.1” and “our CSMS supports 2.1” as claims to verify against a specific firmware version and a specific functional block, not as roadmap statements. Ask for the conformance test report.
You may be an early adopter. That is a legitimate choice if V2G is your product. It is an expensive accident if you only wanted the newest number in the spec sheet.
Should you start new on 2.1?
Probably not, unless you are specifically working on V2G or another 2.1-only feature. The right plan for most operators in 2026 is to deploy 2.0.1, design your CSMS for a clean 2.0.1 to 2.1 migration, and adopt 2.1 when your hardware supplier supports it properly.
A decision framework
The decision for a new deployment usually collapses to a short flow:
flowchart TD
A[New deployment] --> B{CSMS supports 2.0.1?}
B -->|No| C[Ship 1.6<br/>then fix CSMS]
B -->|Yes| D{Need V2G<br/>or 2.1 feature?}
D -->|No| E[Ship 2.0.1]
D -->|Yes| F{Hardware and CSMS<br/>2.1-ready?}
F -->|Yes| G[Ship 2.1]
F -->|No| E
style E fill:#d1fae5,stroke:#059669
style G fill:#dbeafe,stroke:#2563ebIf you are choosing an OCPP version for a new project, walk this list in order.
- What does your CSMS support? If it only supports 1.6, you are on 1.6 until you fix that.
- What does your hardware supplier ship today? If their 2.0.1 firmware is mature, prefer it. If they are still bringing 2.0.1 up, wait or pick a different OEM.
- Do you have a V2G or advanced smart-charging use case that needs 2.1? If yes, you may need 2.1, and you accept the bleeding-edge tradeoffs that come with it.
- Is this a long-term deployment of five years or more? Lean newer to delay the next migration.
- Default: 2.0.1. It is the right answer for most projects.
If you are migrating an existing fleet:
- Start with new installs going onto 2.0.1. Cleaner than retrofitting.
- Identify your easy wins. Chargers with 2.0.1 firmware support that are due for an update anyway migrate at almost no marginal cost.
- Use dual-version CSMS operation. Run 1.6 and 2.0.1 in parallel for years if you need to. Do not force a flag day.
- Migrate the hard ones last. Older hardware without 2.0.1 firmware support comes off 1.6 only when it comes off the network entirely.
What about OCPP 1.5 or earlier?
If you have OCPP 1.5 chargers still in the field, plan their replacement. The hardware is at least a decade old, and modern CSMSes either do not support 1.5 or support it grudgingly. At that age the maintenance and truck-roll cost of keeping them alive tends to overtake the cost of replacing them, and each one is also a security surface you cannot patch.
OCPP 1.2 and earlier were essentially pilot-grade. Anything that old in a production fleet is a liability rather than an asset.
One myth to clear up
“OCPP version determines roaming capability.” It does not. OCPP runs between charger and CSMS. Roaming runs between CSMS and roaming partners via OCPI or another roaming protocol. Your OCPP version does not determine your OCPI version, and the reverse is equally untrue. A CPO running a mixed OCPP 1.6 and 2.0.1 fleet can roam over OCPI 2.2.1 perfectly well, because the OCPI relationship lives at the CSMS layer, above the OCPP details. For how these protocols divide the stack, see OCPI vs OCPP vs ISO 15118.
Key takeaways
- The real jump is OCPP 1.6 vs 2.0.1. Version 2.0.1 unifies transactions into
TransactionEvent, adds a hierarchical device model (Station, EVSE, Connector), bakes in TLS and security profiles, and integrates ISO 15118 Plug & Charge natively. - OCPP 2.1 (January 2025) layers V2G and bidirectional charging, DER coordination, battery-swap support, and ad hoc payment options on top of 2.0.1. It is backward compatible, so 2.0.1 work carries forward.
- For a new deployment in 2026 the default is 2.0.1, unless you have a specific V2G or other 2.1-only need and matching hardware and CSMS support.
- Migrate existing 1.6 fleets opportunistically, with dual-version CSMS operation and no flag day.
- Your OCPP version does not dictate your roaming. OCPP is charger-to-CSMS, and roaming lives at the CSMS layer over OCPI.
OCPP 1.6 is the past you are still living with and cannot ignore. OCPP 2.0.1 is the present you should be building on. OCPP 2.1 shipped in January 2025 and is the migration target you plan for rather than the one you jump to.
The biggest mistake in OCPP version decisions is optimizing purely for “newest”. The second biggest is never planning a migration at all and waking up on a stack you cannot move off. Pick 2.0.1 today, design so that 2.1 is an upgrade rather than a rewrite, and let 1.6 retire with the hardware that speaks it.