Your charging network is probably stuck on OCPP 1.6, and the exit just got more interesting

tl;dr. Most of Europe's deployed EV chargers still speak OCPP 1.6, a protocol designed for the connect-charge-stop era. OCPP 2.0.1 has been ratified since 2020 and became an IEC international standard in 2024, and OCPP 2.1, released in January 2025, layers V2G and distributed energy resource control on top of it. The migration everyone deferred has stopped being optional: security audits, ISO 15118 Plug and Charge, smart charging that actually works, and public funding requirements are all pulling in the same direction. The real question in 2026 is no longer whether to leave 1.6 but whether to step through 2.0.1 or build straight for 2.1. Here is how to think about it.

OCPP 2.0.1 has been around long enough to be a teenager's older sibling. Most of the network is still parenting the toddler version.

If you operate charge points, build charging hardware, or write the management software behind either, you already know the uncomfortable shape of this: the industry standardized its future years ago and then mostly declined to move into it. The interesting part is why, and what has changed recently that finally breaks the deadlock.

The version gap in plain language

OCPP 1.6, and specifically its JSON-over-WebSocket flavor 1.6J, is the protocol that built the first generation of European charging networks. It does the basics reliably: a charger connects to a central system, sessions start and stop, meter values flow, remote commands work. For the era of "put AC chargers in parking lots and bill for kilowatt hours," it was enough, which is exactly why it is everywhere.

What it lacks is everything the market now wants. Security first: 1.6 has no mandatory transport encryption, and its security model is thin enough that a modern audit of a plaintext WebSocket fleet is not a comfortable meeting. Device modeling second: 1.6 sees a charger as a flat object, while 2.0.1 models the station, each EVSE, and each connector as a hierarchy you can address individually, which matters enormously once you operate multi-outlet DC hubs rather than single wallboxes. Smart charging third: 1.6 offers static charging profiles, simple power caps in time windows, where 2.0.1 brings a composite schedule engine that merges competing constraints, the site limit, the grid signal, the tariff, the user preference, and applies the safest result. And the headline feature: 2.0.1 is the version with real ISO 15118 support, the standard behind Plug and Charge, where the car authenticates itself and the cable is the whole user experience.

Then, in January 2025, OCPP 2.1 arrived, and it changed the strategic picture more than the technical one. Technically it is a true superset of 2.0.1: everything in 2.0.1 carries forward unchanged, new messages are added on top for vehicle-to-grid operation, distributed energy resource control, and related grid-facing capability, and the protocol negotiates versions so a 2.1 system falls back gracefully to 2.0.1 peers. Strategically, the OCPP family also gained something 1.6 never had: formal international standardization, with 2.0.1 published as an IEC standard in 2024 and 2.1 following into the IEC framework. That sounds bureaucratic and is actually the unlock, because an IEC number is something utilities, regulators, and public tenders can mandate by reference. Voluntary industry conventions get adopted when convenient. IEC standards get written into procurement.

Why the migration stalled for years

The gap between ratification and adoption was never really technical stubbornness. It was three rational hesitations stacked on top of each other.

The first is that 2.0 broke compatibility. Unlike a version bump, OCPP 2.x was a comprehensive redesign, which meant a central system had to be substantially rewritten rather than patched, and every operator with a working 1.6 backend faced a real engineering project with no immediate revenue attached.

The second is the installed hardware. A charging network is a fleet of field devices with firmware, and a protocol migration is only as fast as the slowest vendor's firmware roadmap. Plenty of deployed hardware will never receive a 2.x firmware at all, which forces operators into dual-stack operation: running 1.6 and 2.x side by side for years, which is more work than running either alone, and is precisely the cost that made "wait another year" feel sensible annually.

The third is that for a long time nothing forced the issue. Sessions billed fine on 1.6. The features 2.0.1 enabled, Plug and Charge, serious smart charging, device-level diagnostics, were things customers did not yet demand loudly enough to move a roadmap.

All three hesitations are now eroding at once. Certification for 2.0.1 has been available since 2023 and new hardware increasingly ships with it. The demand side matured: smart charging is becoming a tariff-driven necessity rather than a demo, and V2G pilots are turning into commercial offers that 1.6 simply cannot carry. And the standardization move means the mandate pressure is arriving from above, through tenders and funding conditions, rather than waiting for operators to volunteer.

Step through 2.0.1 or leap to 2.1

So the 2026 question is sequencing. Three honest answers for three situations.

If you are building new, a new network, a new central system, a new charger, there is no reason to touch 1.6 except as a backward-compatibility shim for legacy fleets you must support. Build on 2.0.1 as the floor, structure the codebase for 2.1's additions, and treat version negotiation as a first-class feature. New infrastructure that launches 1.6-only in 2026 is launching with a countdown timer attached.

If you operate a large 1.6 fleet, the pragmatic path is dual-stack with a migration wave plan: central system speaks both, new and upgradeable hardware moves to 2.x in cohorts, and the stubborn tail of never-upgradeable chargers stays on 1.6 until replaced at end of life. The mistake to avoid is treating this as one big-bang project; it is a multi-year operating mode, and the teams that plan it as such suffer far less than the ones that discover it mid-flight.

If your business depends on V2G or grid services, the leap to 2.1 stops being optional strategy and becomes the product roadmap, because the capabilities you are selling live in the messages 2.1 added. Since 2.1 contains 2.0.1 whole, building for it does not strand you with older counterparties; the fallback is designed in.

What this means for the market

Two consequences follow from all this, one for incumbents and one for entrants.

For incumbents, the deferred migration has quietly become a liability line. A 1.6-only network in 2026 is progressively locked out of Plug and Charge user experience, locked out of the smart charging economics that dynamic tariffs and demand charges create, exposed on security posture, and increasingly disqualified from tenders that reference the IEC standards. None of this fails loudly on any given Tuesday, which is exactly what makes it dangerous; it fails as a slow drift into competitive disadvantage.

For entrants, the window is real but narrowing. A software-native operator or CSMS vendor that is fully 2.x-native today competes against incumbents dragging a dual-stack anchor, and the grid-facing features in 2.1 are close to greenfield territory where nobody has a decade of legacy advantage. That advantage decays as the incumbents complete their migrations, which puts a rough two-to-three-year clock on protocol-generation arbitrage as a differentiator. After that, 2.x is simply table stakes and the competition moves back to operations and economics, where it always ends up.

I have spent enough time on the IoT side of charging protocols to say the unfashionable part out loud: protocol migrations are never the glamorous work, and they are repeatedly the work that decides who is still standing when the market turns. OCPP's turn is happening now.

If you are an operator planning the 1.6 exit, or a founder deciding which protocol generation to build your product on, this sits squarely in my advisory territory, where charging, IoT fleets, and energy markets overlap. Details on the consulting page.