OCPP Firmware Updates: Pushing Software to Chargers Safely

Firmware updates are how charging stations get bug fixes, security patches, and new features over time. Without remote firmware update capability, every issue would require a technician visit — economically impossible for a network of hundreds or thousands of chargers.

OCPP provides the protocol mechanism for remote firmware updates. This article covers how it works, the security considerations, and the operational realities of running firmware updates across a real fleet.

Why firmware updates matter

A typical charger’s firmware controls:

• The OCPP communication layer.
• The contactor and relay logic.
• Safety interlocks.
• The display and user interface.
• The metering and reporting logic.
• The ISO 15118 stack (if supported).
• Smart-charging behavior.
• Security and certificate management.

Bugs in any of these can cause real problems — chargers that won’t start sessions, miscount energy, fail safety checks, or expose security holes. Firmware updates are how those bugs get fixed.

In production fleets, firmware updates happen routinely. Typical cadence: monthly to quarterly. Critical security patches go out immediately when needed.

The basic flow

A typical firmware update:

1. The CSMS decides to update a specific charger (or batch of chargers) to a specific firmware version.
2. The CSMS sends UpdateFirmware (1.6) or SignedUpdateFirmware (1.6 security ext / 2.0.1) to the charger. The message includes the URL where the charger can download the firmware, the signature, the retry policy, the install window.
3. The charger validates the request — is the URL trusted, is the signature valid (for signed updates)?
4. The charger downloads the firmware from the specified URL.
5. The charger sends FirmwareStatusNotification at each stage (Downloading, DownloadFailed, Downloaded, Installing, Installed, InstallationFailed).
6. The charger applies the firmware — typically requiring a reboot.
7. The charger reboots and sends BootNotification with the new firmware version.
8. The CSMS confirms the new firmware version is what was expected.

sequenceDiagram
    participant CSMS
    participant Charger
    participant Server as Firmware Server
    CSMS->>Charger: UpdateFirmware
    Charger->>Server: Download firmware
    Charger-->>CSMS: Status Downloading
    Charger-->>CSMS: Status Downloaded
    Charger->>Charger: Verify signature
    Charger-->>CSMS: Status Installing
    Charger->>Charger: Apply and reboot
    Charger->>CSMS: BootNotification new version

The user (if there’s a session in progress when the update arrives) typically experiences either no impact (update is scheduled for after the session ends) or a brief outage during the reboot. The BootNotification message ^{(coming soon)} that follows a reboot is how the CSMS confirms the new firmware version actually took effect.

OCPP 1.6: UpdateFirmware

The basic 1.6 message:

{
  "location": "https://firmware.example.com/charger/v1.4.7.bin",
  "retrieveDate": "2026-06-26T22:00:00Z",
  "retries": 3,
  "retryInterval": 300
}

• location: URL to download the firmware.
• retrieveDate: when to start the download.
• retries / retryInterval: what to do if download fails.

This is unsigned. The charger trusts the URL and downloads whatever is there. Major security weakness — if an attacker can compromise the firmware server (or DNS), they can push arbitrary firmware to any charger that receives this URL.

For this reason, OCPP 1.6 added the Security extensions (published 2018) including SignedUpdateFirmware. Many production deployments use the security-extension version exclusively.

OCPP 1.6 Security Extensions: SignedUpdateFirmware

The secure version:

{
  "retries": 3,
  "retryInterval": 300,
  "requestId": 12345,
  "firmware": {
    "location": "https://firmware.example.com/charger/v1.4.7.bin",
    "retrieveDateTime": "2026-06-26T22:00:00Z",
    "signingCertificate": "...PEM-encoded cert...",
    "signature": "...signature over the firmware..."
  }
}

The signingCertificate and signature let the charger verify that the firmware was signed by a trusted authority before installing.

The flow:

1. Charger downloads the firmware from the URL.
2. Charger validates the signature using the signingCertificate.
3. Validates that the certificate chains to a trusted root.
4. If validation passes, applies the firmware. If not, rejects.

This prevents attackers from pushing rogue firmware even if they compromise the URL.

Production OCPP 1.6 deployments should use SignedUpdateFirmware exclusively. Plain UpdateFirmware should be disabled.

OCPP 2.0.1: UpdateFirmwareRequest

OCPP 2.0.1 made signed updates the default (no separate “security extension” — it’s in the spec). For a broader look at how the versions differ, see the OCPP version comparison ^{(coming soon)}. The message:

{
  "retries": 3,
  "retryInterval": 300,
  "requestId": "abc-123-def",
  "firmware": {
    "location": "https://firmware.example.com/charger/v2.1.0.bin",
    "retrieveDateTime": "2026-06-26T22:00:00Z",
    "installDateTime": "2026-06-27T03:00:00Z",
    "signingCertificate": "...",
    "signature": "..."
  }
}

Similar to 1.6 SignedUpdateFirmware. The installDateTime field is new — lets you schedule when the install actually happens (vs just when the download begins).

OCPP 2.0.1 also has more granular status reporting via FirmwareStatusNotificationRequest.

