CISA’s June 25, 2026 industrial-control advisory says EVoke Systems’ Charging Station Management System can accept WebSocket connections from charging stations without sufficiently authenticating them, allowing an attacker to impersonate EV chargers and potentially issue or receive backend commands. The immediate bug is a missing-authentication flaw; the larger story is that EV charging infrastructure is still dragging legacy device assumptions into an internet-exposed, software-defined energy network. EVoke’s response is not a single patch so much as a migration plan, and that distinction matters.
The uncomfortable part of this advisory is that nothing about it sounds exotic. There is no baroque exploit chain, no speculative side channel, no nation-state-only technique buried in firmware. The failure mode is painfully familiar: a service accepts a network connection, trusts an identifier too much, and gives the other side more authority than it has earned.
In the EV charging world, that “other side” is not a browser or a mobile app. It is a charger talking to a Charging Station Management System, or CSMS, over the Open Charge Point Protocol. That backend is where operators monitor chargers, sessions, meter values, availability, faults, and sometimes remote actions.
The advisory lands because the trust boundary is wrong. If an attacker can connect to the OCPP WebSocket endpoint using a charger identifier and the system does not properly prove that the connecting device is the real charger, the backend can be tricked into treating an impostor as infrastructure.
That is why this is more than a data-integrity issue. Charging networks sit at the intersection of billing, fleet operations, energy management, public infrastructure, and physical equipment. A fake charger session is not just a weird log line; it can become a bad operational decision.
That architecture makes sense. Chargers need to report status changes, receive commands, send meter values, start and stop transactions, and recover from unreliable connectivity. A persistent channel is a practical fit for a field device that may spend years bolted to concrete and managed remotely.
But a persistent channel also concentrates trust. Once a charger is accepted as a valid participant, the backend may process messages as though they come from real hardware. If the connection is authenticated weakly or not at all, the protocol becomes an identity costume: wear the right charger ID, and the system may let you into the conversation.
That is the advisory’s core warning. EVoke’s platform supports multiple OCPP security profiles, but the effective security posture depends on what the deployed charger firmware can actually use. In mixed fleets, the weakest chargers tend to define the real-world attack surface.
OCPP Security Profiles exist precisely because the industry has had to move from basic connectivity toward stronger authentication and encryption. Profile 0 and Profile 1 belong to an earlier era of trust assumptions. Profile 2 adds TLS encryption with basic authentication, while Profile 3 moves toward mutual TLS with client certificates.
That progression is easy to endorse on paper. In the field, it collides with hardware lifecycles, stranded firmware, OEM exits, and site operators that bought chargers years before stronger authentication became table stakes. EVoke says some legacy chargers on its network only support Security Profile 0 or 1, and some models are no longer supported by their manufacturer.
This is the real vulnerability class: not merely “a vendor forgot auth,” but “an ecosystem made unauthenticated or weakly authenticated device identity operationally normal for too long.” CSMS vendors can build stronger doors, but if customers need to keep old locks in service, the front door still has to open for them.
For unsupported legacy chargers, EVoke is moving to server-side protections. The platform will only accept charger IDs registered in its CSMS inventory database and reject unknown identifiers. That is a necessary baseline, but it should not be confused with cryptographic identity.
An allow-list tells the server that a claimed charger ID is one the operator recognizes. It does not, by itself, prove that the connecting endpoint is the physical charger assigned that identity. If the identifier can be guessed, leaked, scraped from documentation, observed in traffic, or inferred from naming conventions, allow-listing narrows the blast radius but does not solve impersonation.
The additional mitigation of allowing only one active connection per charger ID is more interesting operationally. It blocks a common spoofing pattern in which the real charger and the fake charger coexist. If a second connection appears, the system can reject it or terminate the previous session.
That control turns impersonation into an event rather than silent parallel occupancy. It gives defenders something to log, alert on, and investigate. Still, it creates hard choices: terminate the older session and you may knock a legitimate charger offline; reject the newer session and you may miss a real reconnection after a network flap.
The EVBox example in EVoke’s advisory response is exactly the kind of detail that makes asset owners wince. A charger may be physically functional and economically useful but unable to support modern OCPP security profiles because the manufacturer no longer supports the model. At that point, “patch management” becomes “replacement planning,” and replacement planning becomes a budget fight.
This is where IT and operational technology cultures often diverge. In enterprise IT, unsupported systems are risky but usually visible in inventories, vulnerability scanners, endpoint consoles, and procurement records. In charging infrastructure, the estate may be split among site hosts, network operators, charger OEMs, installers, payment providers, cloud services, and utility-facing integrations.
That fragmentation makes simple mandates harder. “Upgrade everything to mutual TLS” is technically correct and politically incomplete. Someone has to know which chargers can do it, which cannot, who owns the replacement cost, and what happens to service availability while the work is performed.
The uncomfortable lesson is that EV infrastructure has to inherit more of enterprise IT’s lifecycle discipline. Devices that cannot authenticate strongly cannot be treated as ordinary long-lived assets. They become exceptions, and exceptions require expiration dates.
That makes device identity the real perimeter. The backend has to know not just that a connection claims to be Charger-17, but that it is Charger-17, using credentials or certificates that cannot be trivially copied into a simulator. This is why the distinction between Profile 2 and Profile 3 matters.
TLS with basic authentication is a meaningful improvement over unauthenticated or weakly authenticated connections, particularly when credentials are unique and rotated. Mutual TLS is stronger because the charger presents a client certificate and the server can verify cryptographic identity during connection establishment. In an ideal deployment, a stolen ID string is useless without the corresponding private key.
But identity systems are operational systems. Certificates expire. Private keys need secure storage. Chargers need provisioning workflows. Field technicians need recovery paths. Backends need revocation, renewal, and inventory alignment.
That complexity is why weaker profiles persisted. It is also why they have to be retired deliberately rather than wished away.
In a billing context, that can affect session records and reconciliation. In a fleet context, it can distort utilization and availability. In a load-management context, bad telemetry can interfere with how operators understand capacity, faults, and charging behavior.
Depending on implementation, attackers may also receive commands intended for a real charger or attempt to trigger state transitions the backend accepts as legitimate. The advisory language points to unauthorized access, unauthorized actions, privilege escalation, and possible compromise of the broader system. Those phrases should be read carefully: they describe risk potential, not necessarily a public proof that every downstream action is exploitable in every deployment.
The practical takeaway for defenders is not to assume that “charger spoofing” is harmless because it does not begin with shell access. Modern infrastructure systems are controlled by messages. If the wrong party can participate in the message flow, security has already lost a major battle.
That matters because EV charging procurement has often emphasized uptime, payment integration, roaming, hardware compatibility, rebate eligibility, and deployment speed. Security requirements have sometimes been implied rather than tested. “Supports OCPP” is not the same as “supports OCPP securely.”
Buyers should now be asking sharper questions. Which OCPP security profiles are required by default? Are insecure profiles disabled unless explicitly approved? Are charger credentials unique per device? Is mutual TLS supported end to end? Can the operator see which chargers are still on weak profiles?
Those questions belong in RFPs, not just incident response meetings. A CSMS that can support Profile 3 but is populated with legacy chargers stuck on Profile 0 is not a Profile 3 environment. It is a mixed-trust environment with a security ceiling set by the devices that cannot move.
This is familiar to Windows administrators who have lived through years of protocol hardening. Support for SMB signing, LDAP channel binding, or modern authentication does not protect an estate if legacy exceptions remain broadly enabled. The feature exists; the deployment decides whether it matters.
But monitoring only works if someone is accountable for the signal. A CSMS can log security events and flag them for operational review, but an alert that disappears into a queue is not a control. Operators need escalation paths, retention policies, and a clear understanding of what constitutes an emergency versus a field-service nuisance.
Unexpected IP changes are a good example. In cellular or dynamic network environments, legitimate chargers may appear from changing addresses. In static depot networks, the same behavior may be suspicious. The platform can flag the event, but the operator needs context.
Rate limiting at the WebSocket gateway layer is similarly useful but bounded. It can reduce denial-of-service pressure from repeated connection attempts and slow brute-force or enumeration behavior. It does not authenticate a device; it simply makes abuse noisier, slower, and easier to block.
Defense in depth is not a slogan here. It is the only realistic bridge between legacy chargers and a stronger future state.
There is no universal answer. A charger inside a controlled depot serving a private fleet has a different risk profile from a public charger reachable across the open internet. A charger behind a tightly managed private network is not the same as one exposed through a broad cloud endpoint with predictable identifiers.
Still, the policy cannot be purely cosmetic. It should identify unsupported EVSE models, classify their risk, and create migration plans with site operators. EVoke’s stated approach points in that direction, but the pressure will be on execution.
The most mature operators will treat weak-profile chargers as exceptions with compensating controls and deadlines. They will isolate them, monitor them, restrict which network paths can reach the CSMS, and plan replacement. The least mature will treat server-side allow-listing as enough and hope obscurity does the rest.
Hope is not a security profile.
The Windows world has spent years unwinding that pattern across authentication protocols, macro behavior, remote administration, print services, directory integrations, and management agents. The hardest part is rarely adding the secure option. The hardest part is removing the insecure option without breaking production.
That is exactly the tension EVoke is describing. Its CSMS supports all OCPP security profiles, including stronger ones. But charger firmware, OEM support, and deployed hardware determine what can actually be enforced. The result is a compatibility matrix masquerading as a security posture.
For sysadmins, the lesson is direct. If your organization operates EV chargers, do not treat them as facilities equipment outside IT’s concern. They are networked endpoints, with identities, protocols, credentials, firmware, logs, and vendor dependencies. They belong in asset inventory and risk management.
They also belong in tabletop exercises. If a charger identity is spoofed, who notices? If a backend begins rejecting duplicate connections, who gets paged? If a firmware upgrade bricks a public charger, who owns the rollback? Those are operational questions before they are technical ones.
Network placement matters. OCPP endpoints should not be casually reachable from the public internet without strong authentication and filtering. Where remote access is necessary, operators should use network controls that reduce who can reach the WebSocket gateway in the first place.
The CSMS should enforce per-device identity as tightly as the installed base allows. Unique credentials are better than shared ones. Certificates are better than passwords where devices support them. Unknown charger identifiers should be rejected, and duplicate identities should trigger investigation.
Logs should be treated as security telemetry, not just operational records. Repeated connection attempts, impossible geography, sudden IP churn, and odd message sequencing can indicate abuse or failing equipment. Either way, operators need to know.
The long-term answer is procurement discipline. New chargers that cannot support modern authentication should be nonstarters. Existing chargers that cannot be upgraded should be placed on a replacement path, not granted permanent exception status because they still deliver kilowatts.
The EV charging sector is moving from build-out mode to infrastructure mode, and infrastructure mode is less forgiving. The next generation of charging networks will not be judged only by how many plugs they deploy or how quickly drivers can start a session. They will be judged by whether each charger can prove what it is, whether each backend refuses impostors by default, and whether the industry can retire legacy trust before attackers turn it into routine tradecraft.
EV Charging Security Has Reached the Boring-but-Dangerous Phase
The uncomfortable part of this advisory is that nothing about it sounds exotic. There is no baroque exploit chain, no speculative side channel, no nation-state-only technique buried in firmware. The failure mode is painfully familiar: a service accepts a network connection, trusts an identifier too much, and gives the other side more authority than it has earned.In the EV charging world, that “other side” is not a browser or a mobile app. It is a charger talking to a Charging Station Management System, or CSMS, over the Open Charge Point Protocol. That backend is where operators monitor chargers, sessions, meter values, availability, faults, and sometimes remote actions.
The advisory lands because the trust boundary is wrong. If an attacker can connect to the OCPP WebSocket endpoint using a charger identifier and the system does not properly prove that the connecting device is the real charger, the backend can be tricked into treating an impostor as infrastructure.
That is why this is more than a data-integrity issue. Charging networks sit at the intersection of billing, fleet operations, energy management, public infrastructure, and physical equipment. A fake charger session is not just a weird log line; it can become a bad operational decision.
The WebSocket Is the Front Door, Not Plumbing
For many readers, “WebSocket endpoint” sounds like implementation detail. In this case, it is the front door. OCPP commonly uses WebSockets so charging stations can maintain an ongoing bidirectional conversation with the central system rather than periodically polling over a simpler request-response channel.That architecture makes sense. Chargers need to report status changes, receive commands, send meter values, start and stop transactions, and recover from unreliable connectivity. A persistent channel is a practical fit for a field device that may spend years bolted to concrete and managed remotely.
But a persistent channel also concentrates trust. Once a charger is accepted as a valid participant, the backend may process messages as though they come from real hardware. If the connection is authenticated weakly or not at all, the protocol becomes an identity costume: wear the right charger ID, and the system may let you into the conversation.
That is the advisory’s core warning. EVoke’s platform supports multiple OCPP security profiles, but the effective security posture depends on what the deployed charger firmware can actually use. In mixed fleets, the weakest chargers tend to define the real-world attack surface.
OCPP’s Compatibility Bargain Comes Due
EVoke’s statement is revealing because it is not the classic vendor line of “upgrade to version X and move on.” The company says its platform is hardware-agnostic and must interoperate with charger OEMs that support different OCPP security profiles depending on firmware capability. That is the reality of EV charging: the network is not one product, one version, one release train.OCPP Security Profiles exist precisely because the industry has had to move from basic connectivity toward stronger authentication and encryption. Profile 0 and Profile 1 belong to an earlier era of trust assumptions. Profile 2 adds TLS encryption with basic authentication, while Profile 3 moves toward mutual TLS with client certificates.
That progression is easy to endorse on paper. In the field, it collides with hardware lifecycles, stranded firmware, OEM exits, and site operators that bought chargers years before stronger authentication became table stakes. EVoke says some legacy chargers on its network only support Security Profile 0 or 1, and some models are no longer supported by their manufacturer.
This is the real vulnerability class: not merely “a vendor forgot auth,” but “an ecosystem made unauthenticated or weakly authenticated device identity operationally normal for too long.” CSMS vendors can build stronger doors, but if customers need to keep old locks in service, the front door still has to open for them.
The Vendor Fix Is Really a Fleet Segmentation Problem
EVoke says it is working with charger OEM partners to migrate supported devices to Security Profile 2 or 3, prioritizing firmware upgrades where OEMs still provide them. That is the right direction, but it is not instant remediation. It requires device inventory, firmware qualification, operator scheduling, rollback planning, and proof that chargers actually reconnect under the stronger profile.For unsupported legacy chargers, EVoke is moving to server-side protections. The platform will only accept charger IDs registered in its CSMS inventory database and reject unknown identifiers. That is a necessary baseline, but it should not be confused with cryptographic identity.
An allow-list tells the server that a claimed charger ID is one the operator recognizes. It does not, by itself, prove that the connecting endpoint is the physical charger assigned that identity. If the identifier can be guessed, leaked, scraped from documentation, observed in traffic, or inferred from naming conventions, allow-listing narrows the blast radius but does not solve impersonation.
The additional mitigation of allowing only one active connection per charger ID is more interesting operationally. It blocks a common spoofing pattern in which the real charger and the fake charger coexist. If a second connection appears, the system can reject it or terminate the previous session.
That control turns impersonation into an event rather than silent parallel occupancy. It gives defenders something to log, alert on, and investigate. Still, it creates hard choices: terminate the older session and you may knock a legitimate charger offline; reject the newer session and you may miss a real reconnection after a network flap.
Legacy Chargers Are Becoming the Windows XP Machines of the Grid Edge
Every industry eventually discovers its Windows XP problem. A device keeps working, its software stops improving, and its operational value outlasts its security model. EV charging is now meeting that problem in public view.The EVBox example in EVoke’s advisory response is exactly the kind of detail that makes asset owners wince. A charger may be physically functional and economically useful but unable to support modern OCPP security profiles because the manufacturer no longer supports the model. At that point, “patch management” becomes “replacement planning,” and replacement planning becomes a budget fight.
This is where IT and operational technology cultures often diverge. In enterprise IT, unsupported systems are risky but usually visible in inventories, vulnerability scanners, endpoint consoles, and procurement records. In charging infrastructure, the estate may be split among site hosts, network operators, charger OEMs, installers, payment providers, cloud services, and utility-facing integrations.
That fragmentation makes simple mandates harder. “Upgrade everything to mutual TLS” is technically correct and politically incomplete. Someone has to know which chargers can do it, which cannot, who owns the replacement cost, and what happens to service availability while the work is performed.
The uncomfortable lesson is that EV infrastructure has to inherit more of enterprise IT’s lifecycle discipline. Devices that cannot authenticate strongly cannot be treated as ordinary long-lived assets. They become exceptions, and exceptions require expiration dates.
Identity Is the New Perimeter for Charging Networks
The old perimeter model is nearly useless here. Chargers live in parking lots, garages, depots, retail sites, apartment complexes, and roadside locations. Their traffic may traverse commodity internet links, cellular networks, VPNs, private APNs, or a patchwork of local networking decisions made long after the charger was installed.That makes device identity the real perimeter. The backend has to know not just that a connection claims to be Charger-17, but that it is Charger-17, using credentials or certificates that cannot be trivially copied into a simulator. This is why the distinction between Profile 2 and Profile 3 matters.
TLS with basic authentication is a meaningful improvement over unauthenticated or weakly authenticated connections, particularly when credentials are unique and rotated. Mutual TLS is stronger because the charger presents a client certificate and the server can verify cryptographic identity during connection establishment. In an ideal deployment, a stolen ID string is useless without the corresponding private key.
But identity systems are operational systems. Certificates expire. Private keys need secure storage. Chargers need provisioning workflows. Field technicians need recovery paths. Backends need revocation, renewal, and inventory alignment.
That complexity is why weaker profiles persisted. It is also why they have to be retired deliberately rather than wished away.
Spoofing Is Not Just a Hacker Demo
A charger impersonation flaw invites dramatic scenarios, but the more plausible risks are mundane and still serious. An attacker who can connect as a charger may be able to send false status, transaction, or meter messages. The CSMS may then record inaccurate operational data or make wrong decisions based on a synthetic view of the network.In a billing context, that can affect session records and reconciliation. In a fleet context, it can distort utilization and availability. In a load-management context, bad telemetry can interfere with how operators understand capacity, faults, and charging behavior.
Depending on implementation, attackers may also receive commands intended for a real charger or attempt to trigger state transitions the backend accepts as legitimate. The advisory language points to unauthorized access, unauthorized actions, privilege escalation, and possible compromise of the broader system. Those phrases should be read carefully: they describe risk potential, not necessarily a public proof that every downstream action is exploitable in every deployment.
The practical takeaway for defenders is not to assume that “charger spoofing” is harmless because it does not begin with shell access. Modern infrastructure systems are controlled by messages. If the wrong party can participate in the message flow, security has already lost a major battle.
CISA’s Advisory Is Also a Message to Buyers
CISA advisories do more than warn current operators. They shape procurement behavior. By putting this class of weakness into the industrial-control advisory stream, CISA is effectively telling the market that EV charging backends belong in the same risk conversation as other connected infrastructure.That matters because EV charging procurement has often emphasized uptime, payment integration, roaming, hardware compatibility, rebate eligibility, and deployment speed. Security requirements have sometimes been implied rather than tested. “Supports OCPP” is not the same as “supports OCPP securely.”
Buyers should now be asking sharper questions. Which OCPP security profiles are required by default? Are insecure profiles disabled unless explicitly approved? Are charger credentials unique per device? Is mutual TLS supported end to end? Can the operator see which chargers are still on weak profiles?
Those questions belong in RFPs, not just incident response meetings. A CSMS that can support Profile 3 but is populated with legacy chargers stuck on Profile 0 is not a Profile 3 environment. It is a mixed-trust environment with a security ceiling set by the devices that cannot move.
This is familiar to Windows administrators who have lived through years of protocol hardening. Support for SMB signing, LDAP channel binding, or modern authentication does not protect an estate if legacy exceptions remain broadly enabled. The feature exists; the deployment decides whether it matters.
Monitoring Is a Mitigation, Not a Cure
EVoke says it will monitor anomalies such as repeated connection attempts, unexpected IP address changes, and abnormal message patterns. That is sensible, especially in a world where not every charger can immediately be upgraded. Detection gives operators a way to see abuse attempts, misconfigurations, and suspicious reconnections.But monitoring only works if someone is accountable for the signal. A CSMS can log security events and flag them for operational review, but an alert that disappears into a queue is not a control. Operators need escalation paths, retention policies, and a clear understanding of what constitutes an emergency versus a field-service nuisance.
Unexpected IP changes are a good example. In cellular or dynamic network environments, legitimate chargers may appear from changing addresses. In static depot networks, the same behavior may be suspicious. The platform can flag the event, but the operator needs context.
Rate limiting at the WebSocket gateway layer is similarly useful but bounded. It can reduce denial-of-service pressure from repeated connection attempts and slow brute-force or enumeration behavior. It does not authenticate a device; it simply makes abuse noisier, slower, and easier to block.
Defense in depth is not a slogan here. It is the only realistic bridge between legacy chargers and a stronger future state.
The Hard Part Is Killing Profile 0 Without Killing Uptime
The most consequential line in EVoke’s response may be the promise of a lifecycle policy for legacy chargers that cannot support modern OCPP security profiles. That is where the advisory turns from vulnerability management into infrastructure governance. A lifecycle policy forces the question that every operator would rather defer: when does a working charger become too risky to keep online?There is no universal answer. A charger inside a controlled depot serving a private fleet has a different risk profile from a public charger reachable across the open internet. A charger behind a tightly managed private network is not the same as one exposed through a broad cloud endpoint with predictable identifiers.
Still, the policy cannot be purely cosmetic. It should identify unsupported EVSE models, classify their risk, and create migration plans with site operators. EVoke’s stated approach points in that direction, but the pressure will be on execution.
The most mature operators will treat weak-profile chargers as exceptions with compensating controls and deadlines. They will isolate them, monitor them, restrict which network paths can reach the CSMS, and plan replacement. The least mature will treat server-side allow-listing as enough and hope obscurity does the rest.
Hope is not a security profile.
Microsoft Shops Should Recognize the Pattern
WindowsForum readers have seen this movie before, just with different acronyms. A protocol begins life in a trusted environment. It becomes ubiquitous. Attackers learn to abuse assumptions that once felt reasonable. Vendors add stronger modes, but backward compatibility keeps weaker modes alive.The Windows world has spent years unwinding that pattern across authentication protocols, macro behavior, remote administration, print services, directory integrations, and management agents. The hardest part is rarely adding the secure option. The hardest part is removing the insecure option without breaking production.
That is exactly the tension EVoke is describing. Its CSMS supports all OCPP security profiles, including stronger ones. But charger firmware, OEM support, and deployed hardware determine what can actually be enforced. The result is a compatibility matrix masquerading as a security posture.
For sysadmins, the lesson is direct. If your organization operates EV chargers, do not treat them as facilities equipment outside IT’s concern. They are networked endpoints, with identities, protocols, credentials, firmware, logs, and vendor dependencies. They belong in asset inventory and risk management.
They also belong in tabletop exercises. If a charger identity is spoofed, who notices? If a backend begins rejecting duplicate connections, who gets paged? If a firmware upgrade bricks a public charger, who owns the rollback? Those are operational questions before they are technical ones.
The Practical Shape of a Safer Charging Estate
The near-term defensive posture is not mysterious. Operators should identify exposed OCPP endpoints, inventory charger models and firmware versions, determine which security profiles each charger actually uses, and prioritize movement to Profile 2 or Profile 3. They should also assume that charger IDs are not secrets unless proven otherwise.Network placement matters. OCPP endpoints should not be casually reachable from the public internet without strong authentication and filtering. Where remote access is necessary, operators should use network controls that reduce who can reach the WebSocket gateway in the first place.
The CSMS should enforce per-device identity as tightly as the installed base allows. Unique credentials are better than shared ones. Certificates are better than passwords where devices support them. Unknown charger identifiers should be rejected, and duplicate identities should trigger investigation.
Logs should be treated as security telemetry, not just operational records. Repeated connection attempts, impossible geography, sudden IP churn, and odd message sequencing can indicate abuse or failing equipment. Either way, operators need to know.
The long-term answer is procurement discipline. New chargers that cannot support modern authentication should be nonstarters. Existing chargers that cannot be upgraded should be placed on a replacement path, not granted permanent exception status because they still deliver kilowatts.
EVoke’s Advisory Turns Charger IDs Into a Board-Level Asset
The small details in this advisory add up to a clear operating model for the next phase of EV infrastructure security.- EVoke’s CSMS issue centers on insufficient authentication for OCPP WebSocket connections, which can let an attacker impersonate a charger if they can present a usable charger identifier.
- EVoke says stronger OCPP security profiles are supported by the platform, but actual protection depends on what each charger’s firmware and OEM support can handle.
- Legacy chargers limited to weaker profiles will need compensating controls such as inventory allow-listing, duplicate-session prevention, anomaly monitoring, and rate limiting.
- Unsupported charger models create a lifecycle problem, because devices that cannot be upgraded must eventually be isolated, replaced, or accepted as explicit risk exceptions.
- Operators should treat charger identity, firmware capability, and OCPP security profile as core asset-management data rather than niche protocol details.
- Future charger purchases should require modern authentication support by default, because backward compatibility is now a measurable security liability.
The EV charging sector is moving from build-out mode to infrastructure mode, and infrastructure mode is less forgiving. The next generation of charging networks will not be judged only by how many plugs they deploy or how quickly drivers can start a session. They will be judged by whether each charger can prove what it is, whether each backend refuses impostors by default, and whether the industry can retire legacy trust before attackers turn it into routine tradecraft.
References
- Primary source: CISA
Published: 2026-06-25T12:00:00+00:00
- Related coverage: thehackerwire.com
OCPP WebSocket Auth Bypass: Critical Station Impersonation – TheHackerWire
SummaryCVE-2026-25851, published February 27, 2026, details a critical authentication bypass vulnerability (CVSS 9.4) impacting WebSocket endpoints. This fla...www.thehackerwire.com
