Signed Update Firmware

Source: OCPP 1.6 Security Whitepaper Edition 2 (2020-03-31) — Use Case L01 (Secure Firmware Update), Sections 5.21 / 5.22 (Messages)

Overview

The Central System uses SignedUpdateFirmware.req to instruct the Charge Point to download and install a digitally-signed firmware image. This message is the OCPP 2.0.1 UpdateFirmware ported into OCPP 1.6 — it was renamed to avoid clashing with the legacy UpdateFirmware.req from OCPP 1.6 (which carries no signature).

The PDU contains a FirmwareType element with the firmware location, retrieval and installation times, the signing certificate, and the firmware signature. The Charge Point reports progress via SignedFirmwareStatusNotification.

Behavioural rules:

• On receiving SignedUpdateFirmware.req, the CP SHALL validate the certificate before accepting the message:
  • If the certificate is invalid → respond with SignedUpdateFirmware.conf(status = InvalidCertificate) and emit SecurityEventNotification.req(InvalidFirmwareSigningCertificate).
  • If the certificate is revoked → respond with SignedUpdateFirmware.conf(status = RevokedCertificate).
• The signature SHALL be validated over the entire firmware file using RSA-PSS or ECSchnorr with SHA-256 hashing.
• If the CP is already installing (or scheduled to install) firmware and a new SignedUpdateFirmware.req arrives, the CP SHOULD cancel the ongoing update and respond with AcceptedCanceled. If it cannot cancel, it MAY respond with Rejected.
• If the legacy OCPP 1.6 UpdateFirmware.req arrives instead, the CP SHALL respond with WebSocket CALLERROR NotSupported and SHALL NOT start the firmware update process.
• The CP SHALL wait until all transactions have ended before commencing installation, when continuing to charge during installation is not possible. While waiting, the CP SHALL set unused connectors to UNAVAILABLE.
• The Central System SHALL include the Firmware Signing certificate in firmware.signingCertificate. The manufacturer SHALL NOT use intermediate certificates for the firmware signing certificate in the Charge Point.

Sequence Diagram

Excerpt of Figure 13. Secure firmware update happy flow

Central System  ──── SignedUpdateFirmware.req ────▶  Charge Point
                     (requestId, firmware{location, retrieveDateTime,
                                           installDateTime?, signingCertificate, signature},
                      retries?, retryInterval?)
                                                     Verify certificate
Central System  ◀─── SignedUpdateFirmware.conf ────  Charge Point
                     (status)
                                       (then a series of SignedFirmwareStatusNotification.req
                                        messages reporting Downloading → Downloaded →
                                        SignatureVerified → Installing → Installed)

Initiator

Central System → Charge Point

Fields

FirmwareType

UpdateFirmwareStatusEnumType values

• Accepted — Accepted this firmware update request. The CP will start the firmware update process.
• Rejected — Firmware update request rejected.
• AcceptedCanceled — Accepted, but in doing so canceled an ongoing firmware update.
• InvalidCertificate — The certificate is invalid.
• RevokedCertificate — Failure end state. The Firmware Signing certificate has been revoked.

Examples

{
  "requestId": 123,
  "retries": 3,
  "retryInterval": 600,
  "firmware": {
    "location": "https://firmware.example.com/cp/2.1.0/firmware.bin",
    "retrieveDateTime": "2026-04-28T02:00:00Z",
    "installDateTime": "2026-04-28T03:00:00Z",
    "signingCertificate": "-----BEGIN CERTIFICATE-----\nMIIE...\n-----END CERTIFICATE-----",
    "signature": "MEUCIQDg7v9...base64...kIM2Q=="
  }
}

{
  "status": "Accepted"
}

Related Configuration Keys

• SupportedFileTransferProtocols — File transfer protocols the CP supports for firmware download.

Schema

Source: schemas/SignedUpdateFirmware.json, schemas/SignedUpdateFirmwareResponse.json (OCPP 1.6 Security Whitepaper, JSON Schema draft-06)