OCPP Security Profiles Explained: TLS, Certificates & Authentication in OCPP 2.0.1

Every EV charge point is a network-connected computer that processes payment data, controls high-voltage equipment, and communicates with backend systems over the public internet. A compromised charger is not a theoretical risk --- it is a physical safety hazard, a payment fraud vector, and a potential entry point into an operator's entire network. OCPP 2.0.1 introduced mandatory security profiles specifically because the previous generation of the protocol left security as an afterthought, and the industry paid for it.

This guide covers the three OCPP 2.0.1 security profiles in detail: what each one provides, how they work at the protocol level, when to use each, and how to implement and test them correctly.

The Security Problem in OCPP 1.6

OCPP 1.6 treated security as optional. The specification mentioned TLS but did not mandate it, define authentication mechanisms, or provide any certificate management framework. In practice, this led to widespread vulnerabilities across production charging networks.

What went wrong

Unencrypted WebSocket connections in production. The majority of OCPP 1.6 deployments use ws:// rather than wss://. Every message --- including charger credentials, transaction data, and configuration commands --- travels in plaintext. Anyone on the same network segment can read and modify these messages.

No standardized authentication. OCPP 1.6 does not define how a CSMS should verify that an incoming WebSocket connection actually comes from a legitimate charge point. Many implementations rely solely on the charger's serial number in the URL path (/ocpp/CP001), which is trivially spoofable.

No firmware signing. When a CSMS pushes a firmware update to a charger over OCPP 1.6, there is no mechanism to verify the firmware's authenticity. An attacker who can intercept or modify the firmware URL can push arbitrary code to the charge point.

Man-in-the-middle exposure. Without TLS, an attacker positioned between the charger and the CSMS can intercept messages, inject fraudulent transaction data, modify charging profiles, or issue remote commands to the charger --- including stopping or starting sessions, changing power limits, or resetting the device.

Real-world risk scenarios

These are not hypothetical. Publicly documented incidents and security research have demonstrated:

• Session hijacking: Spoofing a charger identity to report phantom transactions or steal revenue from legitimate sessions.
• Free charging fraud: Manipulating transaction messages to avoid billing.
• Charger bricking: Pushing malicious firmware that renders charge points inoperable, requiring physical truck rolls to recover.
• Network lateral movement: Using a compromised charge point as a pivot to access the operator's internal systems, including payment processing and customer databases.

The Open Charge Alliance recognized these risks and made security a first-class concern in OCPP 2.0.1.

OCPP 2.0.1 Security Profiles Overview

OCPP 2.0.1 defines three security profiles that provide progressively stronger authentication and encryption. Every conformant implementation must support at least one profile, and the specification strongly recommends Profile 2 or 3 for any internet-facing deployment.

The profile is configured on the charge point via the SecurityProfile variable in the Security component, and the CSMS must be configured to accept connections at the corresponding security level.

Security Profile 1: Basic Authentication

Security Profile 1 provides the minimum level of identity verification: the charge point authenticates itself to the CSMS using HTTP Basic Authentication transmitted during the WebSocket handshake. No TLS encryption is used.

How it works

1. The charge point initiates a WebSocket connection to the CSMS at a ws:// endpoint.
2. The HTTP Upgrade request includes an Authorization header containing the Base64-encoded chargePointId:password string.
3. The CSMS decodes the credentials, validates them against its database, and either accepts the WebSocket upgrade or rejects it with HTTP 401.
4. All subsequent OCPP messages travel over the unencrypted WebSocket connection.

Password management

The charger's authentication password is configured via the BasicAuthPassword variable. OCPP 2.0.1 specifies that passwords must be at least 16 characters and should be rotated periodically. The CSMS can trigger a password change by sending a SetVariables request to update the BasicAuthPassword, after which the charger reconnects with the new credentials.

When to use Profile 1

Profile 1 is appropriate only when:

