Migration Guide 2.0.1 → 2.1 Section A

Security Section — Migration Guide

Use cases A01–A05 (Security Flows) and Connection-Level Security. Perspective: CSMS Developer.

11 Sections
5 Use Cases
A01 – A05

Created by tzi.app — your guide to migrating from OCPP 2.0.1 to OCPP 2.1.

1. Summary of Changes

High-Level Overview

Area Change Type Description
A01 (Password Update) Deprecated Deprecated in favor of B09 (SetNetworkProfile). Retained for backwards compatibility.
A02 (Certificate Update - CSMS) Extended New fields: hashRootCertificate, requestId. New cert type V2G20Certificate. New trigger SignV2G20Certificate. Retry behavior documented.
A03 (Certificate Update - CS) Extended Same new fields as A02. New security event DiscardedRenewedClientCertificate for failed cert swaps.
A04 (Security Event Notification) Changed All security events reclassified as Critical. Event name renamed. New event. Guaranteed delivery semantics added.
A05 (Security Profile Upgrade) Redesigned Flow completely changed: now uses SetVariablesRequest(NetworkConfigurationPriority) + ResetRequest + BootNotificationRequest.
Certificate Management Extended New messages: GetInstalledCertificateIdsRequest, DeleteCertificateRequest. New cert type: OEMRootCertificate. Certificate maxLength: 5500 → 10000.
Hash Algorithms Extended HashAlgorithmEnumType adds SHA384 and SHA512.
Schema sizes Increased attributeValue max: 1000 → 2500. additionalInfo max: 512 → 1024.
Security Profiles New A00.FR.320 (no unsuitable cipher suites), A00.FR.427 (unique CS cert per station), A00.FR.501 (112-bit symmetric equiv.), A00.FR.511 (CN = serial), A00.FR.707 (validate firmware signing cert + firmware).
All messages Extended customData (vendor extensions) available in all 2.1 messages.

2. Connection-Level Security (Profiles) Changes

The three security profiles (1, 2, 3) remain the same in structure. The following requirements are new or clarified in 2.1.

New Functional Requirements

Requirement Description
A00.FR.320 Do NOT use cipher suites with cryptographic primitives marked as unsuitable for legacy use. (2.0.1 only prohibited deprecated suites.)
A00.FR.427 A unique Charging Station certificate SHALL be used for each Charging Station. (Was implicit in 2.0.1, now explicit.)
A00.FR.501 Private keys must provide security equivalent to >= 112-bit symmetric key. (New minimum security threshold.)
A00.FR.511 CS certificate subject CN must contain the unique serial number of the CS — explicitly stated as NOT a URL or IP address.
A00.FR.707 Before providing a firmware signing certificate to a CS, the CSMS must validate both the certificate and the signed firmware. (2.0.1 only mentioned certificate validation.)

Profile 2 Clarification

In 2.1, the specification explicitly states: The CSMS needs 2 different certificates (one RSA, one ECDSA) to support both cipher suite families. This was implied in 2.0.1 but not explicitly stated.

3. Data Type & Schema Changes

Field Size Increases

Field Message(s) 2.0.1 2.1
attributeValue SetVariablesRequest maxLength: 1000 maxLength: 2500
additionalInfo StatusInfoType (all responses) maxLength: 512 maxLength: 1024
certificate InstallCertificateRequest maxLength: 5500 maxLength: 10000

New Field: customData

All OCPP 2.1 messages now include an optional customData field for vendor-specific extensions. The CSMS should accept and pass through customData without rejecting messages that contain it.

JSON — customData example
{
  "customData": {
    "vendorId": "com.example.vendor"
  }
}

4. A01 — Update Charging Station Password

Deprecated

Deprecation Notice

A01 is deprecated in OCPP 2.1. Use case B09 (Setting a new NetworkConnectionProfile) is the preferred approach for updating Basic Auth credentials.

The use case is retained for backwards compatibility only. CSMS implementations should:

  1. Continue supporting A01 for Charging Stations that have not been updated.
  2. Prefer B09 for new deployments or updated stations.

