OCPP 1.6 Security - TLS, Certificates, and the Mistakes Everyone Makes
A practical guide to securing OCPP 1.6 connections: TLS setup, certificate management, security profiles, and the common vulnerabilities in real deployments.
OCPP 1.6 Security. TLS, Certificates, and the Mistakes Everyone Makes
OCPP 1.6 wasn't designed with security as a first priority. The original spec assumed chargers would sit on private networks behind firewalls. That assumption was wrong by about 2018, and it's dangerously wrong now. Chargers are on the public internet, handling payments, and connected to power infrastructure. Securing them matters.
The baseline
Rendering diagram...
If your charger connects over ws:// in production, everything is in plaintext: RFID card IDs, transaction data, configuration commands, firmware URLs. Anyone on the same network segment can read it. Worse, they can inject messages. start free charging sessions, change configurations, redirect firmware downloads.
The three security profiles
The OCPP 1.6 security whitepaper defines three profiles, each building on the previous:
| Profile | How it works |
|---|---|
| Profile 1 | Password in the WebSocket URL. Better than nothing, barely. |
| Profile 2 | TLS with server certificate. Charger verifies the backend. |
| Profile 3 | Mutual TLS. Both sides present certificates. The gold standard. |
Rendering diagram...
Profile 1 puts a password in the URL: wss://backend.example.com/ocpp/CP001?password=secret123. The password is usually hardcoded during manufacturing and rarely rotated. If someone reads the charger's config, they have the password forever.
Profile 2 has the backend present a TLS certificate. The charger verifies it's talking to the real server, not an impersonator. This stops man-in-the-middle attacks. But the backend doesn't verify the charger. anything that knows the URL can connect.
Profile 3 adds a client certificate on the charger side. Both endpoints prove their identity. No impersonation in either direction. This is what you actually want, but it requires a PKI: certificate provisioning during manufacturing, a CA, and a renewal workflow. Most operators end up on Profile 2 with strong unique-per-charger passwords because Profile 3 PKI is hard to get right at scale.
The mistakes I see in real deployments
Plain WebSocket in production. More common than you'd expect. Sometimes the charger firmware doesn't support TLS. Sometimes IT misconfigured the load balancer. Either way it's a critical vulnerability.
Certificate validation disabled. The charger is configured for wss:// but verify_peer = false. This defeats the entire purpose. a MITM can present any certificate and the charger happily accepts it.
Default passwords. admin, password, ocpp, the charger serial number. Never changed after deployment in the field.
Unprotected firmware URLs. The UpdateFirmware location points to a plain HTTP URL with no authentication. Anyone on the network can serve a modified firmware image.
Open OCPP endpoints. The backend's WebSocket endpoint is publicly accessible with no IP filtering, no rate limiting. Trivial to flood with fake charger connections.
Practical checklist
- Use
wss://everywhere. No exceptions. - Enable certificate validation on the charger side. If the vendor says "just disable it for testing" and never mentions turning it back on, push back.
- Unique passwords per charger, rotated on a schedule.
- HTTPS for all firmware and diagnostics URLs.
- Rate-limit and monitor WebSocket connections to your CSMS.
- Log every unknown charger ID that attempts to connect. it's either a misconfiguration or something worse.
- If you can manage it, aim for Profile 3 (mTLS). If not, Profile 2 with per-charger passwords is the pragmatic floor.
OCPP 1.6 security is not where the spec shines. The protocol itself doesn't enforce any of this. it's on you to configure it correctly. But the attack surface of a publicly-accessible EV charger handling payment credentials is real, and treating security as optional is a decision you'll eventually regret.