• The charger and CSMS communicate over a physically isolated private network (e.g., a dedicated VPN or private APN on a cellular connection).
• No sensitive data traverses the connection, or the network itself provides encryption at a lower layer.
• Regulatory requirements do not mandate transport-layer encryption.

In every other scenario, Profile 1 is insufficient. The password travels in Base64 encoding (not encryption) and is visible to any network observer. Do not use Profile 1 over the public internet.

Risks

• All traffic is plaintext --- credentials, transaction data, and commands are fully exposed.
• Susceptible to credential theft via packet capture.
• No protection against man-in-the-middle attacks.
• An attacker who captures the password can impersonate the charger indefinitely until the password is rotated.

Security Profile 2: TLS with Server Certificate

Security Profile 2 adds TLS encryption to the Basic Authentication mechanism. The charger verifies the CSMS server's identity via its TLS certificate, and all communication is encrypted. This is the recommended minimum for any production deployment.

How it works

1. The charge point initiates a TLS handshake with the CSMS at a wss:// endpoint.
2. The CSMS presents its server certificate. The charger validates the certificate against its trusted root certificate store (the CACertificateStore or a pre-provisioned root CA).
3. Once the TLS session is established, the charger sends the HTTP Upgrade request with the Authorization header containing Basic Auth credentials, just as in Profile 1 --- but now encrypted within the TLS tunnel.
4. The CSMS validates the credentials and accepts or rejects the connection.
5. All subsequent OCPP messages travel over the encrypted WebSocket connection.

TLS configuration requirements

OCPP 2.0.1 specifies concrete requirements for the TLS configuration:

Minimum TLS version: TLS 1.2 is the minimum. TLS 1.3 is recommended where both sides support it. TLS 1.0 and 1.1 are explicitly prohibited.

Cipher suites: The specification recommends cipher suites providing forward secrecy. Acceptable examples include:

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_AES_128_GCM_SHA256 (TLS 1.3)
• TLS_AES_256_GCM_SHA384 (TLS 1.3)

Cipher suites without forward secrecy (e.g., RSA key exchange) or using CBC mode should be disabled.

Certificate requirements: The server certificate must be a valid X.509v3 certificate. The charger validates the certificate chain up to a trusted root CA. The certificate's Common Name (CN) or Subject Alternative Name (SAN) must match the CSMS hostname.

Certificate provisioning

For Profile 2, you need to provision the charger with the root CA certificate that signed the CSMS server certificate. This can be done:

• At manufacturing: Pre-load the charger with a set of trusted root CAs (similar to how browsers ship with trusted roots).
• During commissioning: Install the root CA certificate via a local interface or initial unencrypted connection, then switch to Profile 2.
• Via OCPP: Use the InstallCertificate message to push the root CA certificate to the charger (though this requires an already-established connection).

When to use Profile 2

Profile 2 is appropriate for:

• Standard production deployments over the public internet.
• Environments where the CSMS identity must be verified but individual charger certificate management is operationally burdensome.
• Deployments where HTTP Basic Auth provides sufficient client authentication for the threat model.

Profile 2 protects against network eavesdropping and server impersonation. It does not protect against a stolen charger password being used from a different device --- the CSMS cannot distinguish between the real charger and an attacker using the same credentials from a different machine.

Security Profile 3: Mutual TLS (mTLS)

Security Profile 3 is the gold standard. Both the charger and the CSMS authenticate each other using X.509 certificates. No passwords are involved --- identity is proven cryptographically.

How it works

1. The charge point initiates a TLS handshake with the CSMS at a wss:// endpoint.
2. The CSMS presents its server certificate. The charger validates it against its trusted root CA store.
3. The CSMS requests the client certificate. The charger presents its own X.509 certificate.
4. The CSMS validates the charger's certificate against its trusted root CA store. If the certificate is valid and not revoked, the TLS handshake completes.
5. The WebSocket upgrade proceeds without an Authorization header --- the TLS client certificate has already authenticated the charger.
6. All communication is encrypted and both endpoints are cryptographically verified.

