Security Section — Migration Guide
Use cases A01–A05 (Security Flows) and Connection-Level Security. Perspective: CSMS Developer.
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.
{
"customData": {
"vendorId": "com.example.vendor"
}
}4. A01 — Update Charging Station Password
DeprecatedDeprecation 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:
- Continue supporting A01 for Charging Stations that have not been updated.
- Prefer B09 for new deployments or updated stations.
Schema Changes
The SetVariablesRequest/SetVariablesResponse schema changes apply:
attributeValuemaxLength: 1000 → 2500additionalInfomaxLength: 512 → 1024
5. A02 — Update Charging Station Certificate by Request of CSMS
ExtendedNew 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). |
{
"csr": "<PEM-encoded CSR>",
"certificateType": "ChargingStationCertificate"
}{
"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). |
{
"certificateChain": "<PEM certificate chain>",
"certificateType": "ChargingStationCertificate"
}{
"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
ExtendedSame New Fields as A02
The SignCertificateRequest and CertificateSignedRequest changes from A02 apply identically to A03:
hashRootCertificate(new inSignCertificateRequest)requestId(new in both messages)V2G20Certificateenum 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
ChangedAll 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).
{}{
"customData": {
"vendorId": "com.example.vendor"
}
}8. A05 — Upgrade Charging Station Security Profile
RedesignedThis is the most significantly changed use case in the Security section. The entire flow has been redesigned.
Flow Comparison
2.0.1 Flow
- CSMS sends
InstallCertificateRequest(install root/client certs) as part of the upgrade flow. - CSMS optionally runs A02 (for Profile 3 upgrade).
- CSMS sends
SetVariablesRequest(SecurityProfile=<new_profile>)toSecurityCtrlr. - CS disconnects and reconnects on the new profile.
2.1 Flow
- Prerequisites: All certificates must already be installed via separate operations.
- CSMS sends
SetVariablesRequest(NetworkConfigurationPriority=<new_order>)toOCPPCommCtrlr. - CSMS sends
ResetRequest(type=OnIdle). - CS reboots and reconnects using the first entry in
NetworkConfigurationPriority. - CS sends
BootNotificationRequeston 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
{
"setVariableData": [{
"component": {
"name": "SecurityCtrlr"
},
"variable": {
"name": "SecurityProfile"
},
"attributeValue": "3"
}]
}{
"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
{
"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
ExtendedNew 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
Mark as deprecated; implement B09 as the preferred password update method for new deployments.
Handle new hashRootCertificate field in SignCertificateRequest — use it to route CSR to the correct CA if present.
Handle new requestId field — echo it back in CertificateSignedRequest when present.
Support V2G20Certificate as a valid certificateType value.
Handle SignV2G20Certificate in TriggerMessageRequest.
Handle duplicate SignCertificateRequest messages due to CS retry behavior (exponential back-off).
Treat ALL security event types as critical (update alerting rules).
Handle renamed event CentralSystemFailedToAuthenticate (previously CsmsFailedToAuthenticate). Support both names during transition.
Handle new event DiscardedRenewedClientCertificate.
Handle late-arriving events (guaranteed delivery means events may arrive after reconnection with timestamps in the past).
Rewrite the upgrade flow. Replace InstallCertificate + SetVariables(SecurityProfile) with SetVariables(NetworkConfigurationPriority) + ResetRequest + BootNotification handling.
Ensure certificates are installed as prerequisites before starting A05 (no longer part of the flow).
Target OCPPCommCtrlr.NetworkConfigurationPriority instead of SecurityCtrlr.SecurityProfile.
Send ResetRequest(OnIdle) after successful SetVariablesResponse.
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.