OCPP 1.6 vs 2.0.1 vs 2.1: What Changes on the Hardware Side

The Open Charge Alliance states that OCPP 1.6 and OCPP 2.0.1 are not compatible. That single sentence is why the OCPP version is a hardware decision and not a backend preference: a station built for 1.6 does not become a 2.0.1 station because the operator changed management systems. What the newer versions add lands in four places on the board — flash and RAM for the device model and its variables, secure storage and a trustworthy clock for credentials, headroom for device management and diagnostics, and board options such as a powerline modem or a card terminal that cannot be added by firmware at all.

This page is written from the equipment side. It does not answer how long an OCPP certificate takes to obtain; it answers what the version in the specification changes in the product being built.

The three live versions as they stand in September 2026

A specification that says "OCPP 2.x" is not specifying anything a supplier can be held to. Three versions are current at the same time, two of them have had new editions within the last year, and the differences between editions are exactly where field problems come from.

  • OCPP 1.6, released 2015. SOAP and JSON transports, smart charging through charge profiles, local authorisation list management. The Open Charge Alliance describes it as still widely used, which matters commercially: an installed base a buyer already operates is a constraint on the next purchase, not a legacy detail.
  • OCPP 2.0.1, released 2020. Edition 3 was approved as an IEC standard, IEC 63584, in 2024. Edition 4 was published in December 2025 and incorporates the errata issued since edition 3. A purchase specification should name the edition, because errata change behaviour that test cases check.
  • OCPP 2.1, released January 2025. Edition 2, published in December 2025, added Part 5 with the certification profiles and Part 6 with the test cases, and folded in the errata issued since the first edition. It builds on 2.0.1 rather than replacing it: the Open Charge Alliance states that care was taken to keep application logic developed for 2.0.1 compatible with 2.1.
  • Certification covers 1.6 and 2.0.1. The Open Charge Alliance certification programme validates conformance of an implementation with the OCPP 2.0.1 or OCPP 1.6 specification, and the resulting certificates are listed publicly per company and product. A tender that requires a certificate today has to be written against one of those two versions.

The practical reading for a manufacturer: 2.0.1 is the version with an IEC number and a certification route behind it, 1.6 is the version most of the installed fleet speaks, and 2.1 is the version the next generation of features is being written into. Designing to 2.0.1 is the position that is compatible with all three of those facts at once.

Which parts of OCPP 2.0.1 become hardware

The feature list published by the Open Charge Alliance is written for the protocol. Translated into board terms, this is what each item costs.

Device model

Structure the station has to describe about itself

OCPP 2.0.1 replaces the flat connector numbering of 1.6 with a hierarchy — Charging Station, EVSE, connector — expressed as components and variables. The station is expected to report that structure and to hold the variables persistently. On the board this is non-volatile storage that survives power loss and a code path that can serve a query about the station's own configuration. It is the single largest reason a 1.6-sized memory budget stops being enough.

Security

Keys, certificates and a clock you can trust

The added security in 2.0.1 means credentials that live on the station and have to be stored somewhere an attacker with the enclosure open cannot simply read, and validity periods that have to be checked against a time the station actually knows. That is a secure element or protected flash decision, plus a real-time clock with backup. Both are board-level and both are cheaper to design in than to retrofit.

Device management

Being administered remotely, not just monitored

Getting and setting configuration, monitoring variables and returning diagnostics turn the station into something the operator administers over the link. The board consequences are a log buffer that does not lose the interesting minutes, and firmware update that cannot brick a unit on a bad connection — in practice a dual-bank layout, which doubles the flash reserved for application code.

ISO 15118 and display

The parts OCPP cannot provide on its own

OCPP 2.0.1 adds support for ISO 15118 on the station-to-backend interface. It does not add the vehicle-side stack or the powerline modem on the Control Pilot line, and without those there is no Plug and Charge on any version. Display and messaging support likewise assumes a screen exists and that there is room for the text. These are product decisions the protocol version exposes rather than creates.

What OCPP 2.1 adds that is not a firmware question

Because 2.1 keeps 2.0.1 application logic compatible, it is tempting to file it as "later, in software". Several of its additions are not software at all. Bidirectional charging — the new functional block enabling V2X energy flows — needs power electronics capable of exporting; no protocol release adds that to a unidirectional charger. Ad hoc payment with a credit or debit card needs a terminal, either built in or standalone, with the certification regime that comes with handling payment. Support for ISO 15118-20 with bidirectional power transfer needs the second-generation high-level communication stack underneath it. Battery swapping support presumes a swap station.

The honest way to use this list during specification is as a filter: look at which 2.1 functional blocks the product will plausibly need in its service life, and check only those against the hardware. Local cost calculation and the extended transaction options are firmware. Bidirectional power and card payment are not. Mixing the two in one requirement line is how a station ends up nominally compliant and practically unable to do the thing the buyer bought it for.

Four things that are regularly mis-specified

  • "OCPP 2.0.1 ready" as a product property. It is not a defined term and it carries no obligation. Ask for the version the station speaks today, pinned to a firmware version and a hardware revision, and separately for what an upgrade would require. If the answer to the second is "a different controller", that is a legitimate answer — but it should appear before the purchase order, not after.
  • Treating a certificate as a company attribute. Certificates under the Open Charge Alliance programme are issued against an implementation and a version, and the certified products are listed publicly. A statement made at company level is not checkable; "this product holds a certificate for OCPP 2.0.1, here is the public entry" is. Ask for the entry.
  • Assuming version parity between station and backend. Because 1.6 and 2.0.1 are not compatible, a 2.0.1-only management system cannot operate a 1.6 station natively and the reverse also holds. Many operators run a mixed fleet deliberately. If that is the case, it is the management system that has to speak both, and the requirement belongs in the software tender rather than in the hardware one.
  • Leaving the security profile unstated. The security profile decides how the station authenticates and how credentials get to it in the field — which is an installation and service process, not just a protocol setting. Specifying the profile is worth more than adding another feature name to the requirement, because it is the item that changes what field technicians have to do at every unit.

