OCPP Security Profiles: What Each One Means

OCPP defines three security profiles that specify how the charger-to-CSMS communication is secured. If you are new to the protocol, what OCPP is covers the charger-to-CSMS relationship these profiles protect. Each profile balances security with implementation complexity. In production, only Profiles 2 and 3 are reasonable choices.

This article explains what each profile actually requires, how they differ, and which one to use in different operational contexts.

The three profiles

A summary first:

Profile	Transport	Client Auth	Server Auth	Production Use
1	Plain HTTP/WS	Basic auth (username/password)	None	Lab/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: Profile 1 has no transport security; Profile 2 has server-side TLS but client uses basic auth; Profile 3 has mutual TLS where both sides present certificates.

Profile 1: HTTP with Basic Auth

The minimum profile. Communication is plain HTTP / WebSocket. The charger authenticates itself to the CSMS via HTTP Basic Auth (a username and password in the Authorization header).

GET /ocpp/ws HTTP/1.1
Authorization: Basic Y2hhcmdlcjEyMzpwYXNzd29yZA==

The username/password authenticates the charger. There’s no encryption — everything (including the credentials themselves) is in cleartext on the wire.

When this is acceptable: isolated lab networks, completely controlled environments where you trust the network medium itself. Essentially never in production.

What’s exposed if compromised: an attacker on the network can read all OCPP traffic, including the credentials. They can then masquerade as the charger to the CSMS, or as the CSMS to the charger.

In 2026, Profile 1 is not appropriate for any deployment that touches the open internet. If your CSMS is still accepting Profile 1 connections from production chargers, you have a serious security problem.

Profile 2: TLS with Basic Auth

The minimum profile for production. TLS encryption (HTTPS for the upgrade, WSS for the WebSocket). The charger authenticates to the CSMS via Basic Auth (still username/password) over the encrypted channel.

The server (CSMS) presents an X.509 certificate. 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.
• Server certificate prevents MITM attacks.
• Implementation is straightforward — similar to any HTTPS API.
• Charger doesn’t need to manage its own certificate.

Disadvantages:

• Basic Auth credentials still need to be managed — created, distributed, rotated.
• Credential leakage (logs, source code) gives an attacker the ability to impersonate the charger.
• No infrastructure-level binding between the charger and the credential.

Profile 2 is the most common production deployment in 2026. It’s good enough for most use cases when combined with proper credential hygiene.

Profile 3: Mutual TLS

The highest profile. Mutual TLS — both client and server present certificates. The charger and CSMS authenticate each other at the TLS layer, before any application-level authentication.

The charger holds its own X.509 certificate (and private key). On every connection, it presents this certificate. The CSMS validates the certificate against its trust store. The server’s certificate is similarly validated by the charger.

After mTLS authentication, the connection is established. Application-level credentials (if any) flow over the now-mutually-authenticated channel.

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 established

Advantages:

• Strongest protection — even if application credentials leak, the attacker also needs the charger’s private key.
• Certificate binding to specific hardware (when keys are HSM-protected) makes credential compromise harder.
• Standards-compliant and well-understood at the infrastructure level.

Disadvantages:

• Certificate lifecycle is more operationally complex (issuance, renewal, revocation).
• Requires PKI infrastructure (you need to run or rely on a CA that issues charger certs).
• Implementation more complex than Profile 2.
• Some older charger firmware doesn’t support mTLS reliably.

Profile 3 is recommended for:

• High-security environments (regulated markets, sensitive deployments).
• Large fleets where credential rotation at scale is operationally desirable (rotate certificates centrally rather than passwords manually).
• Critical infrastructure where vulnerability to credential leakage matters more.

Choosing a profile

A decision framework.

Use Profile 1:

• Only in test labs.
• Never in production.

Use Profile 2:

• Standard production deployments.
• Mixed charger fleets where some don’t support mTLS well.
• Lower operational complexity is a priority.
• Combine with good credential hygiene (rotate, audit, store securely).

Use Profile 3:

• High-security deployments.
• Regulated environments.
• Large fleets where centralized certificate management is preferable to per-charger password management.
• New deployments where you’re building the PKI infrastructure anyway.

Most operators in 2026 are on Profile 2 with a roadmap to Profile 3 as their fleets refresh. Some new deployments are starting on Profile 3 directly.

The PKI requirements

If you’re going to Profile 3, you need PKI infrastructure.

A CA (Certificate Authority). Issues charger certificates. Could be:

• Your own internal CA (run by you).
• A managed CA (cloud-based, SaaS).
• A commercial CA (less common for OCPP given the closed nature of the trust).

Per-charger certificates. Each charger has its own certificate identifying it. Private key generated on the charger (ideally in HSM); CSR sent to CA; certificate returned and installed.

Renewal mechanism. Certificates expire (typically 1-3 years). Renewal must happen before expiration or the charger goes offline. The same delivery channel that handles firmware updates ^{(coming soon)} is often reused to push renewed certificates.

Revocation mechanism. If a charger is compromised or decommissioned, its certificate must be revoked. CRL or OCSP.

Audit trail. Who issued which cert? When? Why?

This is a meaningful operational commitment. It’s not “implement Profile 3 in code and you’re done.”

Credentials hygiene for Profile 2

If you’re on Profile 2, the security depends heavily on credential hygiene.

Generate strong passwords. Don’t use defaults; don’t use predictable patterns; use a CSPRNG.

Store passwords encrypted. In your CSMS database, use proper password storage (bcrypt or similar).

Never log passwords. Production logs should mask credential fields.

Rotate periodically. Quarterly or biannually depending on risk posture.

Rotate on personnel changes. When an engineer with access leaves, rotate.

Limit credential distribution. Only people who need them should have them.

Audit credential access. Who can read production credentials? Reviewed quarterly.

A Profile 2 deployment with sloppy credential management is less secure than Profile 1 with good operational discipline. The profile matters less than the practice.

What changed in OCPP 2.0.1

OCPP 1.6’s security profiles were defined in the Security extension (Edition 2, 2018). Adoption was uneven — many 1.6 deployments stayed on Profile 1 (or quasi-Profile-1 with TLS terminated at a proxy) for years.

OCPP 2.0.1 makes the security profiles native to the base specification. Mutual TLS is a first-class option. The expectation is that production deployments use Profile 2 minimum, Profile 3 preferred. For where this sits across releases, see the OCPP version comparison ^{(coming soon)}.

If you’re building OCPP 2.0.1 from scratch, Profile 3 is the right starting point. The operational complexity is real but manageable, and you avoid a future migration from Profile 2.

Common operational issues

A few things that go wrong with OCPP security in production.

Charger trust store not maintained. New CA certificates added but not pushed to chargers. Chargers can’t validate the CSMS’s certificate after a CA rotation.

Expired charger certificates (Profile 3). Charger’s cert expired; can’t connect; offline indefinitely until human intervention. Need a renewal process.

Compromised credentials reused. Charger A’s credentials leaked. Operator assumes only that charger is at risk. Turns out the same credentials were used for chargers B-Z. Now all those are compromised too.

TLS misconfiguration. Old TLS versions, weak ciphers. SSL Labs report would catch most of these.

Self-signed certificates accepted. Charger doesn’t validate the CSMS certificate properly, accepts self-signed. Vulnerable to MITM. Audit charger firmware for proper certificate validation.

Hostname mismatch. Certificate is for csms.example.com; charger connects to csms-prod.example.com via IP. Hostname mismatch — but charger accepts anyway because it’s not strict. Vulnerability.

The honest summary

OCPP security profiles are well-defined; the practical question is which to use and how to operate them. Profile 2 is the production baseline. Profile 3 is the high-security option. Profile 1 is for lab use only. Whichever profile you choose, the operational discipline (credential management, certificate lifecycle, TLS configuration, audit logging) matters more than the choice itself. Start with Profile 2 if you’re constrained, migrate to Profile 3 as your fleet refreshes and your operational maturity grows.