Security - CSMS Developer Guide
Based on the "Improved security for OCPP 1.6-J" white paper, Edition 4 (2026-02-05). This guide covers secure connection setup, security profiles, TLS configuration, certificate management, credential updates, and security event logging for OCPP 1.6-J implementations.
1. Scope & Overview
Section 1This white paper describes how the security enhancements, introduced in OCPP 2.x, can be used on top of OCPP 1.6-J, in a standardized way. The security part of OCPP 2.x was developed to strengthen and mature the future development and standardization of OCPP. Security requirements are included for both Charge Point and Central System, to help developers build a secure OCPP implementation.
Secure Connection Setup
TLS-based security with X.509 certificates and three security profiles for different deployment scenarios.
Security Events/Logging
Security event notification system to monitor and log security-related events in the charging infrastructure.
Secure Firmware Update
Cryptographic verification of firmware images to ensure source authenticity and integrity.
Security Objectives
OCPP security has been designed to meet these objectives:
- 1 To allow the creation of a secure communication channel between the Central System and Charge Point. The integrity and confidentiality of messages on this channel should be protected with strong cryptographic measures.
- 2 To provide mutual authentication between the Charge Point and the Central System. Both parties should be able to identify who they are communicating with.
- 3 To provide a secure firmware update process by allowing the Charge Point to check the source and the integrity of firmware images, and by allowing non-repudiation of these images.
- 4 To allow logging of security events to facilitate monitoring the security of the smart charging system.
Design Considerations
This document was designed to fit into the approach taken in OCPP. Standard web technologies are used whenever possible to allow cost-effective implementations using available web libraries and software. No application layer security measures are included. Based on these considerations, OCPP security is based on TLS and public key cryptography using X.509 certificates.
Important: Because the Central System usually acts as the server, different users or role-based access control on the Charge Point are not implemented in this standard. To mitigate this, it is recommended to implement access control on the Central System.
Note: OCPP should not be used by qualified personnel performing maintenance to Charge Points locally at the Charge Point, as other protocols may be used for local maintenance purposes.
OCPP-J Only
This document is for OCPP 1.6-J (JSON over WebSockets) only, OCPP-S (SOAP) is NOT supported. This document was started as it is seen as a simple step to port OCPP 2.x security to OCPP 1.6. But as OCPP 2.x only supports JSON over WebSockets (not SOAP), this document is also written for OCPP 1.6-J only.
Conventions
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119.
Note: The phrase "valid reasons in particular circumstances" relating to the usage of SHOULD, SHOULD NOT, RECOMMENDED, and NOT RECOMMENDED is to be taken to mean technically valid reasons, such as the absence of necessary hardware. It specifically excludes decisions made on commercial grounds.
References
| Reference | Description |
|---|---|
[1] | ENISA - Algorithms, key size and parameters report 2014 |
[2] | RFC 5280 - X.509 PKI Certificate and CRL Profile |
[3] | RFC 5246 - TLS Protocol Version 1.2 |
[4] | RFC 3749 - TLS Compression Methods |
[5] | BSI AIS 20 - Deterministic Random Number Generators |
[6] | RFC 4210 - Certificate Management Protocol (CMP) |
[7] | NIST SP 800-57 - Recommendation for Key Management |
[8] | RFC 2617 - HTTP Authentication |
[9] | RFC 5280 - X.509 PKI Certificate and CRL Profile |
[10] | OCPP 1.6 - Interface description, October 2015 |
[11] | LaQuSo - End-to-end security design for smart EV-charging |
[12] | RFC 2818 - HTTP Over TLS |
[13] | RFC 2119 - Key words for use in RFCs |
[14] | RFC 2986 - PKCS #10: Certification Request Syntax v1.7 |
[15] | RFC 6960 - X.509 OCSP |
2. Security Profiles
Section 2This section defines the different OCPP security profiles and their requirements. This White Paper supports three security profiles.
Profiles Overview
| Profile | Charge Point Authentication | Central System Authentication | Communication Security |
|---|---|---|---|
| 1. Unsecured Transport with Basic Authentication | HTTP Basic Authentication | - | - |
| 2. TLS with Basic Authentication | HTTP Basic Authentication | TLS authentication using certificate | Transport Layer Security (TLS) |
| 3. TLS with Client Side Certificates | TLS authentication using certificate | TLS authentication using certificate | Transport Layer Security (TLS) |
- The Unsecured Transport with Basic Authentication Profile does not include authentication for the Central System, or measures to set up a secure communication channel. It should only be used in trusted networks (e.g., VPN between Central System and Charge Point).
- When the Charge Point does not have the correct date and time set, it cannot validate the server certificate. A solution might be to use NTP, mobile network to set time automatically, or have an installer tool set the time before the first connection.
Generic Requirements
Generic Security Profile requirements that apply across all profiles.
| ID | Precondition | Requirement Definition |
|---|---|---|
A00.FR.001 | The Charge Point and Central System SHALL only use one security profile at a time. | |
A00.FR.002 | If the Charge Point tries to connect with a different profile than the Central System is using. | The Central System SHALL reject the connection. |
A00.FR.004 | The security profile SHALL be configured before OCPP communication is enabled. | |
A00.FR.005 | Lowering the security profile is not recommended. The Charge Point SHALL only allow lowering if AllowSecurityProfileDowngrade is implemented and set to true. Only downgrade from profile 3 to profile 2. SHALL NOT allow downgrade from profile 2 or 3 to profile 1 using OCPP. | |
A00.FR.006 | When a Central System communicates with Charge Points with different security profiles or different versions of OCPP. | The Central System MAY operate via different addresses or ports. For instance, one TCP port for TLS with Basic Authentication and another for TLS with Client Side Certificates. |
Note: Only securing the OCPP communication is not enough to build a secure Charge Point. All other interfaces to the Charge Point should be equally well secured.
Profile 1 - Unsecured Transport with Basic Authentication
Profile 1The Unsecured Transport with Basic Authentication profile provides a low level of security. Charge Point authentication is done through a username and password. No measures are included to secure the communication channel.
Charge Point Auth
HTTP Basic authentication
Central System Auth
Not authenticated (CP must trust server)
Communication Security
No security measures included
Recommended For
Trusted networks only (e.g., VPN)
Profile 1 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
A00.FR.201 | The profile SHOULD only be used in trusted networks. | |
A00.FR.202 | The Charge Point SHALL authenticate itself to the Central System using HTTP Basic authentication. | |
A00.FR.203 | A00.FR.202 | The client SHALL provide a username and password with every connection request. |
A00.FR.204 | A00.FR.203 | The username SHALL be equal to the Charge Point identity as it uses it in the OCPP-J connection URL. |
A00.FR.205 | The password SHALL be stored in the AuthorizationKey Configuration Key. Minimal 16-bytes long, strongly advised to be randomly generated binary for maximal entropy. Hexadecimal represented (20 bytes max, up to 40 hex digits). | |
A00.FR.206 | A00.FR.203 | With HTTP Basic, credentials are transmitted in clear text (base64 only). Hence, RECOMMENDED only over already secured connections (e.g., VPNs). |
A00.FR.207 | A00.FR.202 | The Central System SHALL validate that Charge Point identity and AuthorizationKey match with username and password in the authorization header. |
Profile 2 - TLS with Basic Authentication
Profile 2In the TLS with Basic Authentication profile, the communication channel is secured using Transport Layer Security (TLS). The Central System authenticates itself using a TLS server certificate. The Charge Points authenticate themselves using HTTP Basic Authentication.
Charge Point Auth
HTTP Basic authentication (encrypted via TLS)
Central System Auth
TLS server certificate
Communication Security
Transport Layer Security (TLS)
Key Benefit
Password sent encrypted, reducing risks
Profile 2 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
A00.FR.301 | The Charge Point SHALL authenticate to the Central System using HTTP Basic authentication. | |
A00.FR.302 | A00.FR.301 | The client SHALL provide a username and password with every connection request. |
A00.FR.303 | A00.FR.302 | The username SHALL be equal to the CP identity in the OCPP-J connection URL. |
A00.FR.304 | A00.FR.302 | The password SHALL be stored in AuthorizationKey. Min 16-bytes, strongly advised randomly generated binary. Hex represented (20 bytes max, 40 hex digits). |
A00.FR.305 | The Central System SHALL act as the TLS server. | |
A00.FR.306 | The Central System SHALL authenticate itself using the Central System certificate as server side certificate. | |
A00.FR.307 | The Charge Point SHALL verify the certification path of the Central System's certificate according to RFC 5280 Section 6 path validation rules. | |
A00.FR.308 | The Charge Point SHALL verify that the commonName matches the Central System's Fully Qualified Domain Name (FQDN). | |
A00.FR.309 | If the CS does not own a valid certificate, or if the certification path is invalid. | The Charge Point SHALL trigger an InvalidCentralSystemCertificate security event. |
A00.FR.310 | A00.FR.309 | The Charge Point SHALL terminate the connection. |
A00.FR.311 | The communication channel SHALL be secured using TLS. | |
A00.FR.312 | The CP and CS SHALL only use TLS v1.2 or above. | |
A00.FR.313 | Both endpoints SHALL check the version of TLS used. | |
A00.FR.317 | The Central System SHALL support at least: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384 | |
A00.FR.318 | The Charge Point SHALL support at least the ECDHE_ECDSA cipher suites (128 AND 256) OR the RSA cipher suites (128 AND 256). TLS_ECDHE is preferred as TLS_RSA does not support forward secrecy. | |
A00.FR.319 | The CP and CS SHALL NOT use cipher suites with cryptographic primitives marked as unsuitable for legacy use. | |
A00.FR.320 | The TLS Server and Client SHALL NOT use TLS compression methods to avoid compression side-channel attacks. | |
A00.FR.324 | A00.FR.302 | The Central System SHALL validate that CP identity and AuthorizationKey match with username and password in the authorization header. |
Profile 3 - TLS with Client Side Certificates
Profile 3In the TLS with Client Side Certificates profile, the communication channel is secured using TLS. Both the Charge Point and Central System authenticate themselves using certificates.
Charge Point Auth
TLS client certificate
Central System Auth
TLS server certificate
Communication Security
Transport Layer Security (TLS)
Key Benefit
Mutual TLS authentication, highest security
Profile 3 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
A00.FR.401 | The Charge Point SHALL authenticate itself using the Charge Point certificate. | |
A00.FR.402 | The Charge Point certificate SHALL be used as a TLS client side certificate. | |
A00.FR.403 | The Central System SHALL verify the certification path of the CP certificate per RFC 5280 Section 6. | |
A00.FR.404 | The Central System SHALL verify that the certificate is owned by the CPO by checking that the O (organizationName) RDN contains the CPO name. | |
A00.FR.405 | The Central System SHALL verify the certificate belongs to this CP by checking that the CN (commonName) RDN contains the unique Serial Number of the CP. | |
A00.FR.406 | If the CP certificate is not owned by the CPO (e.g., immediately after installation). | It is RECOMMENDED to update the certificate before continuing communication with the CP. |
A00.FR.409 | The Central System SHALL act as the TLS server. | |
A00.FR.410 | The Central System SHALL authenticate itself using the CS certificate as server side certificate. | |
A00.FR.411 | The Charge Point SHALL verify the certification path of the CS certificate per RFC 5280 Section 6. | |
A00.FR.412 | The Charge Point SHALL verify that the commonName matches the CS's FQDN. | |
A00.FR.415 | The communication channel SHALL be secured using TLS. | |
A00.FR.416 | The CP and CS SHALL only use TLS v1.2 or above. | |
A00.FR.421 | The CS SHALL support at least: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384 | |
A00.FR.422 | The CP SHALL support at least the ECDHE_ECDSA suites (128 AND 256) OR the RSA suites (128 AND 256). TLS_ECDHE preferred. | |
A00.FR.427 | A unique Charge Point certificate SHALL be used for each Charge Point. |
3. Keys & Certificates
Section 2.6OCPP uses a number of public private key pairs for its security. To manage the keys on the Charge Point, messages have been added to OCPP. Updating keys on the Central System or at the manufacturer is out of scope for OCPP. If TLS with Client Side certificates is used, the Charge Point requires a "Charge Point certificate" for authentication against the Central System.
Keys Used in OCPP
| Certificate | Private Key Stored At | Description |
|---|---|---|
Central System Certificate | Central System | Key used to authenticate the Central System. |
Central System Root Certificate | Central System | Certificate used to authenticate the Central System. |
Charge Point Certificate | Charge Point | Key used to authenticate the Charge Point. |
Firmware Signing Certificate | Manufacturer | Key used to verify the firmware signature. |
Manufacturer Root Certificate | Manufacturer | Root certificate for verification of the Manufacturer certificate. |
Certificate Properties
Requirements for certificate properties used in the OCPP security specification.
| ID | Precondition | Requirement Definition |
|---|---|---|
A00.FR.501 | All certificates SHALL use a private key that provides security equivalent to a symmetric key of at least 112 bits (NIST recommended key size for 2011-2030). | |
A00.FR.502 | A00.FR.501 AND RSA or DSA | This translates into a key that SHALL be at least 2048 bits long. |
A00.FR.503 | A00.FR.501 AND elliptic curve cryptography | This translates into a key that SHALL be at least 224 bits long. |
A00.FR.504 | For all cryptographic operations, only the algorithms recommended by BSI which are suitable for use in future systems SHALL be used. This includes the signing of certificates in the certificate hierarchy. | |
A00.FR.505 | For signing by the certificate authority RSA-PSS, or ECDSA SHOULD be used. | |
A00.FR.506 | For computing hash values the SHA256 algorithm SHOULD be used. | |
A00.FR.507 | The certificates SHALL be stored and transmitted in the X.509 format encoded in Privacy-Enhanced Mail (PEM) format. | |
A00.FR.508 | All certificates SHALL include a serial number. | |
A00.FR.509 | The subject field SHALL contain the organization name of the certificate owner in the O (organizationName) RDN. | |
A00.FR.510 | For the Central System certificate, the subject field SHALL match the FQDN of the server in the CN (commonName) RDN. | |
A00.FR.511 | For the Charge Point certificate, the subject field SHALL contain a CN (commonName) RDN which consists of the unique serial number of the Charge Point. This serial number SHALL NOT be in the format of a URL or an IP address so that Charge Point certificates can be differentiated from Central System certificates. | |
A00.FR.512 | For all certificates the X.509 Key Usage extension SHOULD be used to restrict the usage of the certificate to the operations for which it will be used. |
Certificate Hierarchy
This White Paper adds support for the use of two separate certificate hierarchies:
- 1 The Charge Point Operator hierarchy which contains the Central System, and Charge Point certificates.
- 2 The Manufacturer hierarchy which contains the Firmware Signing certificate.
The Central System can update the CPO root certificates stored on the Charge Point using the InstallCertificate.req message.
| ID | Precondition | Requirement Definition |
|---|---|---|
A00.FR.601 | The Charge Point Operator MAY act as a certificate authority for the Charge Point Operator hierarchy. | |
A00.FR.602 | The private keys belonging to the CPO root certificates MUST be well protected. | |
A00.FR.603 | As the Manufacturer is usually a separate organization from the Charge Point Operator, a trusted third party SHOULD be used as a certificate authority. This is essential to have non-repudiation of firmware images. |
Note: It is not recommended to have preinstalled well-known root CA certificates as used in operating systems or browsers on a Charge Point (like a CA bundle). Only root and intermediate certificates part of the Charge Point Operator hierarchy should be used for the OCPP connection. Trusting many additional well-known root CA certificates creates security risks.
Certificate Revocation
In some cases a certificate may become invalid prior to the expiration of the validity period. Such cases include changes of the organization name, or the compromise or suspected compromise of the certificate's private key. The revocation does not mean the connection needs to be closed immediately - it can stay open longer than 24 hours.
| Certificate | Revocation Method |
|---|---|
Central System certificate | Fast expiration |
Charge Point certificate | Online verification |
Firmware Signing certificate | Online verification |
| ID | Precondition | Requirement Definition |
|---|---|---|
A00.FR.701 | Fast expiration SHOULD be used to revoke the Central System certificate. (The certificate is only valid for a short period, less than 24 hours. After expiration the server requests a new certificate from the CA.) | |
A00.FR.702 | The Central System SHOULD use online certificate verification to verify the validity of the Charge Point certificates. | |
A00.FR.703 | It is RECOMMENDED that a separate certificate authority server is used to manage the certificates. | |
A00.FR.704 | The Central System SHALL verify the validity of the certificate with the certificate authority server. | |
A00.FR.706 | Prior to providing the certificate for firmware validation to the Charge Point, the Central System SHOULD validate both the certificate and the signed firmware update. |
Installation & Manufacturing
Unique credentials should be used to authenticate each Charge Point to the Central System, whether they are the password used for HTTP Basic Authentication or the Charge Point certificate. These unique credentials have to be put on the Charge Point during manufacturing or installation.
| ID | Precondition | Requirement Definition |
|---|---|---|
A00.FR.801 | It is RECOMMENDED that the manufacturer initializes the Charge Point with unique credentials during manufacturing. | |
A00.FR.802 | A00.FR.801 | The credentials SHOULD be generated using a cryptographic random number generator and installed in a secure environment. |
A00.FR.803 | A00.FR.801 | The information needed by the CPO to validate the Charge Point credentials SHOULD be sent over a secure channel to the Central System. The Certificate Private key is not needed by the CPO and SHOULD NOT be provided to the CPO. |
A00.FR.804 | If Charge Point certificates are used. | The manufacturer MAY sign these using their own certificate. |
A00.FR.805 | A00.FR.804 | It is RECOMMENDED that the CPO immediately updates the credentials after installation using use cases A01 or A02. |
A00.FR.806 | Before the 'factory credentials' have been updated | The Central System MAY restrict the functionality that the Charge Point can use. The Central System can use the BootNotification state: Pending for this. |
A00.FR.807 | A00.FR.804 AND Charge Point manufacturer certificate has expired | The Central System MAY accept a connection by Charge Point in a Pending state after the BootNotification and immediately execute use case A02 to install a new valid CPO certificate. |
4. Credential Management
Use CasesThis section covers the use cases for managing credentials on Charge Points, including updating HTTP Basic Authentication passwords and managing client side certificates.
A01 - Update Charge Point Password
A01 (OCPP 2.0.1)Objective
Defines how to use the AuthorizationKey to update the password used to authenticate Charge Points in the Basic and TLS with Basic Authentication security profiles.
Actors
Charge Point, Central System
Prerequisite
Security Profile 1 (Basic) or Profile 2 (TLS with Basic Authentication) in use.
Postcondition (Success)
The Charge Point has reconnected to the Central System with the new password.
Scenario Description
- 1 The Central System sends a
ChangeConfiguration.req(key = AuthorizationKey)to the Charge Point with the AuthorizationKey Configuration Key. - 2 The Charge Point responds with
ChangeConfiguration.confand the status Accepted. - 3 The Charge Point disconnects its current connection. (Storing any queued messages)
- 4 The Charge Point connects to the Central System with the new password.
A01 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
A01.FR.01 | The Charge Point SHALL store the password in the configuration key AuthorizationKey. | |
A01.FR.02 | To set a Charge Point’s authorization key via OCPP, the Central System SHALL send the Charge Point a ChangeConfiguration.req message with the AuthorizationKey Configuration Key. | |
A01.FR.03 | A01.FR.02 AND CP responds with ChangeConfiguration.conf status Accepted. | The Central System SHALL assume that the authorization key change was successful, and no longer accept the old credentials. |
A01.FR.04 | A01.FR.02 AND CP responds with status Rejected or NotSupported. | The Central System SHALL assume that the CP has NOT changed the password. The Central System SHALL keep accepting the old credentials. |
A01.FR.05 | A01.FR.04 | While the Central System SHALL still accept a connection from the CP, it MAY restrict the functionality. The Central System can use BootNotification state: Pending, and retry updating credentials. |
A01.FR.06 | Different passwords SHOULD be used for different Charge Points. | |
A01.FR.07 | Passwords SHOULD be generated randomly to ensure sufficient entropy. | |
A01.FR.08 | The Central System SHOULD only store salted password hashes, not the passwords themselves. | |
A01.FR.09 | The Central System SHOULD NOT put the passwords in clear-text in log files or debug information to prevent mass compromise. | |
A01.FR.10 | On the Charge Point the password needs to be stored in clear-text. Extra care SHOULD be taken to store it securely. Definitions of secure storage mechanisms are out of scope. | |
A01.FR.11 | A01.FR.02 | The Charge Point SHALL log the change of AuthorizationKey in the Security log. |
A01.FR.12 | A01.FR.11 | The Charge Point SHALL NOT disclose the content of the AuthorizationKey in its logging. This is to prevent exposure of key material to persons who may have access to a diagnostics file. |
A02 - Update Charge Point Certificate by request of Central System
A02 (OCPP 2.0.1)Objective
To facilitate the management of the Charge Point client side certificate, a certificate update procedure is provided.
Actors
Charge Point, Central System, Certificate Authority Server
Prerequisite
The configuration variable CpoName MUST be set.
Postcondition (Success)
New Client Side certificate installed in the Charge Point.
Scenario Description
- 1 The Central System requests the Charge Point to update its certificate using
ExtendedTriggerMessage.req (SignChargePointCertificate). - 2 The Charge Point responds with
ExtendedTriggerMessage.conf. - 3 The Charge Point generates a new public / private key pair.
- 4 The Charge Point sends a
SignCertificate.reqto the Central System. - 5 The Central System responds with
SignCertificate.conf, with status Accepted. - 6 The Central System forwards the CSR to the Certificate Authority Server.
- 7 Certificate Authority Server signs the certificate.
- 8 The Certificate Authority Server returns the Signed Certificate to the Central System.
- 9 The Central System sends
CertificateSigned.reqto the Charge Point. - 10 The Charge Point verifies the Signed Certificate.
- 11 The Charge Point responds with
CertificateSigned.confwith status Accepted or Rejected.
A02 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
A02.FR.01 | A key update SHOULD be performed after installation of the CP, to change the key from the one initially provisioned by the manufacturer (possibly a default key). | |
A02.FR.02 | After sending an ExtendedTriggerMessage.conf. | The Charge Point SHALL generate a new public / private key pair using one of the key generation functions described in Section 4.2.1.3 of RFC 4210. |
A02.FR.03 | A02.FR.02 | The Charge Point SHALL send the public key in form of a Certificate Signing Request (CSR) as described in RFC 2986, PEM encoded, using the SignCertificate.req message. |
A02.FR.04 | The Central System SHOULD NOT sign the certificate itself, but instead forward the CSR to a dedicated certificate authority server. The dedicated authority server MAY be operated by the CPO. | |
A02.FR.05 | The private key generated by the Charge Point SHALL NOT leave the Charge Point at any time, and SHALL NOT be readable via OCPP or any other remote connection. | |
A02.FR.06 | The Charge Point SHALL verify the validity of the signed certificate in the CertificateSigned.req message, checking that the current date is within the certificate’s validity period, the properties in Certificate Properties, and that it is part of the Charge Point Operator certificate hierarchy. | |
A02.FR.07 | If the certificate is not valid. | The Charge Point SHALL respond with CertificateSigned.conf status Rejected, discard the certificate and trigger an InvalidChargePointCertificate security event. |
A02.FR.08 | If the certificate is valid. | The Charge Point SHALL respond with status Accepted AND switch to the new certificate by reconnecting the websocket and TLS connection. |
A02.FR.10 | (A02.FR.08 OR A02.FR.28) AND The CP successfully connected to the CS using either of the certificates. | The Charge Point SHALL discard the client certificate that is NOT in use. (To prevent having multiple client certificates installed.) |
A02.FR.11 | Upon receipt of a SignCertificate.req AND It is able to process the request. | The Central System SHALL set status to Accepted in the SignCertificate.conf. |
A02.FR.12 | Upon receipt of a SignCertificate.req AND It is NOT able to process the request. | The Central System SHALL set status to Rejected in the SignCertificate.conf. |
A02.FR.13 | A02.FR.03 | The Charge Point SHALL put the value of the CpoName configuration key in the organizationName (O) RDN in the CSR subject field. |
A02.FR.28 | A02.FR.08 AND the CP cannot successfully connect using the new certificate. | The Charge Point SHOULD reconnect to the Central System alternating between using the old and new client certificate. The CP SHOULD NOT stop trying to reconnect to prevent becoming a stranded asset. |
A02.FR.29 | A02.FR.10 AND The CP discarded the new client certificate. | The Charge Point SHOULD send a SecurityEventNotification.req DiscardedRenewedClientCertificate to the Central System. |
A03 - Update Charge Point Certificate initiated by the Charge Point
A03 (OCPP 2.0.1)Objective
To facilitate the management of the Charge Point client side certificate, a certificate update procedure initiated by the Charge Point is provided.
Actors
Charge Point, Central System, Certificate Authority Server
Prerequisite
CpoName configuration variable MUST be set AND Charge Point is connected using Security Profile
3.
Postcondition (Success)
New Client Side certificate installed in the Charge Point.
Scenario Description
- 1 The Charge Point detects that its certificate is due to expire.
- 2 The Charge Point generates a new public / private key pair.
- 3 The Charge Point sends a
SignCertificate.reqto the Central System. - 4 The Central System responds with a
SignCertificate.conf, with status Accepted. - 5 The Central System forwards the CSR to the Certificate Authority Server.
- 6 Certificate Authority Server signs the certificate.
- 7 The Certificate Authority Server returns the Signed Certificate to the Central System.
- 8 The Central System sends a
CertificateSigned.reqto the Charge Point. - 9 The Charge Point verifies the Signed Certificate.
- 10 The Charge Point responds with a
CertificateSigned.confwith the status Accepted or Rejected.
A03 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
A03.FR.01 | A key update MAY be performed after installation to change the key from the one initially provisioned by the manufacturer. | |
A03.FR.02 | When the CP detects its current certificate will expire in one month. | The Charge Point SHALL generate a new public / private key pair using the key generation functions described in RFC 4210. |
A03.FR.03 | A03.FR.02 | The Charge Point SHALL send the public key in form of a CSR as described in RFC 2986, PEM encoded, using the SignCertificate.req message. |
A03.FR.05 | The private key SHALL NOT leave the Charge Point at any time and SHALL NOT be readable via OCPP or any other remote connection. | |
A03.FR.06 | The Charge Point SHALL verify the validity of the signed certificate in the CertificateSigned.req message, checking the current date, validity period, Certificate Properties, and certificate hierarchy. | |
A03.FR.07 | If the certificate is not valid. | The Charge Point SHALL respond with CertificateSigned.conf status Rejected, discard the certificate and trigger an InvalidChargePointCertificate security event. |
A03.FR.08 | If the certificate is valid. | The Charge Point SHALL respond with status Accepted AND switch to the new certificate by reconnecting the websocket and TLS connection. |
A03.FR.13 | A03.FR.03 | The Charge Point SHALL put the value of CpoName in the organizationName RDN in the CSR subject field. |
A03.FR.24 | A03.FR.08 AND the CP cannot connect using the new certificate. | The CP SHOULD reconnect alternating between old and new client certificate. SHALL NOT stop trying to reconnect. |
A03.FR.25 | A03.FR.10 AND The CP discarded the new client certificate. | The CP SHOULD send a SecurityEventNotification.req DiscardedRenewedClientCertificate to the Central System. |
5. Profile & Certificate Management
Use CasesThis section covers use cases for upgrading security profiles and managing CA certificates on Charge Points, including retrieving, installing, and deleting certificates.
A05 - Upgrade Charge Point Security Profile
A05 (OCPP 2.0.1)Use Case Summary
Objective
Upgrade the security profile used by a Charge Point to a higher profile.
Actors
Charge Point, Central System, CPO
Prerequisite
Configuration Key SecurityProfile has an allowed value AND prerequisites for new security profile are met before sending the upgrade command.
Postcondition
Success: The Charge Point is using the new security profile. Failure: The Charge Point is NOT using the new security profile.
Scenario
- 1 CPO command the Central System to upgrade a Charge Point to a higher Security Profile.
- 2 The Central System sends a
ChangeConfiguration.reqfor configuration key:SecurityProfilewith a new (higher) value to the Charge Point. - 3 The Charge Point checks all the prerequisites for the new Security Profile.
- 4 The Charge Point responds with
ChangeConfiguration.conf. - 5 The Charge Point disconnects its current connection to the Central System.
- 6 The Charge Point connects to the Central System using the new Security Profile.
Note: For security reasons it is by default not allowed to revert to a lower
Security Profile using OCPP. Only when the configuration key AllowSecurityProfileDowngrade is set to true, it is allowed
to downgrade from profile 3 to profile 2. Even then, it is not allowed to revert from
profile 2 or profile 3 to profile 1 using OCPP.
A05 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
A05.FR.01 | CP receives ChangeConfiguration.req for SecurityProfile with value >= 1 and <= current value AND AllowSecurityProfileDowngrade is not implemented or set to false. | The CP SHALL respond with ChangeConfiguration.conf(Rejected) and not change the value. |
A05.FR.02 | CP receives ChangeConfiguration.req for SecurityProfile with higher value AND new value is 1 or 2 AND AuthorizationKey does not contain a valid value. | The CP SHALL respond with Rejected. |
A05.FR.03 | ...new value is 2 or 3 AND No valid CentralSystemRootCertificate installed. | The CP SHALL respond with Rejected. |
A05.FR.04 | ...new value is 3 AND No valid ChargePointCertificate installed. | The CP SHALL respond with Rejected. |
A05.FR.05 | ...value higher than current AND all prerequisites are met. | The CP SHALL respond with ChangeConfiguration.conf(Accepted). |
A05.FR.06 | A05.FR.05 OR A05.FR.10 | The CP SHALL disconnect from the Central System. |
A05.FR.07 | A05.FR.06 | The CP SHALL reconnect to the Central System with the new Security Profile. |
A05.FR.08 | A05.FR.07 AND CP was unable to connect | The CP SHOULD fallback to its previous security profile setting. |
A05.FR.09 | A05.FR.07 AND CP was able to connect | The Central System SHALL NOT allow the CP to connect with a lower security profile anymore. |
A05.FR.10 | AllowSecurityProfileDowngrade is true AND currently active SecurityProfile is 3 AND CP receives ChangeConfiguration.req for SecurityProfile with value 2. | The CP SHALL respond with ChangeConfiguration.conf(Accepted). (NOTE: Downgrading from 3 to 2 only) |
M03 - Retrieve list of available certificates from a Charge Point
M03 (OCPP 2.0.1)Use Case Summary
Objective
To enable the Central System to retrieve a list of available certificates from a Charge Point.
Actors
Charge Point, Central System
Prerequisite
n/a
Postcondition
The Central System received a list of installed certificates.
Scenario
- 1 The Central System requests the Charge Point to send a list of installed certificates
by sending a
GetInstalledCertificateIds.req - 2 The Charge Point responds with a
GetInstalledCertificateIds.conf
M03 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
M03.FR.01 | After receiving a GetInstalledCertificateIds.req | The Charge Point SHALL respond with a GetInstalledCertificateIds.conf. |
M03.FR.02 | M03.FR.01 AND No certificate matching certificateType was found | The CP SHALL indicate this by setting status to NotFound in the GetInstalledCertificateIds.conf. |
M03.FR.03 | M03.FR.01 AND A certificate matching certificateType was found | The CP SHALL indicate this by setting status to Accepted in the GetInstalledCertificateIds.conf. |
M03.FR.04 | M03.FR.03 | The CP SHALL include the hash data for each matching installed certificate in the GetInstalledCertificateIds.conf. |
M04 - Delete a specific certificate from a Charge Point
M04 (OCPP 2.0.1)Use Case Summary
Objective
To enable the Central System to request the Charge Point to delete an installed certificate.
Actors
Charge Point, Central System
Prerequisite
n/a
Postcondition
The requested certificate was deleted from the Charge Point.
Scenario
- 1 The Central System requests the Charge Point to delete an installed certificate by
sending a
DeleteCertificate.req. - 2 The Charge Point responds with a
DeleteCertificate.conf.
M04 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
M04.FR.01 | After receiving a DeleteCertificate.req | The Charge Point SHALL respond with a DeleteCertificate.conf. |
M04.FR.02 | M04.FR.01 AND The requested certificate was found | The CP SHALL attempt to delete it, and indicate success by setting status to Success. |
M04.FR.03 | M04.FR.01 AND (The deletion fails OR the CP rejects the request to delete the specified
certificate.) | The CP SHALL indicate failure by setting status to Failed.
(A CP may reject to prevent deletion of the last certificate of its type.) |
M04.FR.04 | M04.FR.01 AND The requested certificate was not found | The CP SHALL indicate failure by setting status to NotFound. |
M04.FR.05 | Deletion of the Charge Point Certificate SHALL NOT be possible via DeleteCertificate.req. | |
M04.FR.06 | M04.FR.01 AND certificateHashData refers to the CentralSystemRootCertificate | CP SHALL respond with status = Failed.
(Deletion of CentralSystemRootCertificate is not allowed via DeleteCertificate.req.) |
M04.FR.07 | When deleting a certificate | The Central System SHALL use the same hashAlgorithm as the CP uses to report the certificateHashData in GetInstalledCertificateIds.conf. |
M04.FR.08 | M04.FR.02 AND Certificate to delete is a sub-CA or root certificate | Charge Point MAY also delete all child certificates. |
Note: Be cautious when deleting CentralSystemRootCertificates - if all are deleted, the CP cannot validate Central System Certificates and will be unable
to connect. Similarly, deleting all ManufacturerRootCertificates will prevent signed firmware from being installed.
M05 - Install CA certificate in a Charge Point
M05 (OCPP 2.0.1)Use Case Summary
Objective
To facilitate the management of the Charge Point's installed certificates, a method to install a new CA certificate.
Actors
Charge Point, Central System
Prerequisite
n/a
Postcondition
The new certificate was installed in the Charge Point trust store.
Scenario
- 1 The Central System requests the Charge Point to install a new certificate by sending
an
InstallCertificate.req. - 2 The Charge Point responds with an
InstallCertificate.conf.
M05 - Requirements
| ID | Precondition | Requirement Definition |
|---|---|---|
M05.FR.01 | After receiving an InstallCertificate.req | The CP SHALL attempt to install the certificate and respond with an InstallCertificate.conf. |
M05.FR.02 | M05.FR.01 AND The installation was successful | The CP SHALL indicate success by setting status to Accepted. |
M05.FR.03 | M05.FR.01 AND Current amount of installed certificates >= CertificateStoreMaxLength | The CP SHALL indicate failure by setting status to Rejected. |
M05.FR.04 | M05.FR.01 AND The installation failed | The CP SHALL indicate failure by setting status to Failed. |
M05.FR.06 | M05.FR.01 AND The certificate is invalid and/or incorrect. | The CP SHALL indicate rejection by setting status to Rejected. |
M05.FR.08 | When AdditionalRootCertificateCheck is true | Only one certificate (plus a temporarily fallback certificate) of certificateType CentralSystemRootCertificate is allowed to be installed at a time. |
M05.FR.09 | When AdditionalRootCertificateCheck is true AND installing a new CentralSystemRootCertificate | The new CS Root certificate SHALL replace the old one AND the new Root Certificate MUST be signed by the old Root Certificate it is replacing. |
M05.FR.10 | M05.FR.09 AND the new CS Root certificate is NOT signed by the old CS Root certificate | The CP SHALL NOT install the new certificate and respond with status Rejected. |
M05.FR.11 | M05.FR.09 AND the new CS Root certificate is signed by the old one | The CP SHALL install the new certificate AND temporarily keep the old one as a
fallback certificate AND respond with status Accepted. |
M05.FR.12 | M05.FR.11 AND The CP successfully connected to the CS using the new CS Root certificate | The CP SHALL remove the old CS Root (fallback) certificate. |
Note: CertificateSigned.req (use cases A02, A03) and InstallCertificate.req (use case M05) are both used to send certificates but serve different purposes. CertificateSigned.req returns the Charge Point's own public certificate signed by a CA. InstallCertificate.req is used to install Root certificates. It is allowed to have multiple certificates of the
same type installed.
6. Security Events & Logging
Section 3Security event logging allows the Charge Point to inform the Central System of critical security events. This enables monitoring and auditing of the security state of the charging infrastructure.
A04 - Security Event Notification
A04 (OCPP 2.0.1)Objective
To inform the Central System of critical security events.
Actors
Central System, Charge Point
Prerequisite
n/a
Postcondition
The Charge Point successfully informed the Central System of critical security events by
sending a SecurityEventNotification.req.
Scenario
- 1 A critical security event happens.
- 2 The Charge Point sends a
SecurityEventNotification.reqto the Central System. - 3 The Central System responds with
SecurityEventNotification.confto the Charge Point.
Important: Critical security events that will need to be queued and sent to the Central System once a successful connection has been made, as described in the relevant use cases. A security event only needs to be sent once for repeated failed connection attempts, to avoid overflow to the offline queue.
Security Event Types
Event TypesThe following security events are defined in OCPP 1.6 security. Events marked as "Critical"
SHOULD be reported to the Central System via SecurityEventNotification.req. All events SHOULD be logged in the Charge Point's security log.
| Event Type | Critical | Description |
|---|---|---|
FirmwareUpdated | Yes | The firmware on the Charge Point has been updated successfully. |
FailedToAuthenticateAtCentralSystem | Yes | The Charge Point failed to authenticate to the Central System. (e.g., TLS handshake failed, invalid server certificate) |
CentralSystemFailedToAuthenticate | Yes | The Central System failed to authenticate the Charge Point. (e.g., invalid client certificate, wrong password) |
SettingSystemTime | Yes | The system time on the Charge Point has been changed. |
StartupOfTheDevice | Yes | The Charge Point has started up / been rebooted. |
ResetOrReboot | Yes | The Charge Point was reset or rebooted. |
SecurityLogWasCleared | Yes | The security log on the Charge Point was cleared. |
ReconfigurationOfSecurityParameters | Yes | Security parameters (e.g., keys, certificates, security profile) have been changed. |
MemoryExhaustion | No | The Charge Point is running low on available memory. |
InvalidMessages | No | The Charge Point received invalid OCPP messages. |
AttemptedReplayAttacks | No | The Charge Point detected a potential replay attack. |
TamperDetectionActivated | Yes | The Charge Point detected tampering with the physical hardware. |
InvalidFirmwareSignature | Yes | The Charge Point detected an invalid firmware signature when attempting a firmware update. |
InvalidFirmwareSigningCertificate | Yes | The Charge Point detected an invalid firmware signing certificate when attempting a firmware update. |
InvalidCentralSystemCertificate | Yes | The Charge Point detected an invalid Central System certificate during TLS handshake. |
InvalidChargePointCertificate | Yes | The Central System detected an invalid Charge Point certificate during TLS handshake. |
InvalidTLSVersion | Yes | An invalid TLS version was detected during connection setup. |
InvalidTLSCipherSuite | Yes | An invalid TLS cipher suite was detected during connection setup. |
DiscardedRenewedClientCertificate | Yes | The Charge Point discarded a renewed client certificate that it was unable to use. |
Note: The Central System SHOULD implement monitoring for critical security
events and alert operators when they occur. This is especially important for events
indicating potential security compromises such as InvalidCentralSystemCertificate, InvalidChargePointCertificate, and TamperDetectionActivated.