What eectec states, and what it does not

Our charging platform runs OCPP 1.6 in large-scale commercial operation, with OCPP 2.0.1 support in final development — first delivery scheduled for December 2026. That is the whole of the claim.

We hold no Open Charge Alliance certificate for OCPP 1.6 or for OCPP 2.0.1. Implementing a protocol and holding a third-party certificate for it are two different things, and only the first applies to us today. Where a tender requires a certificate, that requirement should be established before design work starts, because it changes the schedule and it is not something a supplier can produce retrospectively.

We do not describe a board as "2.0.1 ready" without stating the firmware version and hardware revision it applies to. Where a customer's requirement is OCPP 2.1, we will say which functional blocks the proposed hardware can reach and which it cannot, rather than answering at the version level.

CE marking at board level does not transfer to a finished charging station. Under the Blue Guide (2022/C 247/01), the party placing the finished product on the EU market under its own name or trademark is the manufacturer and issues the declaration of conformity. This does not change with the OCPP version.

Questions we are asked about this

Can an OCPP 1.6 charging station be upgraded to OCPP 2.0.1 by firmware alone?

Sometimes, and it has to be established per product rather than assumed. The Open Charge Alliance states that OCPP 1.6 and OCPP 2.0.1 are not compatible, so the change is a full protocol implementation on the station, not a configuration switch. Whether firmware alone is enough depends on whether the controller has the flash and RAM headroom to carry the 2.0.1 device model, variable store and security profiles alongside the application. On a board sized for 1.6 it frequently is not, which is why the question belongs in the hardware specification and not in the backend discussion.

Which OCPP versions are available today, and what is the current edition of each?

Three versions are live. OCPP 1.6 was released in 2015 and remains widely used. OCPP 2.0.1 was released in 2020; its edition 3 was approved as IEC standard IEC 63584 in 2024, and edition 4, incorporating subsequent errata, was published in December 2025. OCPP 2.1 was released in January 2025, and its edition 2, published in December 2025, added Part 5 with the certification profiles and Part 6 with the test cases.

Does choosing OCPP 2.0.1 now mean a second migration when OCPP 2.1 arrives?

Not in the way the 1.6 to 2.0.1 step was. OCPP 2.1 builds on OCPP 2.0.1, and the Open Charge Alliance states that care was taken to keep application logic developed for 2.0.1 compatible with 2.1. The hardware question is different from the protocol question: several of the 2.1 additions, such as bidirectional power transfer and ad hoc card payment, require power electronics or peripherals that no protocol version can add later. Those are decided by the product, not by the version number.

What does OCPP 2.0.1 add that costs memory on the controller?

Four things in particular. The device model requires the station to describe its own structure as Charging Station, EVSE and connector components with their variables, and that description has to be stored and served. Device management adds get and set of those variables plus monitoring and diagnostics. The security features add key and certificate storage with a validity check, which implies a trustworthy time source. Display and messaging support adds text the station has to hold. Each is modest alone; together they are the reason a board sized for OCPP 1.6 often cannot simply take 2.0.1.

Is OCPP certification available for OCPP 2.1?

The Open Charge Alliance certification programme validates conformance with the OCPP 2.0.1 or OCPP 1.6 specification. OCPP 2.1 edition 2 published the certification profiles and test cases in December 2025, which is the prerequisite work, but a tender that requires a certificate today should be written against 1.6 or 2.0.1. Certificates are issued against a named implementation and version and are listed publicly, so a claim can be checked rather than believed.

Does OCPP 2.0.1 give a charging station Plug and Charge?

No. OCPP 2.0.1 adds support for ISO 15118 on the interface between the station and the management system, which is necessary but not sufficient. Plug and Charge also requires the high-level communication stack and a powerline modem on the Control Pilot line towards the vehicle, plus certificate handling on the station. A station whose controller has no PLC modem cannot do Plug and Charge on any OCPP version.

Is eectec certified by the Open Charge Alliance?

No. We hold no Open Charge Alliance certificate for OCPP 1.6 or for OCPP 2.0.1, and we state that plainly because getting it wrong costs a supplier evaluation. What is true is that our charging platform runs OCPP 1.6 in large-scale commercial operation, with OCPP 2.0.1 support in final development and first delivery scheduled for December 2026. Implementing a protocol and holding a third-party certificate for it are two different things, and only the first applies to us today.

How should an OCPP requirement be written in a purchase specification?

Name the version and edition, state whether a third-party certificate is required or whether a tested implementation is acceptable, and pin both to a firmware version and a hardware revision. A line reading OCPP 2.0.1 ready is not enforceable: it does not say whether the station speaks 2.0.1 today, whether it can be made to, or who pays if it cannot. Adding the security profile you intend to operate is worth more than adding a further feature name, because that is what determines how credentials reach the station in the field.

Sources

The specifications themselves are published by the Open Charge Alliance and available from its download page. Nothing on this page reproduces their text; the requirements are in the specification documents and a purchase specification should be written against them rather than against any vendor's summary, including this one.

Related

Have an OCPP version fixed by the backend you already run?

Tell us the version and edition, the security profile you operate, and whether the fleet is mixed. We will tell you which of our boards reaches it today, what would have to change for the next version, and what we cannot claim.

Talk to us about a specification See the EN-standard boards