OCPP 2.1 vs OCPP 2.0.1: What CPOs Need To Know Before Upgrading

OCPP 2.1 vs OCPP 2.0.1: The CPO Upgrade Decision

Every CPO and eMSP running a charger fleet eventually asks the same question: is OCPP 2.1 something to plan for now, or a version number to file away for later? OCPP 2.1, which the Open Charge Alliance (OCA) finalized in January 2025, is a structural superset of OCPP 2.0.1 — not a replacement for it. If you’re running public DC fast chargers, evaluating vehicle-to-grid pilots, or just checking whether your CSMS vendor’s “OCPP 2.1 support” headline actually changes anything, this is the practical version of that comparison.

It matters differently depending on who you are. A CPO running a multi-site public network cares about firmware roadmaps and certification cost. An eMSP layering apps and billing on top of someone else’s chargers mostly inherits whatever version the CSMS below it speaks. A fuel retailer or real estate site owner installing first chargers is usually still deciding between 1.6 and 2.0.1 — 2.1 isn’t yet relevant to that call.

Where OCPP Stands Today: 1.6, 2.0.1, and 2.1

Three versions of the Open Charge Point Protocol are live in the field at once — normal for infrastructure with an 8-12 year hardware lifecycle. OCPP 1.6 (2015) remains the most widely deployed version globally, still spoken by most chargers built before roughly 2022. OCPP 2.0.1 (2020) is the version new deployments increasingly standardize on, partly by mandate: in the U.S., the National Electric Vehicle Infrastructure (NEVI) program has required OCPP 2.0.1 on federally funded public chargers since 28 February 2024 under 23 CFR Part 680, and South Korea mandates OCPP certification outright. OCPP 2.1, finalized 23 January 2025 and reissued as IEC-aligned Edition 2 documentation on 8 June 2026, is the newest layer — built on top of 2.0.1, not beside it.

Worth being precise about scope: OCPP governs the link between a charger and its OCPP-compliant charging software platform (its CSMS). It has nothing to do with roaming between networks — that’s OCPI’s job (mandated at 2.2.1 under the same NEVI rule, separately from OCPP). An eMSP whose app talks to multiple networks via OCPI roaming integration won’t see any difference from a charger’s OCPP version bump; this is almost entirely a CPO/hardware-and-CSMS decision.

What OCPP 2.0.1 Already Solved

Before comparing 2.1 to 2.0.1, it helps to remember how much of a jump 2.0.1 already was over 1.6 — because most of what a CPO actually needs from a “modern” protocol arrived at that step, not the next one.

Three-Tier Security Profiles

OCPP 2.0.1 introduced three security profiles, unchanged in 2.1: Profile 1 uses HTTP Basic Authentication over server-certificate TLS; Profile 2 adds TLS client certificates for mutual authentication; Profile 3 layers Plug & Charge certificate-based authorization on top. If your fleet is already certified against one of these, there’s nothing to re-certify when you move to 2.1.

A Real Device Model and Unified Transaction Reporting

1.6 reported charger state through a scattered set of messages — StartTransaction, StopTransaction, MeterValues, StatusNotification. 2.0.1 replaced that with a single TransactionEvent message and a tree-structured Device Model reporting components, values, and configuration in one consistent schema — with transactions that can start when a cable connects (before authorization completes) and stop on disconnect, a flexibility 1.6 never had.

ISO 15118-2 Plug & Charge

2.0.1 also brought certificate-based Plug & Charge software support into OCPP through ISO 15118-2 — letting a vehicle authorize and start a session automatically on connection, no RFID tap or app needed. Combined with the Device Model, this is why 2.0.1 is the version most CPOs should already be running, independent of anything 2.1 adds.

What’s Actually New in OCPP 2.1

OCPP 2.1 adds 27 new messages across four new functional blocks, taking the protocol from 64 messages/15 blocks to 91 messages/19 blocks. Every one of the additions below is optional — a CSMS and charger fleet can run 2.1 and use none of them.

Bidirectional Charging / V2X (Block Q)

Two messages — NotifyAllowedEnergyTransfer and AFRRSignal — let a charger and CSMS coordinate vehicle-to-grid and vehicle-to-everything energy flows, including automatic frequency restoration reserve (AFRR) signals for grid balancing. Relevant to CPOs piloting smart, demand-responsive charging with utilities — it needs bidirectional-capable hardware, not just a firmware flag.

Distributed Energy Resource (DER) Control (Block R)

