The sharpest design difference between OCPP 1.6 and OCPP 2.0.1 is security. In 1.6, security arrived as profiles and extensions layered onto a protocol designed before charger security was a concern. In 2.0.1, charger identity, protected connections and certificate handling are part of the core design.
Key Takeaways
- The core difference is placement: 1.6 added security through extensions; 2.0.1 designs identity, protected connections and certificate handling in.
- On 2.0.1, certificates are a managed lifecycle — issuing, renewal and replacement need a named owner.
- A version is not a verdict: implemented security and operating discipline decide real protection on either generation.
- EVDANCE listings state 1.6J and OCPP-ready, never 2.0.1 — confirm pairing and security setup with your platform in writing.
What “Security” Covers Between a Charger and a Platform
OCPP runs between field chargers and a management platform, as our OCPP guide for operators sets out, and security in that conversation covers three things. First, identity: the platform needs to know it is talking to a genuine charger, and the charger needs to know it reached the genuine platform. Second, the connection itself: session and billing data travelling over public networks should not be readable or alterable on the way. Third, trust in what the charger runs: remote updates are only safe if the charger can tell a legitimate update from anything else.
Two Generations, Two Places for Security
| Area | OCPP 1.6 | OCPP 2.0.1 | What it means on your network |
|---|---|---|---|
| Where security lives | Added through security profiles and extensions after the core protocol | Designed into the core specification | On 1.6, ask what is implemented; on 2.0.1 it is baseline |
| Charger identity | Depends on the profile and setup the deployment chose | Certificate-based identity is part of the design | Each charger carries credentials the platform can check |
| Certificate handling | Largely a matter for the platform and the installer to arrange | Certificate management is built into the protocol’s model | Issuing, renewing and replacing certificates becomes a fleet task with an owner |
| Security events | Left mostly to individual implementations | Security-relevant events are reported to the platform as part of the design | The platform can see security problems as events, not just as chargers going silent |
The Operator’s Job Grows — Deliberately
Certificates are not install-and-forget. They are issued, they expire, they are replaced when hardware is swapped, and they must be revoked when a charger leaves the fleet. On a 2.0.1 network this lifecycle sits inside the management model — which is a strength, but only if somebody owns the list. A charger whose credentials have lapsed or were never provisioned does not degrade gracefully; it fails to connect, and the fault looks like hardware until someone checks the certificates. Operators planning a 2.0.1 fleet should treat certificate administration the way they treat RFID lists and tariff tables in smart charging operations: named owner, renewal routine, a record per charger.
Fairness to 1.6: A Version Is Not a Verdict
None of this makes an OCPP 1.6 fleet automatically insecure, or a 2.0.1 fleet automatically safe. The 1.6 extensions exist precisely so deployments can add protected connections and charger authentication, and most running networks use them with sensible network practice. Equally, 2.0.1’s designed-in security only protects a site whose operator provisions certificates properly and keeps them current. The version tells you where the security machinery lives; the implementation and the operating discipline decide how much protection you actually get. In procurement, ask not just “which version?” but “which security arrangements are implemented, and who runs them?” — in writing.
Where EVDANCE Models Stand
EVDANCE’s networked station, the EV-AC03201T dual-connector AC station, states OCPP 1.6J. The EV-ACS3210E portable states “OCPP-ready” — weaker wording that names no version. No EVDANCE listing states OCPP 2.0.1, and no additional security feature is claimed for either model — so for a security-sensitive deployment, have the pairing and the security setup with your platform confirmed in writing before the network depends on it. The wider range is on the commercial charging page.
Frequently Asked Questions
Is OCPP 1.6 insecure?
No. Its security was added through extensions rather than designed in, so what matters is whether a given deployment implements them. Ask the maker and the platform which security arrangements are in place; the version number alone answers nothing.
Can one platform run 1.6 and 2.0.1 chargers together?
Some platforms accept both versions; others take one. The platform’s current documentation decides, and the answer belongs in any mixed fleet’s purchase file, not in an assumption.
Does using OCPP 2.0.1 make my site compliant with programme rules?
A protocol version is a property of your equipment, not a compliance result. Programme rules are separate documents with their own requirements; check the current text of any programme you are building under.
Related Reading
- OCPP Explained: What Charge Point Operators Need From EV Charger Hardware
- Smart Charging and Time-of-Use Tariffs: How Scheduling Cuts EV Charging Costs
- EV Charger Certifications Explained: CE, UKCA, UL, ETL, CB and What Buyers Should Ask For
- EV Charging Industry News: NEVI Funding Returns, the 30C Tax Credit Ends