Schema Changes

The SetVariablesRequest/SetVariablesResponse schema changes apply:

  • attributeValue maxLength: 1000 → 2500
  • additionalInfo maxLength: 512 → 1024

5. A02 — Update Charging Station Certificate by Request of CSMS

Extended

New Fields in SignCertificateRequest

Two new optional fields added in 2.1:

Field Type Description
hashRootCertificate CertificateHashDataType Hash of the Root CA to identify which Certificate Authority the CSMS should forward the CSR to.
requestId integer Correlation ID. When present, the CSMS SHALL echo this value back in the CertificateSignedRequest (A02.FR.25).
2.0.1 SignCertificateRequest
{
  "csr": "<PEM-encoded CSR>",
  "certificateType": "ChargingStationCertificate"
}
2.1 SignCertificateRequest
{
  "csr": "<PEM-encoded CSR>",
  "certificateType": "ChargingStationCertificate",
  "hashRootCertificate": {
    "hashAlgorithm": "SHA256",
    "issuerNameHash": "...",
    "issuerKeyHash": "...",
    "serialNumber": "..."
  },
  "requestId": 12345
}

New Field in CertificateSignedRequest

Field Type Description
requestId integer Must match the requestId from the corresponding SignCertificateRequest (A02.FR.25).
2.0.1 CertificateSignedRequest
{
  "certificateChain": "<PEM certificate chain>",
  "certificateType": "ChargingStationCertificate"
}
2.1 CertificateSignedRequest
{
  "certificateChain": "<PEM certificate chain>",
  "certificateType": "ChargingStationCertificate",
  "requestId": 12345
}

New Certificate Type: V2G20Certificate

Value Version Description
ChargingStationCertificate 2.0.1 + 2.1 CS-to-CSMS connection certificate
V2GCertificate 2.0.1 + 2.1 ISO 15118-2 certificate
V2G20Certificate 2.1 only ISO 15118-20 certificate

New Trigger Message Value

Value Version Description
SignV2G20Certificate 2.1 only Trigger CS to generate CSR for ISO 15118-20 V2G certificate

Explicit CSMS Signing Restriction

[A02.FR.04] now explicitly states: The CSMS SHOULD NOT sign the certificate itself. Forward the CSR to a dedicated CA server. This was not explicitly stated in 2.0.1.

Retry Behavior (New in 2.1)

2.1 formally documents the CS retry behavior that the CSMS must be aware of:

Requirement Description
A02.FR.17 If the CSMS accepted a SignCertificateRequest but hasn't sent a CertificateSignedRequest within CertSigningWaitMinimum seconds, the CS will re-send.
A02.FR.18 The CS doubles the back-off time on each retry (exponential back-off).
A02.FR.19 The CS stops retrying after CertSigningRepeatTimes attempts, until triggered again by the CSMS via TriggerMessageRequest.

CSMS implication: The CSMS may receive duplicate SignCertificateRequest messages for the same CSR if the CA is slow. The CSMS should handle this gracefully (deduplicate or re-forward).

Certificate Validity Time Note

[A02.FR.06 Note] (new in 2.1): When providing a newly signed certificate with a start period equal to the current time, account for a slight time discrepancy between the CS and CSMS. The CS may reject the certificate if its validity period is slightly in the future from the device's perspective.

Changed Requirement IDs

2.0.1 2.1 Description
A02.FR.02 A02.FR.11 CSMS responds Accepted to valid CSR
new A02.FR.12 CSMS responds Rejected when unable to process
A02.FR.05 A02.FR.14 Set certificateType in CertificateSignedRequest matching the SignCertificateRequest
new A02.FR.25 Echo requestId from SignCertificateRequest into CertificateSignedRequest

6. A03 — Update Charging Station Certificate Initiated by CS

Extended

Same New Fields as A02

The SignCertificateRequest and CertificateSignedRequest changes from A02 apply identically to A03:

  • hashRootCertificate (new in SignCertificateRequest)
  • requestId (new in both messages)
  • V2G20Certificate enum value (new)

