Key takeaways
- Because the gap described above is not theoretical — it shows up repeatedly in production systems that CISA has disclosed.
- SaiFlow's 2023 research targeted the same architectural soft spot from a different angle: what happens when an attacker deliberately opens a second OCPP connection using a legitimate charger's identity.
- Yes — CVE-2025-5517, covered in CISA's ICSA-26-146-01 and disclosed by ABB, is a heap-based buffer overflow (CWE-122) in ABB Terra AC wallbox firmware, CVSS v3.1 6.8 (vector AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H).
- Profile 1 is still defined and usable in OCPP 2.0.1 and 2.1.
OCPP, the Open Charge Alliance's protocol connecting EV charging stations to their backend management systems, still defines Security Profile 1 — an unencrypted WebSocket with only optional HTTP Basic Authentication — as a legal configuration in both OCPP 1.6 and OCPP 2.0.1/2.1, and in 2026 CISA published a run of ICS advisories for real deployments using exactly that gap, including Monta (CVE-2026-95102, CVSS 9.4), Everon (CVE-2026-26288, CVSS 9.4), and Hydro-Québec's Le Circuit Electrique (CVE-2026-20744, CVSS 9.8), all for OCPP WebSocket endpoints accepting connections with no real authentication. The protocol itself has offered a stronger option — Security Profile 2 (TLS plus Basic Auth) and Profile 3 (mutual TLS with client certificates) — since the OCPP 1.6 Security Whitepaper was first published, but the insecure default was never removed, and the pattern of 2026 advisories shows it is still being deployed at scale.
What is OCPP and what does it secure by default?
OCPP is the application-layer protocol that lets a Charge Point (OCPP 1.6 terminology) or Charging Station (OCPP 2.x terminology) talk to the Charging Station Management System (CSMS) that authorizes charging sessions, issues firmware updates, and sends remote commands such as Reset or UnlockConnector. OCPP 1.6 runs primarily as OCPP 1.6J, JSON messages over a WebSocket connection (an older SOAP-based OCPP-S variant is not covered by the security backport described below). The base OCPP 1.6 specification, as originally published, defined no mandatory transport security whatsoever — any security had to be bolted on by the deploying operator, which is why the Open Charge Alliance later published a dedicated document, "Improved security for OCPP 1.6-J" (commonly called the OCPP 1.6 Security Whitepaper, now at Edition 4), to retrofit a security model onto an already-deployed protocol. OCPP 2.0.1 and 2.1 build the same three-tier Security Profile model into the core specification from the start rather than as an add-on, which is a real improvement in how security is specified — but critically, Profile 1 (no transport encryption) remains a defined, implementable option in both 2.0.1 and 2.1. The insecure configuration was never deprecated; it was simply joined by two better ones.
What do Security Profiles 1, 2, and 3 actually require?
| Security Profile 1 | Security Profile 2 | Security Profile 3 | |
|---|---|---|---|
| Transport | Plain ws:// WebSocket, no encryption |
wss:// WebSocket, TLS 1.2 or higher |
wss:// WebSocket, TLS 1.2 or higher |
| Charging Station authentication | Optional HTTP Basic Auth, sent in the clear | HTTP Basic Auth, protected by TLS | X.509 client certificate (mutual TLS) |
| CSMS authentication | None | TLS server certificate | TLS server certificate |
| Password requirement (OCPP 2.0.1 Part 2 / errata) | Not applicable | BasicAuthPassword: minimum 16, maximum 40 characters, UTF-8 | Not applicable (certificate-based) |
| OCA certification status | Optional; insufficient alone for certification | Mandatory minimum for OCPP 2.x Core certification | Optional "Advanced Security" certification profile |
The OCA's own Security Operations Guide notes that the 16-character minimum for Profile 2's Basic Auth password was, at the time it was written, considered a strong password length by CISA's own password guidance — but it also carries an operational catch independent researchers have flagged: because the Charging Station needs the plaintext password to authenticate, the password cannot be stored hashed on the backend, so the main compensating control is ensuring every station gets a unique password rather than a fleet-wide shared one. None of this changes the fact that Profile 1 — with no TLS at all — remains a legal, certifiable-for-some-purposes configuration across every current OCPP version.
Why do real CISA advisories keep citing missing authentication on OCPP endpoints?
Because the gap described above is not theoretical — it shows up repeatedly in production systems that CISA has disclosed. A sample from 2026:
- ICSA-26-274-02 (Monta, all versions). CVE-2026-95102 (CVSS 9.4): OCPP WebSocket endpoints "lack proper authentication mechanisms, enabling attackers to impersonate charging stations," compounded by CVE-2026-93474 (CVSS 6.5), which notes that charging station identifiers are "publicly accessible via web-based mapping platforms" — meaning the one piece of information an attacker needs to impersonate a station is not even secret.
- ICSA-26-062-08 (Everon OCPP Backends). CVE-2026-26288 (CVSS 9.4) is the same missing-authentication pattern; CVE-2026-20748 (CVSS 7.3) is a session-hijacking flaw where the backend "allows multiple endpoints to connect using the same session identifier," so the most recently connected client — legitimate or not — displaces the real charger and receives its commands. Everon's eventual response was to shut its platform down entirely on December 1, 2025, rather than remediate in place.
- ICSA-26-188-01 (Hydro-Québec, Le Circuit Electrique). CVE-2026-20744 (CVSS 9.8) states the "charging station websocket endpoint accepts connections without proper authentication, which could lead to privilege escalation." Hydro-Québec's stated mitigation was to disable OCPP on the majority of its charging stations and add authentication only for the remainder still dependent on it — a telling signal that retrofitting authentication onto an already-deployed OCPP fleet was harder than simply turning the protocol off.
- ICSA-26-022-08 (EVMAPA). CVE-2025-54816 (CVSS 9.4) is again missing authentication on the WebSocket endpoint; CVE-2025-55705 covers the same multiple-simultaneous-connections-per-charger-ID weakness seen at Everon.
The consistency of "unauthenticated OCPP WebSocket" and "shared/predictable charger identity used as the only credential" across five-plus independently operated platforms in a single year indicates this is a common deployment default, not a one-off coding mistake in a single vendor's stack.
What did independent researchers find beyond what CISA disclosed?
SaiFlow's 2023 research targeted the same architectural soft spot from a different angle: what happens when an attacker deliberately opens a second OCPP connection using a legitimate charger's identity. The OCPP standard, per SaiFlow, "doesn't define how a CSMS should accept new connections from a charge point when there is already an active connection" — CSMS vendors handle it inconsistently, and the worst case SaiFlow documented is a CSMS that silently keeps routing to the new, attacker-controlled connection while neither the CSMS nor the original Charge Point surfaces any alert to the operator. SaiFlow paired this with OCPP 1.6J's authentication design: three methods exist (identity alone, identity plus credentials, identity plus client certificate), charger identifiers don't change over the device's life, and most CSMS deployments SaiFlow observed defaulted to identity-alone — the weakest of the three. Combined, SaiFlow assessed this could enable "a vast Distributed DoS (DDoS) attack on the EVSE network," plus theft of CSMS credentials or payment data from a hijacked session.
Pen Test Partners' earlier hardware- and API-focused research (around 2021) found a different set of issues closer to the device and vendor cloud layer rather than the OCPP wire protocol itself: insecure direct object references in charger vendor web APIs, an unauthenticated Telnet service exposed on an EO mini pro charger, and a Growatt-connected public network where locking or unlocking a charger required only a predictable serial number and an unvalidated username — enough to halt active charging sessions. These findings are adjacent to OCPP security rather than flaws in the OCPP specification itself, but they describe the same operator-side pattern: authentication treated as optional at the edges of the charging ecosystem.
Can a firmware bug on the charger itself be triggered over OCPP?
Yes — CVE-2025-5517, covered in CISA's ICSA-26-146-01 and disclosed by ABB, is a heap-based buffer overflow (CWE-122) in ABB Terra AC wallbox firmware, CVSS v3.1 6.8 (vector AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H). Affected firmware fails to validate the length of a specific field inside an incoming OCPP message; an oversized, specially crafted message — reachable either through a man-in-the-middle position on an unencrypted OCPP link or directly from a compromised or malicious CSMS — triggers the overflow. SaiFlow's disclosure write-up describes the practical impact as being able to crash a charger into an unresponsive state with a single message, which it frames as a "Denial-of-Charge" risk at fleet scale rather than a one-charger inconvenience. Both ABB's own advisory and CISA's mitigation guidance for this CVE specifically call out enforcing HTTPS/TLS on the OCPP link as a compensating control — explicitly tying a firmware memory-safety bug back to the same transport-security gap (Profile 1 / unencrypted deployment) documented throughout this guide, because an encrypted, authenticated channel makes injecting the triggering message substantially harder for an outside attacker.
Does upgrading to OCPP 2.0.1 or 2.1 fix this on its own?
Not by itself. SaiFlow's own assessment states OCPP 2.0.1 "will require CP credentials as the minimal obligatory security profile," which matches the OCA's certification rules: OCPP 2.x Core certification mandates at least Security Profile 2, unlike the original OCPP 1.6 base spec, which required nothing until the Security Whitepaper backport arrived. That is real progress in the specification's own baseline. But two things the version number does not guarantee:
Profile 1 is still defined and usable in OCPP 2.0.1 and 2.1"Built on OCPP 2.0.1" is not the same claim as "deployed with Security Profile 2 or 3 enforced" — several of the 2026 CISA advisories above describe backends with no meaningful authentication regardless of which OCPP version the fleet technically ran. The multiple-connection ambiguity SaiFlow identified is a CSMS implementation behavior, not something a protocol version bump resolves automatically. SaiFlow's own recommended mitigation — validating active connections via ping/heartbeat requests before accepting a new one under the same charger identity — is an operational control a CSMS operator has to actually implement, not a guarantee that comes bundled with the newer spec.
Checklist for charging station operators and manufacturers
Confirm which Security Profile is actually enforced on every CSMS-facing connection, not just which OCPP version is nominally supported — Profile 1 (no TLS) remains legal in OCPP 1.6, 2.0.1, and 2.1 alike, and several 2026 CISA advisories describe fleets where the gap was exactly this: a protocol capable of better security, configured without it. Move to Security Profile 2 at minimum, and Profile 3 (mutual TLS with client certificates) for public or high-value infrastructure, matching the OCA's own Core (Profile 2) versus Advanced Security (Profile 3) certification tiers. Issue a unique Basic Auth password per charging station, at the OCPP 2.0.1 minimum length of 16 characters, rather than one shared fleet-wide credential — since the password cannot be stored hashed on the CSMS side, per-station uniqueness is the main compensating control against a single leaked credential compromising the whole fleet. Treat charging station identifiers as public, not secret, per the Monta and Everon advisories where station IDs were discoverable via public charging maps — authentication has to not depend on the identifier itself being unknown to an attacker. Validate that your CSMS rejects or alerts on a second connection attempt using an already-active charger identity, per SaiFlow's findings — ping/heartbeat validation before accepting a new session under an existing identity closes the specific DoS/hijack path SaiFlow documented. Keep charging station firmware current and confirm the OCPP link runs over TLS, since ABB's own mitigation guidance for CVE-2025-5517 ties a firmware memory-safety bug directly back to whether the transport is encrypted in the first place. Don't treat "OCPP 2.0.1 compliant" or "OCPP 2.1 compliant" as a security claim by itself— ask specifically which Security Profile is configured in production, since the newer specifications still define the same insecure Profile 1 option as the 1.6 Security Whitepaper did.
This guide draws on the Open Charge Alliance's own published OCPP 1.6, 2.0.1, and 2.1 download pages and Security Whitepaper references, CISA ICS advisories (ICSA-26-274-02, ICSA-26-062-08, ICSA-26-188-01, ICSA-26-022-08, ICSA-26-146-01), and SaiFlow's own published research on OCPP connection-hijacking/DoS and the ABB Terra AC buffer overflow. The OCA's full OCPP Security Operations Guide v2.0 PDF and the OCPP 2.0.1 Part 2 errata PDF were located at their official URLs but did not render as extractable text through this review's tooling; the password-length and profile details attributed to those documents here are corroborated through secondary technical summaries (including the OCA's own public security-profile explainer language quoted in aggregator coverage) rather than a direct clause-by-clause reading of those two PDFs, and that gap should be treated as a hedge rather than a confirmed verbatim citation. Pen Test Partners' findings are represented here through secondary reporting rather than a directly fetched Pen Test Partners original post, since this review was not able to retrieve one directly. This guide is general information, not a substitute for a direct security review of a specific charging network's actual CSMS configuration.
Sources
- Open Charge Alliance: Download OCPP (versions 1.6, 2.0.1, 2.1, and OCPP 1.6 Security Whitepaper Edition 4)
- CISA ICS Advisory ICSA-26-274-02: Monta (OCPP WebSocket missing authentication, CVE-2026-95102, CVSS 9.4)
- CISA ICS Advisory ICSA-26-062-08: Everon OCPP Backends (missing authentication and session hijacking, CVE-2026-26288 / CVE-2026-20748)
- CISA ICS Advisory ICSA-26-188-01: Hydro-Québec Le Circuit Electrique charging station backend (CVE-2026-20744, CVSS 9.8)
- CISA ICS Advisory ICSA-26-022-08: EVMAPA EV charging stations (CVE-2025-54816, CVSS 9.4)
- CISA ICS Advisory ICSA-26-146-01 / ABB advisory: Terra AC wallbox heap buffer overflow (CVE-2025-5517)
- SaiFlow: Hijacking EV Charge Points to Cause DoS
- SaiFlow: ABB Terra AC Buffer Overflow Vulnerability (CVE-2025-5517)
Frequently asked questions
What is OCPP and what does it secure (or fail to secure) by default?
OCPP (Open Charge Point Protocol), maintained by the Open Charge Alliance (OCA), is the dominant application-layer protocol between an EV charging station (the Charge Point, or in OCPP 2.x terms the Charging Station) and the backend Charging Station Management System (CSMS) that authorizes charging sessions, pushes firmware, and issues remote commands like reset or unlock-connector. OCPP 1.6 runs as OCPP 1.6J over WebSockets (an earlier SOAP-based OCPP-S variant exists but is not addressed by the security backport). Critically, the base OCPP 1.6 specification defines no mandatory transport security at all — security was added later, via a dedicated document titled 'Improved security for OCPP 1.6-J,' commonly called the OCPP 1.6 Security Whitepaper, now at Edition 4. That whitepaper defines three Security Profiles, and Profile 1 — unencrypted WebSocket with optional HTTP Basic Authentication — is still a legal, implementable configuration today. OCPP 2.0.1 and 2.1 build the same three-profile model directly into the core specification rather than bolting it on afterward, but Profile 1 remains defined in those versions too, meaning the insecure option was never removed, only joined by better ones.
What do OCPP Security Profiles 1, 2, and 3 actually require?
Security Profile 1 ('Unsecured Transport with Basic Authentication') uses a plain ws:// WebSocket with no transport encryption at all; HTTP Basic Authentication is optional on top of that plaintext channel, meaning even the credential can be sent in the clear. Security Profile 2 ('TLS with Basic Authentication') requires a wss:// WebSocket secured with TLS 1.2 or higher, with the Charging Station authenticating to the CSMS via HTTP Basic Auth over that encrypted channel and the CSMS authenticating to the Charging Station via its TLS server certificate; the OCPP 2.0.1 Part 2 specification and errata define a BasicAuthPassword requirement of a minimum 16 and maximum 40 characters, sent as UTF-8, which the OCA's own Security Operations Guide notes was, at time of writing, considered a strong password length by CISA guidance. Security Profile 3 ('TLS with Client-Side Certificates') adds mutual TLS: the Charging Station presents its own X.509 client certificate rather than (or in addition to) a Basic Auth password, so both ends authenticate cryptographically. All three profiles exist, unchanged in concept, across OCPP 1.6 (via the Security Whitepaper backport), OCPP 2.0.1, and OCPP 2.1 — the protocol family has never deprecated Profile 1.
Why do real CISA ICS advisories keep citing missing authentication on OCPP WebSocket endpoints?
Because Profile 1 (or a Profile 2/3 deployment that silently falls back to no authentication) is still common in production, and 2026 alone produced a run of CISA ICS advisories describing exactly that gap on live CSMS backends. ICSA-26-274-02 (Monta, all versions) lists CVE-2026-95102 (CVSS 9.4) for OCPP WebSocket endpoints that 'lack proper authentication mechanisms, enabling attackers to impersonate charging stations.' ICSA-26-062-08 (Everon OCPP Backends) lists CVE-2026-26288 (CVSS 9.4) for the same pattern, plus CVE-2026-20748 for session hijacking where the backend 'allows multiple endpoints to connect using the same session identifier,' letting the most recent connection displace the legitimate charger. ICSA-26-188-01 (Hydro-Québec's Le Circuit Electrique) lists CVE-2026-20744 (CVSS 9.8) because its 'charging station websocket endpoint accepts connections without proper authentication,' and Hydro-Québec's own stated remediation was to disable OCPP on most of its charging stations outright rather than fix the authentication gap in place. Related advisories for CTEK Chargeportal (ICSA-26-078-06), ev.energy (ICSA-26-057-07), EV2GO (ICSA-26-057-04, where the vendor did not respond to CISA's coordination request), EVMAPA (ICSA-26-022-08, CVE-2025-54816, CVSS 9.4), and mobility46.se (CVE-2026-27028) describe the same missing-authentication and publicly-discoverable-charger-ID pattern. The repetition across independent vendors in a single year indicates a systemic deployment gap, not an isolated bug in one product.
What did independent security researchers find beyond the CISA advisories?
SaiFlow, an EV-charging-focused security research firm, published findings in 2023 on two compounding weaknesses in OCPP 1.6J. First, the OCPP standard 'doesn't define how a CSMS should accept new connections from a charge point when there is already an active connection' — different CSMS implementations handle a second, attacker-initiated connection using the same charger identity inconsistently, and SaiFlow called the case where the CSMS silently keeps the old session but routes traffic to the new one 'the most problematic since neither the CSMS nor the CP won't notify the Charge Point Operator.' Second, SaiFlow documented that OCPP 1.6J's authentication model supports three methods — charger identity alone, identity plus credentials, and identity plus client certificate — and that most CSMS providers default to identity-alone, the weakest option, which is brute-forceable since charger identifiers are static for the device's lifetime. Combined, SaiFlow stated these two gaps 'could lead to a vast Distributed DoS (DDoS) attack on the EVSE network' and could additionally expose CSMS credentials or payment data to an attacker who successfully hijacks a connection. Separately, Pen Test Partners' earlier (2021-era) research into home and public charger hardware and backend APIs found insecure direct object references, an unauthenticated Telnet service on an EO mini pro charger, and a public charging network (Shenzhen Growatt-connected) that could be locked or unlocked using only a predictable serial number and an unvalidated username — stopping active charging sessions network-wide was possible through that gap.
Is there a documented firmware-level vulnerability in a specific charging station model, not just a backend API gap?
Yes. CVE-2025-5517, disclosed by ABB and covered in CISA ICS advisory ICSA-26-146-01, is a heap-based buffer overflow (CWE-122) in ABB Terra AC wallbox firmware, CVSS v3.1 score 6.8, with the vector AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H. The root cause is that affected firmware versions (Terra AC UL40/80A through 1.8.32, UL32A through 1.8.2, MID/CE through 1.8.32, and the JP variant through 1.8.2) do not validate the length of a specific field in an incoming OCPP message; a specially crafted, oversized OCPP message sent to the charger — either via a man-in-the-middle position on an unencrypted OCPP connection or directly from a compromised CSMS server — triggers the overflow, which SaiFlow's disclosure write-up states can crash the charger into an unresponsive state (a denial-of-charge condition) and, per ABB's own advisory, carries potential for further memory corruption. ABB's fix was firmware updates (for example 1.8.33 or 1.8.34 depending on model), and both ABB and CISA's mitigation guidance for this specific CVE explicitly call out ensuring the OCPP link between charger and CSMS runs over HTTPS/TLS rather than unencrypted HTTP — i.e., this firmware bug is more dangerous precisely because Profile 1-style unencrypted deployments make the triggering message easier to inject in the first place.
Does moving to OCPP 2.0.1 or 2.1 fix these problems by itself?
Only partially, and only if the better Security Profile is actually configured and enforced — the version number alone does not guarantee it. SaiFlow's own assessment states that OCPP 2.0.1 'will require CP credentials as the minimal obligatory security profile,' which closes off the identity-alone authentication weakness that OCPP 1.6J permits by default; this matches the OCA's certification requirements, where OCPP 2.x core certification mandates support for at least Security Profile 2, versus OCPP 1.6 where the original base spec had no security requirement at all until the Security Whitepaper backport. But two caveats apply directly from the sourced material above. First, Profile 1 is still a defined, legal configuration in OCPP 2.0.1 and 2.1 — 'supports Profile 2' is not the same claim as 'is deployed using Profile 2,' and several of the 2026 CISA advisories describe backends that were simply not enforcing authentication regardless of which OCPP version the fleet ran. Second, the connection-handling ambiguity SaiFlow flagged (what a CSMS does when a second connection arrives using the same charger identity) is a CSMS implementation behavior, not something the OCPP version number fixes on its own; SaiFlow's own recommended mitigation is for CSMS operators to validate connections via ping/heartbeat requests, which is an operational control layered on top of the protocol rather than a protocol-level guarantee.
In this cluster
