OCPP 1.6 vs 2.0.1: what actually changes for site operators.

OCPP 2.0.1 has been ratified for years. Most chargers shipping today still default to OCPP 1.6. If you're a site operator deciding which to require in your spec, the honest answer is: it depends on what you're actually trying to do.

This post is the field version of that answer. We'll cover what changed between 1.6 and 2.0.1, which changes matter for typical retail and fleet sites, and which are useful only for specific use cases that most operators don't have.

The short version up front: OCPP 1.6 is fine for most sites today. OCPP 2.0.1 matters if you need plug-and-charge, granular smart charging, or device management at scale. MÖTEN chargers support both, so you don't have to pick at procurement — you can roll forward when you're ready.

What OCPP actually does

OCPP — the Open Charge Point Protocol — is the language a charger speaks to a back-office system. It standardizes what messages get sent when a session starts, when a session ends, when a fault occurs, when a meter value updates, and when the back-office wants to push a configuration change.

The point of OCPP is vendor independence: an OCPP-compliant charger can talk to any OCPP-compliant management system. You're never locked into one back-office vendor for the life of the hardware. eMÖTEN CMS speaks both versions, as do most major back-office platforms.

What changed in 2.0.1

OCPP 2.0.1 is not a small revision. It's a from-scratch rewrite of the protocol's data model. The headline additions are:

• ISO 15118 plug-and-charge support. The vehicle and charger negotiate identity and billing automatically, no app or RFID card needed.
• Smart charging profiles. Granular control over current, power, and schedule, with stacking and priority rules.
• Device management. Firmware updates, diagnostics, and configuration push from the back-office instead of on-site.
• Improved security. TLS 1.2+ required, signed firmware, certificate-based authentication.
• Display message handling. The back-office can push messages to the charger's screen.
• Better metering. Signed meter values for billing-grade accuracy and dispute resolution.

That's the headline list. Each of those is genuinely useful. Whether they're useful to you is a different question.

Which features actually matter at a typical site

Here's how we think about it for the sites we see most often:

Retail and hospitality (hotels, malls, restaurants)

OCPP 1.6 is sufficient. Drivers tap an RFID card or open an app. Sessions get billed. Reports get generated. The back-office controls when chargers are available and at what price. None of the 2.0.1 advantages are deal-breakers here.

The exception: if you're trying to support plug-and-charge for fleet vehicles or premium-experience deployments where drivers don't want to touch their phone, 2.0.1 starts to matter.

Fleet depots

This is where 2.0.1's smart charging profiles earn their keep. A depot with 30 vehicles charging overnight on a constrained service can use granular charging profiles to spread load across the night, prioritize vehicles that need to leave first, and avoid demand-charge spikes. OCPP 1.6's smart charging is much coarser; you can do similar things, but you have to work harder.

Public DC fast hubs

Plug-and-charge support is becoming table stakes for premium hubs in 2026. Drivers expect to plug in and have it just work, without an app or card. That requires both an ISO 15118-capable vehicle and an OCPP 2.0.1 back-office. If you're building a corridor hub, plan for 2.0.1.

Workplace and multi-family residential

Either version works. The deciding factor is usually what your back-office vendor supports natively versus through extensions, not the protocol itself.

The migration question

If you have an existing OCPP 1.6 deployment, do you need to migrate? Probably not, and certainly not urgently. OCPP 1.6 chargers will be supported by every major back-office vendor for years. The protocol isn't being deprecated; it's being supplemented.

The realistic migration path looks like this:

1. New chargers ship with both 1.6 and 2.0.1 firmware available.
2. You stay on 1.6 until you have a concrete need for a 2.0.1 feature.
3. When that need arrives (usually plug-and-charge or smart charging), you upgrade firmware on the affected chargers and configure the back-office to use 2.0.1 for those endpoints.
4. Older chargers without 2.0.1 firmware support stay on 1.6 indefinitely; the protocols coexist on the same back-office.

What to put in your RFP

If you're writing a procurement spec right now, three lines cover most of the surface area:

• “Charger must support OCPP 1.6-J as a baseline.”
• “Charger must be field-upgradable to OCPP 2.0.1 via firmware update without hardware change.”
• “Vendor must commit to a security update cadence for whichever protocol version is deployed.”

Anything beyond that depends on whether you actually need 2.0.1's specific features today. If you do, name them in the spec. If you don't, leave the door open and don't pay extra for unused capability.

Where the standard is going

OCPP 2.1 is in development under the Open Charge Alliance. The notable additions in the draft work include better support for bidirectional charging (V2G), refinements to smart charging, and tighter integration with ISO 15118-20 for high-power DC use cases. None of that changes the buying calculus today.

For now, treat OCPP 1.6 as the floor, OCPP 2.0.1 as the ceiling, and pick the version that matches your actual use case. Both will be supported for the life of any charger you buy in 2026.