OCPP defines three security profiles that specify how charger-to-CSMS communication is protected. If you are new to the protocol, what OCPP is covers the relationship these profiles secure. Each profile trades security against implementation complexity, and in production only Profiles 2 and 3 are reasonable choices.
This article explains what each profile actually requires, how they differ, and which one fits which operational context.
The three profiles
A summary first:
| Profile | Transport | Client auth | Server auth | Production use |
|---|---|---|---|---|
| 1 | Plain HTTP/WS | Basic auth (username and password) | None | Lab and test only |
| 2 | TLS (HTTPS/WSS) | Basic auth | Server certificate | Production-acceptable |
| 3 | TLS (HTTPS/WSS) | Client certificate (mTLS) | Server certificate | Production-recommended for high security |
The progression is straightforward. Profile 1 has no transport security. Profile 2 adds server-side TLS while the client still uses basic auth. Profile 3 uses mutual TLS, where both sides present certificates.
Profile 1: HTTP with Basic Auth
The minimum profile. Communication is plain HTTP and WebSocket. The charger authenticates itself to the CSMS with HTTP Basic Auth, a username and password in the Authorization header.
GET /ocpp/ws HTTP/1.1
Authorization: Basic Y2hhcmdlcjEyMzpwYXNzd29yZA==There is no encryption. Everything, including the credentials, travels in cleartext.
When this is acceptable: isolated lab networks and completely controlled environments where you trust the physical medium. Essentially never in production.
What an attacker gets: anyone on the network path can read all OCPP traffic including the credentials, then impersonate the charger to the CSMS or the CSMS to the charger.
If your CSMS is still accepting Profile 1 connections from production chargers, that is a live security problem rather than a backlog item.
Profile 2: TLS with Basic Auth
The minimum profile for production. TLS encryption via HTTPS for the upgrade and WSS for the WebSocket, with the charger authenticating over that encrypted channel using basic auth.
The CSMS presents an X.509 certificate, and the charger validates it against its trust store.
GET /ocpp/ws HTTP/1.1
Host: csms.example.com
Authorization: Basic Y2hhcmdlcjEyMzpwYXNzd29yZA==
Upgrade: websocket
[... TLS handshake first ...]Advantages:
- Encryption protects traffic from eavesdropping.
- The server certificate prevents man-in-the-middle attacks, provided the charger validates it properly.
- Implementation is straightforward, much like any HTTPS API.
- The charger does not need to manage a certificate of its own.
Disadvantages:
- Basic auth credentials still have to be created, distributed, and rotated.
- Credential leakage through logs or source control lets an attacker impersonate the charger.
- There is no infrastructure-level binding between a specific piece of hardware and its credential.
Profile 2 is the common landing spot because it gets you TLS without taking on per-charger certificate lifecycle management. That trade is reasonable, as long as you actually do the credential work it leaves you holding.
Profile 3: Mutual TLS
The strongest profile. Both client and server present certificates, so charger and CSMS authenticate each other at the TLS layer before any application-level authentication happens.
The charger holds its own X.509 certificate and private key, and presents that certificate on every connection. The CSMS validates it against its trust store, and the charger validates the server’s certificate in the same way.
sequenceDiagram
participant C as Charger
participant S as CSMS
C->>S: ClientHello
S->>C: ServerHello + server cert
C->>S: Client cert + key exchange
Note over C,S: Both certs validated
C->>S: WebSocket upgrade over WSS
S->>C: OCPP session establishedAdvantages:
- Even if application credentials leak, an attacker still needs the charger’s private key.
- Binding the certificate to specific hardware, ideally with an HSM-protected key, makes compromise substantially harder.
- It is standards-compliant and well understood at the infrastructure level, so your existing PKI tooling applies.
Disadvantages:
- Certificate lifecycle is genuinely more complex: issuance, renewal, revocation.
- You need PKI infrastructure, whether you run it or buy it.
- Implementation is more involved than Profile 2.
- Older charger firmware does not always handle mTLS reliably, which you discover during rollout rather than during procurement.
Profile 3 earns its cost in regulated markets, in large fleets where rotating certificates centrally beats managing passwords per charger, and in any deployment where credential leakage would be more than an inconvenience.
Choosing a profile
Use Profile 1 in test labs, and nowhere else.
Use Profile 2 for standard production deployments, for mixed fleets where some hardware does not support mTLS well, and where lower operational complexity is worth more to you than the marginal security gain. Pair it with genuine credential hygiene.
Use Profile 3 for high-security or regulated deployments, for large fleets where centralized certificate management scales better than per-charger passwords, and for new builds where you are standing up PKI anyway.
The most useful way to make this decision is not to ask which profile is best, but to ask which failure you are more likely to actually suffer: a leaked password that nobody rotated, or an expired certificate that nobody renewed. Both are operational failures. Pick the one your team is better equipped to prevent.
The PKI requirements
Going to Profile 3 means running real PKI.
A Certificate Authority. It issues charger certificates, and it can be an internal CA you run, a managed cloud CA, or a commercial CA, though the last is less common given how closed the trust domain is.
Per-charger certificates. Each charger has its own certificate. The private key is generated on the charger, ideally inside an HSM, a CSR goes to the CA, and the certificate comes back to be installed.
A renewal mechanism. Certificates expire, typically after one to three years. Renewal has to happen before expiry or the charger drops offline and stays there. The channel that handles firmware updates is often reused to push renewed certificates.
A revocation mechanism. When a charger is compromised or decommissioned, its certificate must be revoked, via CRL or OCSP.
An audit trail. Who issued which certificate, when, and why.
This is a meaningful operational commitment. Implementing Profile 3 in code is the small half of the work.
Credentials hygiene for Profile 2
On Profile 2, your security is almost entirely a function of credential hygiene.
Generate strong passwords from a CSPRNG. No defaults, no predictable patterns, no “chargerID + site name”.
Store them properly in your CSMS, hashed with bcrypt or equivalent.
Never log them. Production logs must mask credential fields, and this needs a test that proves it.
Rotate on a schedule appropriate to your risk posture, and immediately when someone with access leaves.
Limit distribution to the people who genuinely need it, and audit who can read production credentials.
Never share a credential across chargers. This is the one that turns a single leak into a fleet-wide incident.
A Profile 2 deployment with sloppy credential management is less secure than Profile 1 with excellent operational discipline. The profile number is what you can put in a procurement document. The practice is what actually protects you.
What changed in OCPP 2.0.1
OCPP 1.6’s security profiles arrived through the Security extension in 2018, as an optional add-on rather than part of the core. Anything optional in a protocol gets implemented unevenly, and the profiles were no exception.
OCPP 2.0.1 makes them native to the base specification, with mutual TLS as a first-class option rather than an appendix. For where this sits across releases, see the OCPP version comparison.
If you are building OCPP 2.0.1 from scratch, Profile 3 is the right starting point. The operational complexity is real but bounded, and starting there avoids a migration later that will be considerably less pleasant than doing it now.
Common operational issues
Charger trust store not maintained. New CA certificates are added at the CSMS but never pushed to chargers, so after a CA rotation the fleet cannot validate the server and drops off. This is a scheduled outage that nobody scheduled.
Expired charger certificates on Profile 3. The certificate lapses, the charger cannot connect, and it stays offline until a human intervenes. Renewal has to be automated and monitored, not diarised.
Reused credentials. Charger A’s credentials leak, the operator assumes only charger A is exposed, and then discovers the same credential was provisioned to every charger commissioned that quarter.
TLS misconfiguration. Obsolete TLS versions and weak ciphers on the CSMS endpoint. A standard TLS scanner finds these in minutes, and it is worth running one on a schedule rather than once at launch.
Self-signed certificates silently accepted. The charger does not validate the CSMS certificate properly and accepts whatever it is handed, which reduces Profile 2 to Profile 1 with extra steps. Audit firmware for real validation rather than trusting the datasheet.
Hostname mismatch tolerated. The certificate is for csms.example.com, the charger connects by IP or to a different hostname, and the firmware accepts it anyway. Same outcome as above.
The honest summary
The profiles themselves are well defined and not especially hard to understand. Profile 2 is the production baseline, Profile 3 is the high-security option, Profile 1 is for the lab.
The part worth taking seriously is that four of the six failures listed above are not protocol problems at all. They are expiry dates nobody tracked, credentials nobody rotated, and validation nobody verified. A fleet on Profile 3 with unmonitored certificate expiry will have a worse year than a fleet on Profile 2 that rotates passwords properly, because the Profile 3 failure takes chargers offline in batches on a date you could have known in advance.
Choose the profile your operations can actually sustain, then invest in the lifecycle machinery rather than the profile number.