Why mTLS is stronger

With Profile 2, a stolen password can be used from any device. With Profile 3, the charger's private key never leaves the device. Even if an attacker captures network traffic, they cannot extract the private key from the TLS handshake. To impersonate a charger, an attacker would need physical access to extract the private key from the device's secure storage --- a significantly higher barrier.

mTLS also eliminates the operational burden of password management. There are no passwords to rotate, no risk of weak passwords, and no credentials transmitted in HTTP headers.

PKI requirements

Profile 3 requires a functioning Public Key Infrastructure (PKI):

Certificate Authority (CA): You need a CA to issue certificates to both the CSMS and individual charge points. This can be:

• A private CA operated by the CPO or CSMS vendor (most common for charge point certificates).
• A public CA like Let's Encrypt or DigiCert for the CSMS server certificate.
• A managed PKI service from a cloud provider (AWS Private CA, Azure Key Vault, Google Cloud CA Service).

Certificate lifecycle: Each charge point needs its own unique certificate. This means provisioning certificates at manufacturing or commissioning, rotating them before expiry, and revoking them if a device is decommissioned or compromised.

Secure key storage: The charger must store its private key in a secure element or trusted platform module (TPM) to prevent extraction. The specification recommends hardware-backed key storage.

When to use Profile 3

Profile 3 is appropriate for:

• High-security deployments in regulated industries (government facilities, military installations, critical infrastructure).
• Networks where charger impersonation is a material threat.
• Operators who have the infrastructure to manage a PKI and certificate lifecycle.
• Deployments that require compliance with standards like ISO 15118 Plug & Charge, which also relies on certificate-based authentication.

The primary barrier to Profile 3 adoption is operational complexity. Managing certificates for thousands of charge points requires automation, monitoring for approaching expiry dates, and a revocation strategy. For many operators, Profile 2 provides sufficient security with significantly less operational overhead.

Certificate Management in OCPP 2.0.1

OCPP 2.0.1 includes dedicated messages for managing certificates on charge points over the OCPP connection itself. This is critical for Profile 2 and Profile 3 deployments where certificates need to be updated remotely.

InstallCertificate

The CSMS sends InstallCertificate to push a new certificate to the charge point. The message specifies the certificate type:

• CentralSystemRootCertificate --- Root CA used to validate the CSMS server certificate.
• ManufacturerRootCertificate --- Root CA used to validate firmware signing certificates.
• V2GRootCertificate --- Root CA for ISO 15118 Vehicle-to-Grid communication.

The charger validates the certificate format and stores it. If storage is full or the certificate is malformed, the charger responds with Rejected.

GetInstalledCertificateIds

The CSMS sends GetInstalledCertificateIds to query which certificates are currently installed on the charger. The response includes the certificate hash (issuer name hash, issuer key hash, serial number) for each installed certificate. This allows the CSMS to audit a charger's certificate store and determine if updates are needed.

DeleteCertificate

The CSMS sends DeleteCertificate to remove a specific certificate from the charge point, identified by its certificate hash data. This is used to revoke trust in a compromised CA or remove expired certificates.

CertificateSigningRequest

For Profile 3, when a charger needs a new client certificate (initial provisioning or renewal), it generates a key pair locally and sends a SignCertificate request containing the CSR (Certificate Signing Request). The CSMS forwards the CSR to the CA, obtains the signed certificate, and delivers it back to the charger via CertificateSigned. This ensures the private key is generated on the charger and never transmitted.

Certificate rotation workflow

A typical certificate renewal for Profile 3 follows this sequence:

1. The CSMS monitors certificate expiry dates (queried via GetInstalledCertificateIds).
2. Before expiry, the CSMS triggers the charger to generate a new CSR via TriggerMessage with SignCertificate.
3. The charger generates a new key pair and sends SignCertificate with the CSR.
4. The CSMS submits the CSR to the CA and receives the signed certificate.
5. The CSMS sends CertificateSigned with the new certificate.
6. The charger installs the new certificate and begins using it on the next TLS handshake.