New: requestId Correlation

[A03.FR.21] If the SignCertificateRequest included a requestId, the CSMS SHALL include the same requestId in the CertificateSignedRequest.

New: Discarded Certificate Event

[A03.FR.25] If the CS discards a new client certificate (e.g., it couldn't reconnect with it), it SHOULD send a SecurityEventNotification with type DiscardedRenewedClientCertificate. The CSMS should monitor for this event and may need to re-trigger A02. This is a new event type not present in 2.0.1.

Changed Requirement IDs

2.0.1 2.1 Description
A03.FR.01 A03.FR.11 CSMS responds Accepted to valid CSR
new A03.FR.12 CSMS responds Rejected when unable to process
A03.FR.02 A03.FR.04 CSMS SHOULD NOT sign the certificate itself
new A03.FR.14 Set certificateType matching the request
new A03.FR.21 Echo requestId
new A03.FR.25 Handle DiscardedRenewedClientCertificate event

7. A04 — Security Event Notification

Changed

All Events Reclassified as Critical

In 2.0.1, security events were split into critical and non-critical. In 2.1, ALL security events are classified as Critical.

Event Type 2.0.1 Criticality 2.1 Criticality
FirmwareUpdated Non-critical Critical
FailedToAuthenticateAtCsms Non-critical Critical
SettingSystemTime Non-critical Critical
StartupOfTheDevice Non-critical Critical
ResetOrReboot Non-critical Critical
SecurityLogWasCleared Non-critical Critical
ReconfigurationOfSecurityParameters Non-critical Critical
MemoryExhaustion Non-critical Critical
InvalidMessages Non-critical Critical
AttemptedReplayAttacks Non-critical Critical
TamperDetectionActivated Critical Critical
InvalidFirmwareSignature Critical Critical
InvalidFirmwareSigningCertificate Critical Critical
InvalidCsmsCertificate Critical Critical
InvalidChargingStationCertificate Critical Critical
InvalidTLSVersion Critical Critical
InvalidTLSCipherSuite Critical Critical

CSMS implication: If the CSMS previously ignored or only logged non-critical events, it must now treat ALL events as requiring operator alerting.

Event Name Change

2.0.1 2.1
CsmsFailedToAuthenticate CentralSystemFailedToAuthenticate

The CSMS should handle both names during a transition period (stations running 2.0.1 and 2.1 may coexist).

New Security Event Type

Event Type Criticality Description
DiscardedRenewedClientCertificate Non-critical CS discarded a new certificate after A02/A03 (could not reconnect with it). CSMS should re-trigger certificate update. This is the only non-critical event in 2.1.

Guaranteed Delivery Semantics (New)

Requirement Description
A04.FR.02 Security event notifications are queued with guaranteed delivery. If the CS is disconnected, it sends them upon reconnection. The CSMS may receive past events.
A04.FR.04 The CS stores all security events (including non-critical) in a local security log.

CSMS implication: Event timestamps may be significantly in the past. The CSMS should handle late-arriving events correctly and not treat them as current incidents.

Response Schema Change

The SecurityEventNotificationResponse now includes an optional customData field. The response remains effectively empty (no required fields beyond the optional customData).

2.0.1 Response
{}
2.1 Response
{
  "customData": {
    "vendorId": "com.example.vendor"
  }
}

8. A05 — Upgrade Charging Station Security Profile

Redesigned

This is the most significantly changed use case in the Security section. The entire flow has been redesigned.

Flow Comparison

2.0.1 Flow

  1. CSMS sends InstallCertificateRequest (install root/client certs) as part of the upgrade flow.
  2. CSMS optionally runs A02 (for Profile 3 upgrade).
  3. CSMS sends SetVariablesRequest(SecurityProfile=<new_profile>) to SecurityCtrlr.
  4. CS disconnects and reconnects on the new profile.

2.1 Flow

  1. Prerequisites: All certificates must already be installed via separate operations.
  2. CSMS sends SetVariablesRequest(NetworkConfigurationPriority=<new_order>) to OCPPCommCtrlr.
  3. CSMS sends ResetRequest(type=OnIdle).
  4. CS reboots and reconnects using the first entry in NetworkConfigurationPriority.
  5. CS sends BootNotificationRequest on the new profile.

Key Differences

Aspect 2.0.1 2.1
Certificate installation Part of the A05 flow (InstallCertificateRequest) Prerequisite — must be done beforehand
Profile selection Set SecurityProfile on SecurityCtrlr Set NetworkConfigurationPriority on OCPPCommCtrlr
Reconnection trigger CS auto-disconnects after accepting new SecurityProfile CSMS explicitly sends ResetRequest; CS reboots
Messages used InstallCertificateRequest, SetVariablesRequest, TriggerMessageRequest SetVariablesRequest, ResetRequest, BootNotificationRequest
Post-upgrade cleanup None specified [A05.FR.06] CS removes all NetworkConnectionProfiles with a lower security profile

New Messages in A05

Message Direction Purpose
ResetRequest / ResetResponse CSMS → CS Trigger CS reboot to apply new profile
BootNotificationRequest / BootNotificationResponse CS → CSMS CS reports back on new profile after reboot

New SetVariablesRequest Target

2.0.1 SetVariablesRequest
{
  "setVariableData": [{
    "component": {
      "name": "SecurityCtrlr"
    },
    "variable": {
      "name": "SecurityProfile"
    },
    "attributeValue": "3"
  }]
}
2.1 SetVariablesRequest
{
  "setVariableData": [{
    "component": {
      "name": "OCPPCommCtrlr"
    },
    "variable": {
      "name": "NetworkConfigurationPriority"
    },
    "attributeValue": "2,1"
  }]
}

The attributeValue is a comma-separated list of configuration slot numbers. The slot containing the NetworkConnectionProfile with the higher security profile should be listed first.

New ResetRequest in A05

JSON — ResetRequest
{
  "type": "OnIdle"
}

The ResetEnumType includes a new value in 2.1:

Value Version Description
Immediate 2.0.1 + 2.1 Reset immediately
OnIdle 2.0.1 + 2.1 Reset when no transactions are active
ImmediateAndResume 2.1 only Reset immediately, resume transactions after reboot

Updated Downgrade Rules

Current Target AllowSecurityProfileDowngrade 2.0.1 2.1
3 2 true Allowed Allowed (A05.FR.08)
3 2 false Rejected Rejected (A05.FR.10)
3 1 Any Rejected (A00.FR.005) Rejected (A05.FR.09)
2 1 Any Rejected (A00.FR.005) Rejected (A05.FR.09)

The rules are functionally the same, but 2.1 formalizes them with dedicated FRs (A05.FR.08–A05.FR.10) instead of relying on a single A00.FR.005.

New Post-Upgrade Requirements

Requirement Description
A05.FR.05 After reboot, the CS connects using the first entry in NetworkConfigurationPriority.
A05.FR.06 The CS updates its SecurityProfile config variable and removes all NetworkConnectionProfiles with a lower security profile.
A05.FR.07 The CSMS SHALL NOT allow the CS to connect with a lower security profile anymore.

Validation the CS Performs (CSMS Should Be Aware)

Requirement Description
A05.FR.02 If upgrading to Profile 2/3 and no valid CSMSRootCertificate is installed: CS responds Rejected.
A05.FR.03 If upgrading to Profile 3 and no valid ChargingStationCertificate is installed: CS responds Rejected.
A05.FR.04 If all prerequisites are met: CS responds Accepted.

9. Certificate Management Additions

Extended

New Messages

OCPP 2.1 adds formal certificate management messages that were not part of the 2.0.1 security flows:

Message Direction Purpose
GetInstalledCertificateIdsRequest / Response CSMS → CS Query which certificates are installed on a CS
DeleteCertificateRequest / Response CSMS → CS Remove a certificate from a CS

InstallCertificateRequest Changes

Field 2.0.1 2.1
certificate maxLength 5500 10000
certificateType enum values V2GRootCertificate, MORootCertificate, CSMSRootCertificate, ManufacturerRootCertificate Same + OEMRootCertificate

New Certificate Type: OEMRootCertificate

Added to multiple enumerations in 2.1:

Enum 2.0.1 Values Added in 2.1
InstallCertificateUseEnumType V2G, MO, CSMS, Manufacturer OEMRootCertificate
GetCertificateIdUseEnumType V2G, MO, CSMS, V2GChain, Manufacturer OEMRootCertificate

CertificateHashDataType — Hash Algorithm Extension

Algorithm 2.0.1 2.1
SHA256 Yes Yes
SHA384 No Yes
SHA512 No Yes

10. New Enumerations & Enum Value Additions

CertificateSigningUseEnumType

Value 2.0.1 2.1
ChargingStationCertificate Yes Yes
V2GCertificate Yes Yes
V2G20Certificate No Yes

MessageTriggerEnumType (security-relevant values)

Value 2.0.1 2.1
SignChargingStationCertificate Yes Yes
SignV2GCertificate Yes Yes
SignCombinedCertificate Yes Yes
SignV2G20Certificate No Yes

HashAlgorithmEnumType

Value 2.0.1 2.1
SHA256 Yes Yes
SHA384 No Yes
SHA512 No Yes

ResetEnumType (used in A05)

Value 2.0.1 2.1
Immediate Yes Yes
OnIdle Yes Yes
ImmediateAndResume No Yes

11. Migration Checklist

Must Do Breaking / Behavioral

A01

Mark as deprecated; implement B09 as the preferred password update method for new deployments.

A02/A03

Handle new hashRootCertificate field in SignCertificateRequest — use it to route CSR to the correct CA if present.

A02/A03

Handle new requestId field — echo it back in CertificateSignedRequest when present.

A02/A03

Support V2G20Certificate as a valid certificateType value.

A02

Handle SignV2G20Certificate in TriggerMessageRequest.

A02

Handle duplicate SignCertificateRequest messages due to CS retry behavior (exponential back-off).

A04

Treat ALL security event types as critical (update alerting rules).

A04

Handle renamed event CentralSystemFailedToAuthenticate (previously CsmsFailedToAuthenticate). Support both names during transition.

A04

Handle new event DiscardedRenewedClientCertificate.

A04

Handle late-arriving events (guaranteed delivery means events may arrive after reconnection with timestamps in the past).

A05

Rewrite the upgrade flow. Replace InstallCertificate + SetVariables(SecurityProfile) with SetVariables(NetworkConfigurationPriority) + ResetRequest + BootNotification handling.

A05

Ensure certificates are installed as prerequisites before starting A05 (no longer part of the flow).

A05

Target OCPPCommCtrlr.NetworkConfigurationPriority instead of SecurityCtrlr.SecurityProfile.

A05

Send ResetRequest(OnIdle) after successful SetVariablesResponse.

A05

After upgrade, refuse connections from CS on lower security profiles (A05.FR.07).

Should Do Recommended

Update attributeValue maxLength validation from 1000 to 2500.

Update additionalInfo maxLength validation from 512 to 1024.

Update InstallCertificateRequest.certificate maxLength from 5500 to 10000.

Support SHA384 and SHA512 in HashAlgorithmEnumType.

Support OEMRootCertificate certificate type.

Implement GetInstalledCertificateIdsRequest for certificate auditing.

Implement DeleteCertificateRequest for certificate lifecycle management.

Accept and pass through customData in all messages without rejection.

Maintain dual RSA + ECDSA certificates for Profile 2/3 TLS endpoints.

Apply A00.FR.320: reject cipher suites with primitives marked unsuitable for legacy use (stricter than 2.0.1).

Apply A00.FR.707: validate both firmware signing certificate and signed firmware before provisioning to CS.

OCPP 2.1 Security Section Migration Guide — Use Cases A01–A05 — CSMS Developer Perspective