A networked EV charger is, technically speaking, an internet-connected device sitting in a public or semi-public location, talking to a remote server, capable of starting and stopping a flow of real electrical power on command. That’s a meaningful attack surface — and as charging networks scale from a handful of units to hundreds, the security of the OCPP link between charger and CPMS stops being a checkbox and becomes one of the things that actually determines whether a network can be trusted.
Why Charger Security Isn’t Optional Anymore
The risks aren’t hypothetical. An unsecured or poorly secured charge point management link exposes a network to:
- Impersonation — a rogue device posing as a legitimate charger (or a legitimate CPMS), able to send fraudulent transaction or remote-control commands.
- Eavesdropping — session tokens, RFID/payment identifiers, and operational data intercepted in transit.
- Command injection — a man-in-the-middle altering
RemoteStartTransaction,RemoteStopTransaction, or firmware-update commands en route. - Fleet-wide exposure — because a CPMS manages many chargers from one place, a single compromised credential or certificate can be a foothold into the whole network, not just one device.
Where OCPP 1.6J Falls Short
OCPP 1.6J, still the most widely deployed version in the field, supports TLS but treats it as optional, and its default authentication is HTTP Basic Auth — a username/password pair sent over the WebSocket connection. In practice, this means security depends heavily on how carefully each deployment was configured, not on the protocol itself:
- TLS can be (and often is, in older or budget deployments) skipped entirely, leaving the WebSocket connection in plaintext.
- Basic Auth credentials are typically static per charger and need manual rotation — nothing in the protocol enforces regular renewal.
- There’s no standardized mechanism for mutual authentication (the CPMS proving its identity to the charger, not just the reverse).
What OCPP 2.0.1 and 2.1 Add
OCPP 2.0.1 introduced a formal security framework built around three security profiles, and OCPP 2.1 carries the same model forward while extending certificate handling further (notably for ISO 15118 Plug & Charge, covered below).
| Security Profile | Authentication | Transport | Typical Use |
|---|---|---|---|
| Profile 1 | Basic Auth | Plain WebSocket (no TLS) | Legacy/lab only — not recommended for production |
| Profile 2 | Basic Auth | TLS (server-side certificate) | Minimum acceptable baseline for a production deployment |
| Profile 3 | Client-side (mutual) TLS certificates | TLS, both directions authenticated | Recommended for any commercial or public network |
The jump from Profile 2 to Profile 3 is the meaningful one: instead of a shared password, each charger holds its own client certificate, issued and verifiable by the CPMS’s certificate authority. That means a stolen or leaked password can’t impersonate a charger — an attacker would need the actual private key material, which is why mutual TLS is the direction every serious CPMS vendor is pushing deployments toward.
Certificate Management in Practice
Moving to Profile 3 (or planning for OCPP 2.1’s Plug & Charge features) means the CPMS takes on a role it may not have had before: acting as, or integrating with, a certificate authority. In practice that involves:
- Issuing a certificate per charge point, tied to that device’s identity, at commissioning time.
- Rotation and renewal, so certificates expire and get replaced automatically before they lapse — a manual process here doesn’t scale past a handful of sites.
- Revocation, so a decommissioned or compromised charger’s certificate can be invalidated immediately, cutting it off from the network without a truck roll.
- OCPP 2.1’s extended certificate model for ISO 15118 Plug & Charge, where the vehicle itself authenticates to the charger cryptographically — meaning certificate management now spans not just chargers, but potentially vehicle-side credentials issued by mobility service providers, adding another layer the CPMS needs to track.
None of this is charger-hardware work — it’s entirely a CPMS platform capability, which is exactly why security posture is as much a software-vendor decision as a hardware one.
What This Looks Like in a Real CPMS
In a platform like ChargeOS, this typically surfaces as:
- A live security/health score per charge point, showing whether it’s on Profile 2, Profile 3, or still unsecured — so an operator can see gaps at a glance across an entire fleet rather than auditing devices one by one.
- Automated certificate lifecycle management — issuance, renewal reminders, and revocation handled centrally rather than per-site.
- OCPP version visibility, since a mixed fleet (some 1.6J, some 2.0.1/2.1 chargers) will have a mixed security ceiling, and the CPMS needs to make that visible rather than reporting a false all-green status.
A Practical Checklist for Buyers
Before signing on with a CPMS or a charger vendor, it’s worth confirming directly:
- Does the platform support Security Profile 3 (mutual TLS), or only Basic Auth over TLS (Profile 2)?
- Is certificate issuance, rotation, and revocation automated, or does it require manual intervention per device?
- Can the platform show, at a glance, which chargers in a fleet are on which security profile and OCPP version?
- If ISO 15118 Plug & Charge is on the roadmap, does the CPMS’s certificate model already account for vehicle-side credentials, or would that be a later re-architecture?
- What happens operationally when a charger’s certificate expires or is revoked — does charging fail gracefully, or does the site go dark?
Security profile is rarely the first question a site owner asks when evaluating a CPMS — but it’s usually the first one that matters once the network is large enough to be worth attacking.