The status notifications

During an update, the charger sends FirmwareStatusNotification (1.6) or FirmwareStatusNotificationRequest (2.0.1) at each stage.

Common status values:

• Downloaded — firmware download complete.
• DownloadFailed — download failed.
• Downloading — download in progress.
• DownloadScheduled — download scheduled for later.
• DownloadPaused — paused (e.g., wifi went away).
• Idle — no firmware activity.
• InstallationFailed — install failed.
• Installing — install in progress.
• Installed — install complete.
• InstallRebooting — rebooting to apply.
• InstallScheduled — install scheduled for later.
• InstallVerificationFailed — signature/integrity check failed.
• InvalidSignature — signature didn’t validate.
• InvalidCertificate — signing cert didn’t validate.
• RevokedCertificate — signing cert was revoked.

The CSMS tracks these status updates and presents them in an operations dashboard. A charger that’s been “Downloading” for an hour is probably stuck and needs investigation.

Scheduling matters

Firmware updates cause downtime. Plan them.

Schedule for low-utilization windows. Overnight in residential locations; early morning before commuter rush; weekends for retail sites.

Pre-announce to users where possible. Some networks display “scheduled maintenance” messages on the charger before the window.

Batch rather than all-at-once. Don’t update your entire fleet simultaneously — partial failures spread across batches are less catastrophic than a fleet-wide bug.

Reserve time for download. A cellular-connected charger may take 20 minutes to download a 50 MB firmware. Account for this in scheduling.

Failure modes

A list of things that go wrong with firmware updates.

Download fails. Network outage, server unavailable, file too large for the cellular plan. Charger retries; eventually gives up. Need to reschedule.

Signature validation fails. Signing cert wrong, cert revoked, signing process error. Charger rejects. Operators need to fix the signing infrastructure.

Install fails. Firmware doesn’t apply correctly — bug in the new firmware, hardware incompatibility, insufficient flash space. Charger may rollback (if supported) or remain on old firmware.

Install succeeds but boot fails. New firmware has a bug that prevents the charger from starting normally. If hardware has rollback, it returns to the previous firmware after a watchdog timeout. If no rollback, charger is bricked until physical recovery.

Update completes but feature regression. Update applied successfully but a previously-working feature is broken in the new version. Discovered later by operators or users.

Mitigations:

• Test firmware on a small fleet first. Pilot on 10-50 chargers before broader rollout. Catch issues with limited blast radius.
• Hardware-level rollback. Some chargers support A/B firmware slots — the new firmware goes to slot B, on successful boot it becomes active, on failure it reverts to slot A. Production-grade pattern.
• Pre-release validation. Run the firmware in a lab, test against your CSMS, verify OCPP interactions work.
• Quick rollback plan. Be ready to push the previous version back to chargers if a new version turns out to have problems.

Security beyond signatures

Beyond signed updates, a few other security practices.

TLS for the download URL. HTTPS, modern cipher suites. Don’t allow firmware download over plain HTTP.

Pin the trusted root. Don’t let the charger trust any random CA for firmware signing. Limit to your specific signing authority.

Audit firmware deployments. Log every UpdateFirmware sent. Log every FirmwareStatusNotification received. Operations team should be able to answer “what firmware is on which charger as of when.”

Limit who can initiate firmware updates. In your CSMS, restrict the “push firmware” action to specific roles. Don’t let any operator update any charger.

Code signing infrastructure. The signing process itself needs security. HSM-protected keys, multi-person approval, audit logs.

Operational best practices

A short list for CPOs running firmware updates at scale.

1. Maintain a per-charger firmware inventory. Know what’s running where.
2. Plan updates in waves (canary → small group → broader rollout).
3. Monitor BootNotification frequency post-update. A spike of reboots means something’s wrong.
4. Have a rollback plan for every firmware push.
5. Coordinate with OEMs on firmware compatibility — some updates require coordinated CSMS changes.
6. Document expected behavior changes so support teams aren’t surprised.
7. Audit firmware status regularly — chargers stuck in old versions need attention.

What this means for CSMS implementers

If you’re building a CSMS, your firmware update implementation should:

Support both signed and unsigned modes (for backward compatibility, but default to signed).

Implement scheduled installs (don’t force operators to push during business hours).

Track firmware status per charger with full audit log.

Handle stuck updates — alert when a charger has been “Downloading” for too long.

Support batch operations — push firmware to many chargers at once with appropriate concurrency limits.

Integrate with the OEM’s firmware signing infrastructure — your CSMS should pull the latest signed firmware from a trusted source automatically.

Provide rollback capability in your operator UI.

The honest summary

OCPP firmware updates are the mechanism that makes long-term operation of remote chargers viable. Get the security right (signed updates only), schedule deliberately, monitor obsessively, and have a rollback plan. Most firmware update problems trace to operational shortcuts — pushing untested firmware to production, failing to monitor status, lacking rollback capability. Treat firmware updates with the rigor they deserve and your fleet operations stay smooth.