TL;DR: Electric vehicle cybersecurity now spans the vehicle, charger, mobile app, and cloud backend, and Finite State argues that the most reliable defense starts with visibility into the software actually shipped across that ecosystem. The lesson for practitioners is that reachability and inventory matter more than broad vulnerability counts when the attack surface includes third-party code, connected chargers, and remote commands.
At a glance
What this is: This analysis says EV security is an ecosystem problem, not just a car problem, because vulnerabilities in the vehicle, charger, app, and cloud can all be exploitable.
Why it matters: It matters to IAM and broader security teams because connected vehicles depend on credentials, remote access, and software trust boundaries that behave like identity and supply-chain controls.
By the numbers:
- Global electric car sales grew about 20% in 2025 to top 20 million, according to the IEA.
- Electric cars reached a 25% share of the world car market, according to the IEA.
Context
Electric vehicle cybersecurity is the discipline of protecting the vehicle, its charging equipment, its mobile app, and the cloud services that connect them. Once those layers are networked together, the security boundary is no longer the chassis alone but the full software and identity chain that controls charging, commands, updates, and data.
For practitioners, the governance problem is visibility. If teams cannot inventory shipped firmware, third-party software, and remotely reachable services across the vehicle and charger, they cannot reliably decide what is actually exploitable. The identity intersection is real here: remote commands, API tokens, app authentication, and charger management access all shape the attack surface.
This is typical of modern connected-product risk, but EVs add physical consequences and a much wider blast radius when chargers, fleets, and backend platforms are shared.
Key questions
Q: What breaks when EV cybersecurity does not cover chargers and cloud backends?
A: Security fails at the ecosystem boundary. A vehicle may be well protected while a charger, mobile app, or backend token remains exploitable, giving attackers a path to remote commands, telemetry, or network pivoting. The practical result is that the least governed component becomes the entry point for the entire connected vehicle stack.
Q: Why do third-party apps create so much risk in connected vehicles?
A: Third-party apps often sit close to remote commands, telemetry, and authentication flows, so they inherit trust that is broader than their original purpose. If those apps leak tokens or expose weak access controls, an attacker can manipulate vehicle data or functions without compromising the manufacturer’s core software. Governance has to extend to every delegated integration.
Q: What signs show that EV vulnerability management is missing the real risk?
A: The clearest signs are large vulnerability lists with no exploitability ranking, missing firmware provenance, and no distinction between reachable and unreachable flaws. If teams cannot say which component is shipped, which version is live, and which issue can actually be triggered, they are managing inventory noise rather than exposure.
Q: How should fleet operators govern charger access and remote commands?
A: They should treat charger access, remote commands, and backend administration as privileged pathways that need scoping, segregation, and review. Shared depots and central consoles expand blast radius, so the governance question is who can issue commands, from where, and through which authenticated channel. That is an access-control problem as much as an operational one.
Technical breakdown
Why EV attack surface now extends beyond the vehicle
An EV is not a single embedded system. It is a distributed system of electronic control units, infotainment, telematics, the mobile app, cloud services, and charging equipment, all of which exchange data and sometimes authority. That means compromise can begin in a third-party app, a cloud token, or charger firmware and still affect vehicle functions. In identity terms, remote trust is being extended across multiple systems that were not originally designed as one security domain. The technical problem is less about one critical flaw than about too many connected trust edges.
Practical implication: Map every remotely reachable component and treat each trust edge as an access-control boundary.
How charger firmware and protocols create exploitable paths
Charging stations are embedded computers with networking, firmware, and protocol stacks of their own. They commonly speak OCPP to management systems and may also use Bluetooth, Wi-Fi, or vehicle-to-charger protocols such as ISO 15118. Each interface is a place where authentication, update integrity, or memory-safety failures can expose code execution or network pivoting. The charger is often the weakly governed identity between the vehicle and the wider network, which is why a charger compromise can become a foothold rather than a local nuisance.
Practical implication: Inventory charger firmware and lock down protocol authentication before treating chargers as trusted infrastructure.
Why software inventory and reachability are the control points that matter
The article’s core technical argument is that exploitability depends on what is actually shipped and reachable, not on abstract vulnerability counts. A ground-truth software bill of materials links firmware components to known flaws, while reachability analysis filters out issues that cannot be triggered in the deployed architecture. For connected vehicles, that is especially important because suppliers, open-source packages, and over-the-air update paths multiply the number of places where hidden exposure can persist. Without those controls, remediation becomes guesswork.
Practical implication: Build shipped-firmware inventories and prioritize only vulnerabilities that are reachable in the deployed EV and charger stack.
Threat narrative
Attacker objective: The attacker wants to gain remote influence over vehicle functions, charging operations, or connected data paths without touching the car’s primary safety systems directly.
- Entry often begins through a third-party app, exposed charger interface, or weakly authenticated update path rather than the vehicle core itself.
- The attacker then abuses firmware, tokens, or protocol weaknesses to gain control of the charger, app session, or remote command channel.
- From there, the attacker can pivot into nearby systems, disrupt charging, or reach vehicle data and management functions.
- The end state is remote vehicle control, service disruption, or fleet-scale exposure across shared chargers and management platforms.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
EV security is now an identity and software-supply-chain governance problem, not only a hardware problem. The article shows that remote access, app trust, charger management, and backend authentication all create authority outside the vehicle itself. That means the security boundary is defined by software provenance and access governance as much as by physical design. Practitioners should treat EV ecosystems as federated trust environments.
Shipped-software visibility is the named concept that separates effective EV security from reactive vulnerability management. A team that cannot inventory the exact binaries, firmware, and third-party packages in the vehicle and charger cannot decide what is reachable, exploitable, or safe to patch. This is where the identity angle matters: remote commands and management channels depend on credentials and authenticated trust paths. Practitioners should make ground-truth inventory a control objective, not a reporting exercise.
Shared charging infrastructure creates blast-radius risk that fleet governance often underestimates. One compromised charger, token, or management platform can affect many vehicles at once because the operational model is centralized. That makes segmentation, access scoping, and supplier assurance part of resilience, not just hygiene. Practitioners should re-evaluate how much shared access they allow across depots, apps, and charger backends.
EV cybersecurity is drifting toward safety-critical governance as autonomy increases. As more vehicle functions depend on software and remote connectivity, cyber compromise can cross into physical harm and operational disruption. That raises the standard for evidence, lifecycle control, and verified remediation. Practitioners should align EV programs with engineering assurance, not just incident response.
Reachability should replace raw vulnerability count as the decision metric for EV remediation. Counting CVEs without knowing whether they are actually triggerable in shipped firmware produces noise and delay. The practical conclusion is that teams should prioritize what can be exploited in the field, especially where the same flaw exists in many deployed chargers or vehicles.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Vulnerability Management Guide
What this signals
Shipped-software visibility is becoming the practical dividing line between EV programs that can remediate exposure and those that only count it. When the security team can tie firmware, supplier packages, and charger versions back to deployed assets, reachability analysis becomes usable and the backlog becomes defensible.
Fleet operators should expect charger governance to look more like privileged access management than traditional device maintenance. Shared charging infrastructure concentrates trust, so a single access path can affect many vehicles if command channels and backend rights are not tightly scoped.
The identity problem is real even in a vehicle-security article: remote commands, app sessions, and charger administration depend on authentication and delegated trust. Programs that do not govern those paths as high-risk access will keep rediscovering the same exposure in a different form.
For practitioners
- Build a shipped-firmware inventory Create a ground-truth SBOM from the firmware and binaries actually deployed in the vehicle and charger, including supplier and open-source components.
- Separate charging networks from enterprise systems Segment EVSE management traffic, charger administration, and remote command paths so a compromised charger cannot pivot into unrelated infrastructure.
- Review third-party app and token trust Audit every mobile app, data logger, and remote-service token that can issue vehicle or charging commands, then revoke anything that is not explicitly needed.
- Prioritize only reachable vulnerabilities Use reachability analysis to suppress flaws that cannot be triggered in the deployed architecture and focus remediation on exploitably exposed firmware and services.
- Demand supplier evidence for charger security Require suppliers to show update integrity, authentication design, and component provenance for chargers and backend services before approving fleet-wide rollout.
Key takeaways
- EV cybersecurity depends on governing the whole connected ecosystem, not only the car’s internal electronics.
- The article’s central evidence is that attackers already exploit third-party apps, charger firmware, and open-source components, not just vehicle software.
- The most actionable control is ground-truth inventory paired with reachability analysis, because that shows what is actually exploitable in the field.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party apps, supplier code, and backend tokens expand EV trust chains. |
| Recommendation — Inventory and govern third-party trust paths before they become the weakest link. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | The article’s core control is a complete inventory of shipped firmware and connected assets. |
| Recommendation — Inventory every shipped EV and charger component so exposure decisions rest on known assets. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Shipped software, third-party components, and firmware versions must be known to manage risk. |
| Recommendation — Track installed software and firmware versions across vehicles and chargers before remediation. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Reachability analysis makes remediation of exploitable flaws a prioritised control issue. |
| Recommendation — Use flaw remediation controls to focus on reachable issues in deployed EV systems. | ||
| MITRE ATT&CK | TA0001;TA0006;TA0008 — Initial Access; Credential Access; Lateral Movement | The article describes app, token, and charger paths that can lead to broader compromise. |
| Recommendation — Map EV attack paths to credential access and lateral movement to improve detection planning. | ||
Key terms
- Ground Truth SBOM: A ground truth SBOM is the component inventory derived from the shipped binary or final release artefact, not from design intent alone. It captures what was actually compiled and packaged, which makes it more reliable for vulnerability triage, version matching, and compliance evidence.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Charging Station Attack Surface: Charging station attack surface is the collection of ways an EV charging point can be abused, including network protocols, card readers, USB ports, and backend integrations. Because charging stations connect physical infrastructure to digital systems, weaknesses can expose billing data, user information, or access paths into larger environments.
- Fleet-wide Blast Radius: The number of devices or services affected when one shared control fails. In endpoint governance, blast radius is the practical measure of how much operational damage a single update, policy error, or compatibility issue can create.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore it if your programme needs stronger control over credentials, delegated access, and machine identity governance.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org