This entire workflow happens over the existing OCPP connection without physical access to the charger.

Signed Firmware Updates

OCPP 2.0.1 addresses the firmware tampering risk from OCPP 1.6 with cryptographic signature verification for firmware updates.

How signed firmware works

1. The CSMS sends a SignedUpdateFirmware request containing the firmware download URL, the expected signing certificate, and the firmware signature.
2. The charger downloads the firmware from the specified URL.
3. Before installing, the charger verifies the firmware signature against the signing certificate. The signing certificate itself is validated against the ManufacturerRootCertificate installed on the charger.
4. If the signature is valid, the charger installs the firmware and reports Installed via FirmwareStatusNotification.
5. If verification fails, the charger rejects the update and reports InvalidSignature.

Secure boot chain

Signed firmware is most effective when combined with secure boot:

1. Hardware root of trust: The bootloader is stored in read-only memory and cannot be modified.
2. Chain of trust: The bootloader verifies the OS image signature before loading it. The OS verifies application firmware signatures before executing.
3. Runtime integrity: The charge point periodically verifies its own firmware integrity and reports anomalies.

Together, signed firmware and secure boot ensure that only authorized code runs on the charge point, from power-on through normal operation.

Implementation Recommendations

Choosing the right profile

Start with Profile 2 for most deployments. It provides encrypted communication and server authentication with manageable operational complexity. The majority of production OCPP 2.0.1 networks run Profile 2.

Use Profile 3 when:

• Your threat model specifically includes charger impersonation.
• Regulatory requirements mandate mutual authentication.
• You are deploying ISO 15118 Plug & Charge (which requires its own certificate infrastructure, making the incremental cost of mTLS lower).
• You have or can build the PKI infrastructure to manage per-device certificates.

Avoid Profile 1 for internet-facing deployments. If you must use it, ensure the network provides encryption at a lower layer (IPsec VPN, private APN with encryption).

TLS setup checklist

For Profile 2 and 3 deployments:

1. Obtain a server certificate from a public CA for your CSMS endpoint. Use a SAN that matches your WebSocket URL hostname.
2. Configure TLS 1.2 minimum on your CSMS. Disable TLS 1.0, 1.1, and all weak cipher suites.
3. Enable forward secrecy by prioritizing ECDHE cipher suites.
4. Provision chargers with the root CA certificate that signs your server certificate. For public CAs, most charger firmware includes standard root stores.
5. Implement OCSP stapling or CRL checking on the CSMS to enable certificate revocation validation.
6. Monitor certificate expiry and automate renewal. A single expired certificate can take down connectivity for your entire fleet.

Certificate authority options

For most operators, a hybrid approach works well: public CA for the CSMS server certificate (Profile 2) and private or managed CA for charge point client certificates (Profile 3).

How to Test OCPP Security Profiles

Security configuration is one of the most common sources of interoperability issues in OCPP deployments. A charger that works perfectly on an unencrypted connection may fail silently when TLS is enabled due to certificate chain issues, cipher suite mismatches, or incorrect hostname validation.

What to test

Profile 1 testing:

• Verify the charger sends correct Basic Auth credentials in the WebSocket upgrade request.
• Test with incorrect passwords --- the CSMS should reject with HTTP 401.
• Confirm password rotation works: update BasicAuthPassword via SetVariables, verify the charger reconnects with the new password.

Profile 2 testing:

• Verify TLS handshake completes successfully with a valid server certificate.
• Test with an expired server certificate --- the charger should refuse to connect.
• Test with a self-signed certificate not in the charger's trust store --- connection should fail.
• Verify cipher suite negotiation uses forward-secrecy suites.
• Test InstallCertificate for updating the root CA on the charger.
• Confirm the charger validates the server certificate's hostname against the connection URL.

Profile 3 testing:

