OCPP 1.6J vs OCPP 2.0.1: Which Protocol Should Your Charging Network Use?
OCPP 2.0.1 is not simply a newer version of 1.6J. The two protocols differ in architecture, security model, and device management. Here is what the difference means for a charger purchase in 2026.
If you operate a charging network, or you are buying chargers to build one, the protocol between your chargers and your backend decides what you can do later. Firmware updates over the air, plug and charge, smart charging schedules, and payment terminals all depend on the protocol version baked into the charger firmware when it ships. Choosing the wrong one is not a software problem you fix in a sprint. It is a hardware fleet problem.
This guide compares the two protocol versions that matter in commercial procurement today: OCPP 1.6J and OCPP 2.0.1. Both are published by the Open Charge Alliance, a global industry consortium. Both are open standards. They are not, however, interchangeable.
What OCPP Actually Does
OCPP, the Open Charge Point Protocol, defines the message exchange between a charging station and a charging station management system, usually shortened to CSMS. It is a JSON over WebSocket protocol. The "J" suffix in 1.6J means JSON. There is also an older SOAP variant, 1.6S, which is effectively legacy and should not be specified in new tenders.
The protocol covers a defined set of operations: authorizing a driver, starting and stopping a transaction, reporting meter values, sending fault and status notifications, applying charging profiles, and managing firmware and configuration. It does not cover the driver-facing app, the payment gateway, or the roaming hub. Those sit above OCPP.
OCPP 1.6J: The Safe Default
OCPP 1.6J is the most widely deployed version in the field. If you buy chargers today and ask for OCPP, you will usually get 1.6J unless you specify otherwise. Its strengths are maturity and ubiquity.
- Supported by every major CSMS on the market, including open source stacks
- Well understood by installers and integrators, so commissioning is predictable
- Certification program has been running for years, with a large pool of certified devices
- Sufficient for basic AC and DC charging, remote start and stop, and RFID authorization
Its weaknesses show up as networks grow. Device management is thin: updating configuration across hundreds of chargers means custom scripts against vendor-specific endpoints. Security relies on basic authentication plus optional TLS, with no standard certificate lifecycle management. Smart charging profiles exist but implementations vary enough between vendors that a multi-vendor site often falls back to static limits.
OCPP 2.0.1: What Actually Changed
OCPP 2.0.1 is not an incremental revision. The data model was rebuilt around a consistent device model, where every configurable value on the charger is described and discoverable by the backend. That single change enables most of what operators want.
| Capability | OCPP 1.6J | OCPP 2.0.1 |
|---|---|---|
| Device model | Flat key-value configuration list | Structured, queryable component and variable model |
| Security | Basic auth, optional TLS, no standard certificate management | TLS required, certificate installation and rotation via the protocol |
| Smart charging | Charging profiles, vendor implementation varies | Full charging station and EVSE-level profiles, plus external constraints |
| Plug and Charge | Not covered | ISO 15118 certificate handling defined in the protocol |
| ISO 15118 support | Vendor specific, often as a parallel API | First class, including contract certificate management |
| Display and messaging | Minimal | Cost and message display on the charger screen |
| Transaction handling | One transaction per connector, limited metadata | Rich transaction model with per-EVSE reporting |
| Security events | Not defined | Structured security event log sent to the backend |
| Certification | Large installed base, mature test suite | Smaller but growing certified device list |
| CSMS support | Universal | Common in modern CSMS, thin in older ones |
The plug and charge row is the one that changes commercial outcomes. Under OCPP 2.0.1, the charger can handle the ISO 15118 contract certificate flow through the protocol itself. Under 1.6J, plug and charge is usually delivered through a vendor extension, which means a fleet with two charger brands needs two integrations. Drivers notice this immediately: on one site, tap and go. On another, download an app and scan a QR code.
The Security Difference Is Not Cosmetic
Public charging networks are distributed industrial control systems connected to the internet. A charger that accepts unsigned firmware, or that authenticates to its backend with a shared password, is a foothold. OCPP 2.0.1 requires TLS and defines how the backend pushes security certificates to the charger and rotates them. It also defines a security event log, so a compromised charger reports its own anomalies.
That matters for compliance as well as security. European network operators working under the EU Alternative Fuels Infrastructure Regulation now face explicit cybersecurity and data handling expectations, and public procurement in several markets asks bidders to state their protocol version and security posture. Answering "1.6J with vendor extensions" is increasingly a scored downgrade.
Which Version Should You Specify?
The honest answer depends on what you are buying and when you need it live.
| Situation | Recommendation |
|---|---|
| Small AC site, single vendor, live in 3 months | 1.6J is acceptable and lower risk |
| Multi-vendor DC network, 5 year horizon | Specify OCPP 2.0.1 with 1.6J fallback |
| Plug and charge is a product requirement | OCPP 2.0.1 with ISO 15118 support |
| Tender with public funding or EU exposure | OCPP 2.0.1, expect cybersecurity scoring |
| Existing 1.6J fleet, backend supports 2.0.1 | Buy new units as 2.0.1, run both on one CSMS |
The pragmatic path most operators take is dual-stack. Modern DC chargers such as the XNYZY08 DC fast charging station and the split DC charger main cabinet can ship with firmware that supports both protocol versions, selected at commissioning. That keeps existing sites on 1.6J while new sites come online on 2.0.1, and it lets you migrate one site at a time instead of running a fleet-wide cutover.
If dual-stack is not offered, treat that as a signal about the vendor firmware roadmap. Ask directly: which OCPP versions are certified, is the certification listed by the Open Charge Alliance, and can the protocol version be changed in the field by firmware update. A vendor that cannot answer the third question is selling you a locked device.
Questions to Put in Your RFQ
- Which OCPP versions are supported, and which are certified against the OCA test suite?
- Is dual-stack operation possible, and is it selectable in the field or fixed at the factory?
- Does the charger support OCPP 2.0.1 security certificate management and security event logging?
- How is ISO 15118 plug and charge implemented: natively, or through a vendor extension?
- What charging profile types are supported for smart charging under each version?
- What is the firmware update mechanism, and does it work over OCPP or through a separate tool?
These six questions separate a charger that will still be maintainable in 2031 from one that becomes a support burden in 2027. For a wider view of what else belongs in a supplier evaluation, see our EV charger supplier vetting checklist.
The Open Charge Alliance runs a recorded tutorial covering the 2.0.1 data model and certification process. It is technical, but it is the authoritative walkthrough from the body that maintains the specification, and it is worth an hour of your integration engineer's time before an RFQ goes out.
Migration Reality Check
Moving an existing 1.6J site to 2.0.1 is not only a charger-side change. Your CSMS must support 2.0.1, your roaming partner must support it, and your RFID or payment authorization path must keep working across both. In practice, operators run both versions in parallel for years, with the CSMS normalizing the data model internally.
The migration cost therefore lands mostly on the backend, once, rather than on the chargers, repeatedly. That is an argument for buying 2.0.1 capable hardware now even if you enable 1.6J today: the expensive part is the site visit, not the firmware flag.
Is OCPP 2.0.1 backward compatible with OCPP 1.6J?+
No. They are separate protocol versions with different message structures. A 1.6J charger cannot talk to a backend using only 2.0.1, and the reverse is also true. Compatibility is achieved by dual-stack firmware or by a CSMS that speaks both.
Do I need OCPP 2.0.1 for plug and charge?+
Not strictly, but it is strongly recommended. Under 1.6J, plug and charge depends on vendor-specific extensions, so a mixed fleet needs separate integrations. Under 2.0.1, the ISO 15118 certificate flow is part of the protocol.
Does OCPP certification guarantee interoperability?+
It guarantees the device passed the Open Charge Alliance test suite for the listed features. It does not guarantee that every feature you need is implemented. Always request the certification certificate and check which feature profiles are covered.
How long will OCPP 1.6J remain supported?+
There is no announced end of support. The installed base is too large for the industry to abandon it quickly, and most CSMS vendors intend to support it for the foreseeable future. The risk is not removal, it is stagnation: new features land in 2.0.1 first.
Can a charger be upgraded from 1.6J to 2.0.1 in the field?+
Sometimes. It depends on whether the hardware has the compute and storage, and whether the vendor ships a signed firmware image. Ask for a written commitment and a version number, not a verbal assurance.