EV Charging Cybersecurity in India: Risks and Safeguards (2026)

Short answer: an EV charger is not an appliance. It is an internet-connected computer that handles payments, holds customer data, sits physically unattended in public, and draws significant power from the grid. That combination creates a security surface most operators never assess, and the consequences of ignoring it range from revenue theft to grid disruption.

This guide covers the actual attack surfaces, what they cost when exploited, and the safeguards worth demanding from vendors.

Why charging infrastructure is an unusual target

Most connected devices carry one or two risk categories. Charging stations carry several simultaneously, which is what makes them worth thinking about seriously.

They process payments. That places them in the same regulatory and criminal-interest category as any payment terminal.

They hold personal data. User identity, vehicle details, location history and charging patterns. Under India's data protection framework, that carries legal obligations.

They are physically accessible. Unlike a server in a locked room, a public charger sits unattended on a forecourt where anyone can approach it, open panels, or connect to ports.

They control significant electrical load. A compromised fleet of chargers could be commanded to draw or drop power simultaneously, which is a grid stability concern rather than merely a commercial one.

They are managed remotely at scale. A single compromised management platform potentially affects every charger connected to it, which turns a small vulnerability into a large incident.

Few other categories of infrastructure combine payment processing, personal data, physical exposure, grid interaction and centralised control in one device.

The main attack surfaces

The charger itself

Physical access opens several routes. Exposed service ports allow direct connection to internal systems. Default or shared credentials, still distressingly common, allow configuration access. Firmware that can be modified without signature verification allows persistent compromise. Unsecured internal wiring can permit metering manipulation.

The mitigations are unglamorous: tamper-evident enclosures, no exposed service ports in public-facing units, unique credentials per device, and signed firmware that the hardware refuses to run if unsigned.

The communication layer

Chargers talk to management platforms continuously, usually over OCPP. Where that communication is unencrypted, it can be intercepted or manipulated. Where the charger does not verify the identity of the server it connects to, it can be redirected to an attacker's platform.

This is the surface most often left weak, because a charger works perfectly well without encryption and the deficiency is invisible in normal operation. Insist on TLS for all charger-to-platform communication, with proper certificate validation rather than blind trust.

The management platform

The highest-value target, because it controls everything connected to it. Compromise here potentially means the ability to alter pricing, disable chargers, extract the entire customer database, or manipulate power delivery across a network.

Platform security is largely conventional application security: strong authentication for operator accounts, mandatory multi-factor authentication for administrative access, role-based permissions so a support user cannot alter firmware, audit logging of privileged actions, and regular independent penetration testing.

Payment and authentication

RFID cards using older, cloneable technologies allow session theft. Weak account systems permit credential stuffing. Poorly implemented payment flows can be manipulated to obtain energy without a completed transaction.

Where RFID is used, choose technologies with cryptographic authentication rather than a readable static identifier. For app-based access, standard account security practice applies, including rate limiting and anomaly detection on session initiation.

The vehicle interface

Charging is not a passive power connection. The vehicle and charger exchange data, and in more advanced scenarios including plug-and-charge authentication, that exchange carries identity and payment information. This surface is less exploited today but grows in importance as smart charging and vehicle-to-grid capability spread.

What actually goes wrong

Translating abstract risk into the outcomes operators care about:

Revenue theft. Cloned authentication tokens, manipulated sessions or altered metering mean energy delivered without payment. Usually discovered late, through reconciliation discrepancies rather than alarms.

Service disruption. Chargers taken offline maliciously, or a platform rendered unavailable. Revenue stops, drivers are stranded, and reputational damage exceeds the direct loss.

Data breach. Customer identity, location and payment information exposed. This is now a legal matter in India, not only a reputational one, with notification obligations and potential penalties.

Pricing manipulation. Altered tariffs, either to steal energy cheaply or to damage an operator's reputation by overcharging customers.

Grid impact. The systemic concern. Coordinated manipulation of many chargers simultaneously could create load events that affect distribution stability. This is why charging infrastructure increasingly attracts attention as critical infrastructure rather than as retail equipment.

Physical safety. Manipulating charging parameters beyond safe limits is a hardware-protection question as much as a software one, which is why safety limits should be enforced in the charger's own firmware rather than only by the platform instructing it.

Data protection obligations in India

Charging operators collect personal data, and India's data protection regime imposes real obligations on that collection.

The practical implications include collecting only what is genuinely needed for the service, being clear with users about what is collected and why, obtaining valid consent where required, securing the data appropriately, retaining it only as long as necessary, and being able to respond to user requests about their own data.

Location and charging history deserve particular care. Charging records reveal where someone was and when, at a granularity that is genuinely sensitive. Treating this as ordinary business telemetry underestimates both the legal exposure and the reputational risk.

Operators should also be clear about the boundary between aggregate analytics, which have legitimate planning value, and individual behavioural data, which carries obligations. Monetising the latter is a risk that rarely justifies the return.

What to demand from vendors

Security questions rarely feature in charger procurement, which is precisely why they are worth asking. A short list that separates serious suppliers from the rest:

• Is charger-to-platform communication encrypted with TLS, and does the charger validate the server certificate?
• Is firmware signed, and does the hardware refuse unsigned updates?
• Are credentials unique per device, or shared across the product line?
• How are security patches delivered, how quickly, and are they included?
• Has the platform undergone independent penetration testing, and when?
• Is multi-factor authentication available and enforceable for administrative accounts?
• What is the disclosure process if a vulnerability is found?
• Where is customer data stored, and who can access it?
• Are safety limits enforced in charger firmware independently of platform instructions?
• What logging exists, and can we access it?

