What are OCPP security profiles?

OCPP security profiles define how a charging station and charging station management system (CSMS or CPMS) authenticate and protect their OCPP connection. They cover the charger-to-management-system link. They do not, by themselves, secure the complete charger, backend, mobile app or wider network.

 

OCPP 2.x uses three named profiles: Profiles 1, 2 and 3. Some OCPP 1.6 security-extension tools also refer to Profile 0 as an unprotected starting state. It has neither TLS transport security nor Basic Authentication and should not be treated as a secure field configuration. The OCPP 1.6 Security Whitepaper explains how later security functions can be added to OCPP 1.6-J.

Security Profile 1: Basic Authentication without TLS

Profile 1 uses an unencrypted WebSocket connection with HTTP Basic Authentication. The password lets the charger identify itself to the CPMS, but the CPMS is not authenticated to the charger and the traffic is not protected in transit.

 

The Open Charge Alliance states in its OCPP Security Operations Guide that Profile 1 is not secure by itself. It may sit behind a correctly configured private network or VPN, but the protection then depends on that network. For internet-facing deployments, TLS should be used.

Security Profile 2: TLS plus Basic Authentication

Profile 2 uses a secure WebSocket connection over TLS. The charger validates the CPMS server certificate, the connection is encrypted and the charger authenticates with a password.

 

Each charger should have unique credentials. Operators also need a controlled process for initial provisioning, password rotation, certificate-authority changes and recovery when credentials are lost. A shared fleet-wide password weakens the benefit of the profile.

Security Profile 3: mutual TLS with client certificates

Profile 3 adds a client certificate for the charging station. The charger validates the CPMS certificate, while the CPMS validates the charger certificate. This provides stronger two-way identity than a password alone.

 

The trade-off is certificate lifecycle management. The project needs a public key infrastructure, secure private-key storage and tested processes for enrolment, renewal, expiry, revocation and replacement. A stronger profile can still fail operationally if those processes are unclear.

How this applies to amina charging stations

amina’s OCPP 1.6j documentation states that LTE WebSocket connections use TLS 1.2 or higher, HTTP Basic Authentication is supported and charger credentials are provisioned during production. The CSMS can later change the password through ChangeConfiguration using the AuthorizationKey setting.

 

The documentation also lists client-certificate support and signed OTA firmware updates. The CSMS integration guide says certificates and the chosen CSMS endpoint can be provisioned before delivery. Operators should still confirm the enabled security profile, certificate chain and renewal process for the exact order and firmware. These documented building blocks do not, by themselves, prove that every deployment is using Security Profile 3.

Which OCPP security profile should operators require?

For an internet-facing charger, Profile 2 is the practical minimum in most projects. Profile 3 may be appropriate where mutual certificate authentication is required and the operator or CPMS provider can manage the certificate lifecycle reliably.

 

OCPP 2.x implementations require the secured connection model rather than an unsecured fallback. The Open Charge Alliance also made Security Profile 2 part of the updated OCPP 1.6 Core certification requirements. Certification and profile support reduce uncertainty, but neither replaces testing of the exact charger, firmware and CPMS combination.

What should be checked before deployment?

  • the OCPP version and security extension used by the charger and CPMS;
  • the highest profile supported and the profile enabled in production;
  • who owns, provisions and rotates passwords and certificates;
  • how certificate expiry, revocation and clock errors are handled;
  • whether hostname and certificate validation are enforced;
  • whether a failed secure connection can cause an unsafe downgrade;
  • how security events and failed authentication attempts are logged; and
  • whether firmware, diagnostics and other related channels are protected.

Record these decisions in the integration specification. “Supports OCPP” is not enough to establish how the connection is secured in practice.