Stay on 1.6
Only when you are locked to a back office or installed base that cannot move yet.
It works and it is everywhere, but it has no security in the core spec, no device model and no Plug & Charge. Treat it as a floor, not a target.
Resources · Tools · OCPP
OCPP 1.6, 2.0.1 or 2.1? The version you build on decides what security, smart charging and Plug & Charge you get for free, and how much rework a later move costs. This matrix lays the three side by side and gives a straight recommendation.
The matrix
The differences that actually change a build decision - security, the device model, smart charging, Plug & Charge and bidirectional power.
| Dimension | OCPP 1.6 | OCPP 2.0.1 | OCPP 2.1 |
|---|---|---|---|
| Status | Mature, most widely deployed | Current standard for new builds | Latest release, superset of 2.0.1 |
| Messaging | JSON over WebSocket (1.6J) or SOAP | JSON over WebSocket | JSON over WebSocket |
| Security | No security in the core spec; TLS and profiles added by a later whitepaper | Built-in security profiles: TLS, key management, signed firmware | Inherits 2.0.1 security, extended for new features |
| Device model | None - limited standard configuration | Full device model for configuration, monitoring and diagnostics | Extended device model |
| Smart charging | Basic charging profiles | Richer profiles and load management | Advanced energy management and local control |
| ISO 15118 / Plug & Charge | Not supported natively | Plug & Charge with ISO 15118-2 | Extended for ISO 15118-20 |
| Bidirectional / V2X | No | No | Yes - vehicle-to-grid and DER management |
| Best for | Existing fleets tied to a 1.6 back office | New chargers needing security and Plug & Charge | V2X, dynamic energy management, future-proofing |
For information only, and simplified for a build decision - always work from the published OCPP specifications for implementation detail.
The recommendation
For most new chargers the answer is 2.0.1, with 2.1 where bidirectional or advanced energy management is on the roadmap. 1.6 is a compatibility floor, not a target.
Only when you are locked to a back office or installed base that cannot move yet.
It works and it is everywhere, but it has no security in the core spec, no device model and no Plug & Charge. Treat it as a floor, not a target.
The right default for a new charger today.
You get the security profiles, the device model and Plug & Charge that modern procurement and UK and EU regulation increasingly expect.
When bidirectional charging, ISO 15118-20 or advanced local energy management are on your roadmap.
A superset of 2.0.1, so a 2.0.1 design is a clean stepping stone rather than a detour.
Migrating from 1.6
The step from 1.6 to 2.x is a data-model change, not a version bump. These are the four things to get right.
Decide 2.0.1 or 2.1 from your feature roadmap, not from what the current back office happens to speak.
The jump from 1.6 is a data-model shift. Map your configuration, metering and diagnostics onto the 2.x device model early.
Adopt the security profiles: TLS, certificate management and signed firmware updates, rather than bolting them on later.
Run a back office that speaks both during rollout, and stage firmware so field units migrate without a flag day.
Take it with you
The comparison above is complete and free to read here, with nothing to fill in. If you would rather have a copy to circulate or take into a planning meeting, we will email you one.
Get the decision matrix by emailGet in touch
Tell us what you're building and our engineers will help you scope the fastest, lowest-risk route to market. A conversation directly with the people who design the charging modules.