• Verify mutual TLS handshake with valid client and server certificates.
• Test with a revoked client certificate --- the CSMS should reject the connection.
• Test the full SignCertificate / CertificateSigned workflow for certificate provisioning.
• Verify certificate rotation without connection downtime.
• Test GetInstalledCertificateIds to audit the charger's certificate store.
• Confirm DeleteCertificate correctly removes certificates and the charger stops trusting the deleted CA.

Firmware signing testing:

• Send a SignedUpdateFirmware with a valid signature --- firmware should install.
• Send a SignedUpdateFirmware with a tampered signature --- charger should reject with InvalidSignature.
• Test with an expired signing certificate.

Testing with OCPPLab

OCPPLab provides an OCPP emulator that supports all three security profiles, allowing you to test your CSMS or charge point firmware against each profile configuration without deploying physical hardware. You can simulate TLS connections, certificate exchanges, and the full certificate lifecycle management workflow, catching configuration issues before they reach production.

For a broader overview of OCPP testing strategies and tools, see our OCPP testing guide.

Frequently Asked Questions

Is OCPP 2.0.1 security mandatory?

Yes. Every OCPP 2.0.1 implementation must support at least one security profile. The specification does not allow unprotected connections without a declared profile. However, the choice of which profile to implement is left to the deployer. In practice, conformance testing programs from the OCA verify security profile support.

Can I upgrade from Profile 1 to Profile 2 or 3 remotely?

Yes, but with caveats. You can push a root CA certificate via InstallCertificate over an existing Profile 1 connection, then change the SecurityProfile variable to 2 via SetVariables. The charger will reconnect using TLS. Upgrading to Profile 3 requires provisioning a client certificate, which involves the SignCertificate workflow. The initial Profile 1 connection is unencrypted, so this upgrade path should ideally happen on a trusted network during commissioning.

What happens if a charger's certificate expires?

If a Profile 3 charger's client certificate expires, the CSMS will reject the TLS handshake and the charger will be unable to connect. This is why proactive certificate monitoring and renewal is critical. Most implementations trigger renewal 30-60 days before expiry. If a certificate does expire, the charger typically requires a local intervention (physical access or local API) to install a new certificate or temporarily downgrade to Profile 2 with Basic Auth to re-establish connectivity.

Do I need a separate PKI for OCPP and ISO 15118?

They are technically separate trust chains. The OCPP PKI handles charger-to-CSMS authentication. The ISO 15118 PKI (V2G PKI) handles vehicle-to-charger authentication for Plug & Charge. However, some operators share infrastructure components (the same CA software, HSMs, and monitoring tools) between the two PKIs to reduce operational costs. The root certificates are distinct and installed via different certificate types in InstallCertificate.

How does OCPP security relate to PCI DSS compliance?

OCPP security profiles help meet PCI DSS requirements for encrypting cardholder data in transit, but they are not sufficient on their own. PCI DSS covers the entire payment processing chain, including data storage, access controls, and network segmentation. Profile 2 or 3 addresses the transport encryption requirement between the charger and CSMS. Additional measures are needed for end-to-end payment security.

Can I use Let's Encrypt certificates for my CSMS?

Yes, and many operators do. Let's Encrypt certificates are trusted by most charger firmware out of the box (since chargers typically ship with standard root CA stores). The 90-day validity requires automated renewal via ACME, which is straightforward for server-side certificates. Let's Encrypt does not issue client certificates, so you will need a separate CA for Profile 3 charge point certificates.

Further Reading

• What is OCPP? The Complete Guide --- Foundational overview of the protocol, message types, and architecture.
• OCPP 1.6 vs 2.0.1: Complete Comparison --- Detailed comparison including security, smart charging, and migration guidance.
• OCPP WebSocket Guide --- Deep dive into WebSocket connection management, TLS configuration, and reconnection strategies.
• OCPP Testing Guide --- Comprehensive guide to testing OCPP implementations, including security profile validation.