Vague answers here predict how the vendor will behave during an actual incident.

Security for site hosts and small operators

Much security guidance assumes a large network operator with a dedicated technology team. Most Indian charging installations are nothing like that: a hotel with four points, a society with a handful, an office with a dozen. The relevant advice is different.

Your platform vendor carries most of the burden, which makes vendor selection the security decision. A host with six chargers is not going to run penetration tests; they are relying on whoever built the platform to have done so. Asking about it before purchase is therefore the highest-value action available.

The risks you control directly are mundane. Default passwords left unchanged. Administrative accounts shared between staff. Chargers on the same network as your billing or booking systems. Physical access to units left unrestricted. None of these require expertise to fix.

Know what happens if the platform goes down. Can chargers operate in a degraded local mode, or do they simply stop? For a residential building where people depend on charging overnight, this matters more than it sounds.

Understand who holds your customer data. If you are a society or an employer, resident and staff charging records are personal data you are responsible for even when a vendor stores them. Know what is collected and where it lives.

Keep the vendor relationship live. Firmware updates that require someone to approve them will not happen if nobody at the site owns the relationship. Name a person.

Practical measures for operators

• Change every default credential before a charger goes live. This remains the most exploited weakness in connected devices generally.
• Segment the network. Chargers should not sit on the same network as business systems.
• Keep firmware current. Deferred updates accumulate known, published vulnerabilities.
• Monitor for anomalies. Unusual session patterns, repeated failed authentications and unexpected configuration changes are early indicators.
• Reconcile energy against revenue regularly. Discrepancies are often the first visible sign of session theft.
• Restrict physical access. Locked enclosures, tamper detection, and cameras covering the units.
• Limit administrative accounts and review them when staff change roles.
• Have an incident plan covering who is contacted, how chargers are isolated, and what obligations are triggered.

Building security into procurement

Security is far cheaper to specify than to retrofit, and charging hardware typically stays in service for many years. Decisions made at purchase therefore govern your exposure for a long time.

Write requirements into the tender. Encrypted communication, signed firmware, unique credentials and a defined patch commitment should appear as requirements rather than as questions asked afterwards. Suppliers respond to what is specified.

Ask for evidence, not assurances. A penetration test report, even a summary, tells you more than a claim of security. So does a documented vulnerability disclosure process, which indicates a supplier who has thought about what happens when something is found.

Establish the patch commitment explicitly. How long will this model receive security updates? Devices installed today may be running in a decade, and hardware that stops receiving patches becomes a liability rather than an asset.

Understand the data arrangement. Where is customer data stored, who processes it, who can access it, and what happens to it if you change platform or the vendor ceases trading? These questions have contractual answers or they have none.

Check the interaction with OCPP compliance. Open protocols help security by allowing you to move away from a vendor whose security practice deteriorates. Lock-in is a security risk as well as a commercial one, because it removes your ability to respond.

Operational security in practice

Beyond procurement, a small number of operational habits prevent most realistic incidents.

Maintain an inventory. You cannot secure devices you have lost track of. Know what hardware is deployed, on what firmware version, at which sites.

Patch on a schedule, not on incident. Deferred updates accumulate published vulnerabilities that are trivially exploitable once known.

Review administrative access regularly. Accounts belonging to former staff or former contractors are a persistent and mundane cause of incidents.

Log and retain. Without logs you cannot determine what happened, which matters both for remediation and for meeting notification obligations.

Rehearse the response. A written incident plan nobody has tested tends to fail on contact. Establish who decides to isolate chargers, who contacts customers, who assesses notification requirements, and how the network is operated meanwhile.

Treat physical and digital security together. Cameras, lighting and tamper-evident enclosures are part of the same problem, not a separate one, since physical access is the route to several of the digital attack surfaces described above.

Where the standards are heading

Security expectations for charging infrastructure are formalising, and specifying ahead of the requirement is cheaper than retrofitting to meet it later.

Internationally, newer protocol versions have brought security into scope directly, covering transport encryption, device identity and firmware integrity rather than leaving them to implementers. Regulatory attention is also increasing as charging networks grow large enough to matter to grid stability, which tends to bring critical infrastructure obligations with it.

In India, the data protection framework already imposes concrete obligations on anyone handling user information, and charging operators clearly qualify. Expectations around breach notification, consent and retention are becoming enforceable rather than advisory.

For an operator purchasing today, the practical conclusion is to specify equipment that already supports encrypted communication, signed firmware and per-device identity, even where nothing currently compels it. Hardware installed now will still be running when those expectations are requirements, and replacing a fleet of chargers to meet a standard is an expensive way to learn this lesson.

Key takeaways

• A charger combines payment processing, personal data, physical exposure and grid interaction in one unattended device.
• The communication layer between charger and platform is the most commonly neglected surface; insist on TLS with certificate validation.
• The management platform is the highest-value target because compromise scales across every connected charger.
• Revenue theft is usually discovered through reconciliation rather than alarms, so reconcile regularly.
• Charging records reveal location history and carry genuine data protection obligations in India.
• Ask vendors specific security questions during procurement; vague answers predict incident behaviour.
• Safety limits should be enforced in charger firmware, not only by the platform.

Security in charging infrastructure is still treated as an afterthought by much of the market, which is exactly why it is worth getting right. The measures above are neither exotic nor expensive; they are largely a matter of specifying them before purchase rather than discovering their absence afterwards.