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, CSMS ecosystem, hardware roadmap, and your team’s expertise all matter.
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 relevant today — 1.6, 2.0.1, and 2.1 — 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’re 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 |
| Installed base (2026) | Dominant — the large majority of fielded chargers | Growing fast, standard for new installs | Early — pilot and first-shipment stage |
| Recommended for new? | No | Yes (today’s choice) | Yes if hardware + CSMS support is in place |
The high-level pattern: 1.6 is what’s installed, 2.0.1 is what you should ship today, 2.1 is what shipped in January 2025 and is the migration target for the next 1-2 years.
OCPP 1.6 — the workhorse
What’s good about it
It works. It’s deployed everywhere. The CSMS market understands it deeply, hardware OEMs have decade-old firmware that’s been hardened by real-world use, and integration engineers can debug it in their sleep. Documentation, tooling, simulators, training — all abundant. Large public networks on both sides of the Atlantic still run enormous 1.6 fleets: think of the AC destination and workplace chargers behind networks like ChargePoint and Blink in North America, or SHELL Recharge and Allego across Europe. That installed base is exactly why 1.6 is not going away quickly.
If you’re managing an existing fleet on 1.6, there’s no rush to migrate. The protocol is stable, the bugs are known, and the later security extensions bring it to a workable security 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 (charger sent StopTransaction but CSMS never got it) is messy.
The data model. The MeterValue object can carry a wide variety of measurands (energy, power, voltage, current, temperature, SOC, etc.), but the format is verbose and not strongly typed in the spec. Different OEMs report different measurands at different intervals, and CSMSes end up with 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, signed firmware updates, etc. They work, but they’re optional and not consistently implemented. A vanilla OCPP 1.6 connection has zero security.
ISO 15118 / Plug & Charge integration is awkward. OCPP 1.6 doesn’t have first-class support for the certificate flows that Plug & Charge requires. It’s been retrofitted but it’s 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 has multiple independent charging points) are awkward to model.
Should you start new on 1.6?
In 2026: no, unless your CSMS literally only supports 1.6 (a few legacy platforms do). If your CSMS supports 2.0.1, that’s where new deployments should start.
When should you migrate existing 1.6 fleets?
There’s no urgent deadline. Most CPOs have a plan to migrate over 3-5 years as chargers come up for firmware refresh anyway. The migration is real engineering work — your CSMS, your monitoring, your data pipelines all need to handle both versions during the transition.
A common pattern: new chargers ship 2.0.1, existing chargers migrate when they’re due for a firmware update for unrelated reasons, and the fleet shifts gradually over a few years until only the oldest, hardest-to-upgrade hardware remains on 1.6.
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 what they were doing in 2015.
Native security. TLS is assumed. Certificate-based mutual authentication is the default profile for production. The first message on every connection — the BootNotification (coming soon) — already carries a richer, structured device identity than its 1.6 equivalent. Signed messages, signed firmware updates, key rotation — all in the core spec, not as a separate document.
Unified TransactionEvent. Instead of separate StartTransaction/StopTransaction/MeterValues messages, there’s one TransactionEvent message with an event type (Started, Updated, Ended). Reconciliation is easier, the state machine is clearer.
Rich device model. A charger isn’t just a flat list of connectors — it’s a hierarchy of Controllers, EVSEs, and Connectors, with components (DisplayController, AlignedDataController, etc.) and variables. You can introspect what a charger is and configure it richly via SetVariables / GetVariables. This is genuinely better than 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 via standard messages. The Authorize message understands ISO 15118 identifiers.
Better smart charging. ChargingProfile types are clearer. Composite schedules can be queried. The relationship between local energy management and OCPP-pushed profiles is defined.
Multi-EVSE support. Chargers with multiple independent EVSEs (e.g. a large DC cabinet with 4 outlets that share a power module pool) are first-class.
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.
The migration tooling is uneven. Hardware OEMs vary in how cleanly they implemented 2.0.1. Some have great support; some have buggy first-generation 2.0.1 firmware that’s worse than their mature 1.6 firmware.
CSMS ecosystem is still catching up in some segments. Major platforms support 2.0.1 well, but if you use a smaller or older CSMS, check first. There are CSMSes in production today that only support 1.6.
Some OCPP 1.6 mental models don’t transfer. Engineers who know 1.6 well sometimes write 2.0.1 code that’s “1.6 with new names” instead of using the new device model and TransactionEvent properly. Plan training.
Should you start new on 2.0.1?
Yes. This is the right answer for most new EV charging deployments in 2026. Hardware support is mature — DC fast-charger OEMs such as Tritium and BTC Power in North America and ABB and Alpitronic in Europe ship production 2.0.1 firmware, and the major CSMS platforms support it — and you avoid a near-term migration.
OCPP 2.1 — released, adoption growing
What’s new
OCPP 2.1’s changes from 2.0.1 are incremental but meaningful, and — 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, supports sessions where energy flows from the vehicle back to the grid, home, or building (V2G / V2H / V2B). 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 initially at two- and three-wheelers as well as cars — relevant in markets where swapping is common.
Ad hoc payment options. Support for prepaid cards, ad hoc credit/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.
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
Hardware support is very early. As of 2026, only a handful of OEMs have shipping 2.1 firmware, and most of those are alpha or beta. Mass-market 2.1 hardware is 1-2 years out.
CSMS support is even earlier. A few CSMS platforms support 2.1 as a feature flag. Production-grade 2.1 CSMSes are a small set.
Standards interplay still settling. 2.1’s V2G provisions depend on ISO 15118-20 vehicle support, which is also early. The full V2G stack (vehicle + charger + OCPP + grid services framework) is in pilot stages, not commercial.
Should you start new on 2.1?
Probably not, unless you’re specifically working on V2G or another 2.1-specific feature. The right plan for most operators in 2026 is to deploy 2.0.1, design your CSMS for clean 2.0.1 → 2.1 migration, and adopt 2.1 when your hardware supplier supports it well.
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’re choosing OCPP version for a new project, walk this list in order.
- What does your CSMS support? If it only supports 1.6, you’re 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’re still bringing up 2.0.1, maybe 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 — accept the bleeding-edge tradeoffs.
- Is this a long-term deployment (5+ years)? Lean toward newer (2.0.1) to delay the next migration.
- Default: 2.0.1. It’s the right answer for most.
If you’re migrating an existing fleet:
- Start with new installs going onto 2.0.1. Cleaner than retrofitting.
- Identify your “easy wins” — chargers that have firmware support for 2.0.1 and are due for an update anyway. Migrate them opportunistically.
- Use dual-version CSMS operation. Run 1.6 and 2.0.1 in parallel for years if needed. Don’t force a flag day.
- Migrate the hard ones last. Older hardware without 2.0.1 firmware support comes off OCPP 1.6 only when it comes off the network entirely (decommissioning).
What about OCPP 1.5 or earlier?
If you have OCPP 1.5 chargers still in the field, replace them. The hardware is at least a decade old. Modern CSMSes either don’t support 1.5 or support it grudgingly. The cost of operating dropping legacy hardware will exceed the cost of replacement.
OCPP 1.2 and earlier — these were essentially pilot-grade. Anything that old in a production fleet is a maintenance liability.
One myth to clear up
“OCPP version determines roaming capability.” It doesn’t. OCPP is between charger and CSMS. Roaming is between CSMS and roaming partners via OCPI or other roaming protocols. Your OCPP version doesn’t determine your OCPI version, and vice versa. A CPO running a mixed OCPP 1.6 + 2.0.1 fleet can still roam via OCPI 2.2.1 cleanly 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: 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/bidirectional charging, DER coordination, battery-swap support, and ad hoc payment options on top of 2.0.1 — and is backward compatible with it, 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 — no flag day.
- Your OCPP version does not dictate your roaming: OCPP is charger-to-CSMS, while roaming lives at the CSMS layer over OCPI.
OCPP 1.6 is the past you’re still living with and shouldn’t ignore. OCPP 2.0.1 is the present you should be building on. OCPP 2.1 shipped in January 2025 and is the next migration target — most CPOs are evaluating it now, planning rollout over 12-24 months as their hardware vendors and CSMS platforms reach parity.
The biggest mistake in OCPP version decisions is to optimize purely for “newest.” The biggest mistake in operations is to never plan migrations and end up with a legacy stack you can’t move off. Pick 2.0.1 today, plan the 2.1 migration in parallel, and gradually decommission 1.6 over the next few years.