A CSMS can now install grid-support characteristic curves — volt-watt, volt-var, frequency-watt, fixed power factor — directly on a charger via SetDERControl, retrieve them with GetDERControl, and remove them with ClearDERControl, with protection events reported back through NotifyDERAlarm. Matters for sites in utility grid-services programs, less so for a standalone workplace or retail install.

Tariff & Cost Model (Block I)

Eight new messages (SetDefaultTariff, GetTariffs, ClearTariffs, NotifySettlement, VatNumberValidation among them) let a charger calculate and display session cost locally, before and during charging — plus new authorization methods for prepaid cards, ad hoc payment, and secure dynamic QR codes. The clearest driver-experience upside: real cost shown on the charger’s own screen, not only in an app afterward.

Battery Swap Support (Block S)

RequestBatterySwap and BatterySwap bring battery-swap stations for two- and three-wheelers (and some EVs) into the same protocol as plug-in charging, reporting insertion/removal events and battery health metrics. Only relevant if swapping is part of your service mix.

Dynamic Charging Profiles and Telemetry Plumbing

Beyond the four new blocks, 2.1 extends smart charging with PullDynamicScheduleUpdate, UpdateDynamicSchedule, and UsePriorityCharging for on-the-fly setpoint changes and priority-boost charging, plus a new one-way SEND message type for high-frequency telemetry that no longer consumes the protocol’s single-outstanding-call slot. For fleet-wide remote monitoring, this quieter plumbing change is genuinely useful — telemetry stops competing with control commands.

The Security Case: Why Protocol Version Is an EV Cybersecurity Decision

The upgrade decision that actually carries security weight is 1.6 → 2.0.1, not 2.0.1 → 2.1. Researchers at the U.S. Department of Energy’s Idaho National Laboratory demonstrated denial-of-service, man-in-the-middle, and code-injection exploits against OCPP 1.6 deployments — exploiting its unencrypted WebSocket transport to remotely terminate charging sessions and gain unauthorized CSMS access, with real financial and reputational exposure for the CPO. Their recommended mitigation is exactly what 2.0.1 already provides by default: upgrade the protocol, or at minimum wrap 1.6 traffic in an encrypted tunnel (TLS, IPSec, or SSH) until you can.

OCPP 2.1 doesn’t change this picture — it inherits the same three OCPP security profiles from 2.0.1 unmodified. Its one incremental hardening is GetCertificateChainStatus, a new call for certificate-chain revocation checks, useful for CPOs running Plug & Charge (Profile 3) at scale. For a network still running exposed 1.6, the cybersecurity case for reaching 2.0.1 is independent of, and stronger than, any case for reaching 2.1.

Should You Upgrade Now? A Decision Framework

Because 2.1 is a strict, backward-compatible superset of 2.0.1, there’s no forced timeline the way there was moving off 1.6. The decision comes down to what your network actually needs to do:

In practice, the version negotiation is handled automatically at the transport layer — a well-built charger offers ocpp2.1, ocpp2.0.1, ocpp1.6 in preference order over its WebSocket connection, and the CSMS picks the highest one both sides support. A charging management system like YoCharge that already negotiates all three versions per charger during that handshake turns this from a hardware-replacement question into a configuration one: you don’t rip out chargers to reach 2.1, you confirm your CSMS and firmware both support it, then decide which of the new blocks are worth turning on.

How to Migrate Without Breaking Live Operations

1. Audit firmware across the fleet first. Segment chargers into 1.6-only hardware, 2.0.1-capable via OTA update, and 2.1-capable — mixed-version fleets are normal and don’t need to move in lockstep.
2. Confirm your CSMS vendor supports multi-version negotiation. A charger should offer all three versions and fall back gracefully — never an all-or-nothing cutover.
3. Pilot on one site or a small charger subset first. Validate TransactionEvent reporting, Plug & Charge certificate flows, and any new 2.1 blocks before a fleet-wide rollout.
4. Re-verify security-profile and certificate configuration post-upgrade. Firmware updates are a common point where TLS client-certificate setup silently regresses.
5. Only enable the 2.1 blocks you actually need. DER control or bidirectional charging without a utility program or V2X hardware behind it adds attack surface for no benefit.
6. OCPP and OCPI are separate decisions. A version change here doesn’t require re-certifying your roaming stack.

Sources: Open Charge Alliance — OCPP 2.1 release announcement | Open Charge Alliance — What’s New in OCPP 2.0.1 | U.S. DOE / Idaho National Laboratory — OCPP 1.6 security research (OSTI.GOV) | eCFR — 23 CFR Part 680, NEVI minimum standards