OCPP 2.1 is an evolutionary step, not another breaking change.
OCPP 2.1 is available and builds directly on OCPP 2.0.1. The decisive difference compared to earlier version jumps: 2.1 is fully backwards compatible with 2.0.1. A charge point running 2.0.1 can operate against a 2.1 backend, and the new functional blocks are additive, not mandatory. Anyone who has implemented the 2.0.1 foundations cleanly gets a path to 2.1 without an architectural break.
This stands in sharp contrast to the step from OCPP 1.6 to 2.0.1. Those two versions are not compatible: a different transaction model, a device model instead of configuration keys, a different message structure, different security profiles. Between 1.6 and 2.0.1 lies a real migration; between 2.0.1 and 2.1 lies a controlled upgrade.
In projects, this is exactly where we see the most confusion: many operators read OCPP 2.1 as another forced rebuild following the 1.6-to-2.0.1 pattern. It is not. The realistic question is not whether 2.1 creates a new break, but how the existing fleet gets onto the 2.0.1 path in an orderly way, from which 2.1 becomes reachable.
The key additions: bidirectionality, DER and robust offline operation.
The most visible building block is bidirectional charging. OCPP 2.1 can control discharge setpoints and bidirectional charging profiles towards the charge point, while ISO 15118-20 handles the negotiation between vehicle and charge point. Only this combination makes V2G controllable as an end-to-end chain from backend to vehicle, including Plug&Charge based on ISO 15118-20.
The second focus is the integration of DER, distributed energy resources. Charge points and sites are treated as controllable resources in interaction with generation, storage and grid requirements. For operators with PV, battery storage or grid-service obligations, the protocol moves much closer to the energy side, which until now was often handled in proprietary side systems.
The third focus is offline operation. OCPP 2.1 defines transaction behavior during backend connectivity loss more robustly, including orderly resynchronization afterwards. Added to this is payment terminal integration for ad-hoc payment, which directly supports the AFIR requirements that have applied to public charging infrastructure since 2024.
- Bidirectional charging (V2G) in combination with ISO 15118-20.
- DER control for generation, storage and controllable loads on site.
- More robust offline transactions with defined resynchronization.
- Payment terminal integration for ad-hoc payment in line with AFIR.
- Extended tariff and cost information towards the driver.
For an OCPP 1.6 fleet, the path leads through 2.0.1.
Anyone operating a 1.6 fleet today cannot jump straight to 2.1. OCPP 1.6 and 2.0.1 are not compatible, and 2.1 requires the 2.0.1 foundation. Concretely, this means: charge point firmware must support 2.0.1 or 2.1 natively, the backend must process the new transaction model based on TransactionEvent, and certificate and security processes must be moved to the new profiles.
For operators of existing fleets, the 2.1 question therefore becomes a hardware and firmware question first. A share of the 1.6 devices in the field will never receive a 2.0.1 update. For those charge points the honest answer is: they keep running on 1.6 as long as they serve their purpose, and get replaced during regular hardware renewal, not force-migrated before that.
In practice, this produces mixed fleets of 1.6, 2.0.1 and 2.1 for years. That is not a planning failure but the normal case. What matters is that new procurement does not extend the path any further, and that the central architecture can handle this mix without maintaining separate special processes for every version.
A sound adoption strategy is trigger-driven, not version-driven.
Upgrading purely for the version number rarely pays off. Solid triggers come from three directions: regulatory, because AFIR has required data provision and ad-hoc payment since 2024 and new public AC charge points in the EU must be ISO 15118-capable since January 2026; commercial, because V2G and flexibility use cases cannot be modelled cleanly without 2.1 and ISO 15118-20; and operational, because more robust offline behavior reduces real support costs.
This leads to a clear sequence: new sites and tenders should make OCPP 2.0.1 mandatory and list 2.1 capability as a criterion. The backend or broker side can be lifted to 2.1 early, because backwards compatibility with 2.0.1 makes that upgrade low-risk. The 1.6 fleet, by contrast, is only touched when there is a real trigger, such as hardware renewal, security requirements or concrete new functionality.
- New tenders: OCPP 2.0.1 mandatory, 2.1 capability as an evaluation criterion.
- Lift central systems to 2.1 early, since it is backwards compatible with 2.0.1.
- Plan for ISO 15118 capability on new public AC charge points, required since January 2026.
- Migrate the 1.6 fleet only on real triggers, not across the board.
- Pilot V2G and DER use cases at individual sites first.
An OCPP broker buffers between the existing fleet and the target picture.
The real challenge of the coming years is not OCPP 2.1 itself, but operating several protocol worlds in parallel. An OCPP broker terminates the connections of all charge points, whether 1.6, 2.0.1 or 2.1, normalizes the differences and presents downstream systems with a consistent model. The central CPMS then does not have to master every dialect at once.
This buffer layer is particularly valuable during phased adoption: charge points stay connected while the backend is lifted to 2.1. New 2.1 functions such as DER control or bidirectional profiles can be tested against individual sites first, while the rest of the fleet keeps running unchanged. Messages can be mirrored, filtered and fully logged, so every migration phase remains auditable.
These transition phases are exactly where a broker layer with modular CPMS building blocks is the right tool: running mixed fleets reliably, taking the 2.0.1 path in an orderly fashion, and activating 2.1 features when the use case genuinely requires them.