Electric Car Security and the Risks Behind Connected Driving

What the BYD demonstration reveals about vehicle access, personal data and the systems behind the charging cable

A car can remember your home address, recognise your phone and respond to an instruction sent from somewhere else. Those features make ownership easier. They also make security part of the vehicle’s everyday operation, with consequences that can extend beyond a stolen account or an exposed file.

The recent BYD demonstration reported by ABC brought those consequences into view. Understanding a vehicle-security demonstration means examining both the visible result and the conditions that made it possible. That evidence should guide the questions owners ask and the protections manufacturers provide.

Our assessment is that electric-car security must cover the vehicle, its accounts, its software support and its charging services together. This article examines that wider system. Many of the risks also affect connected petrol and hybrid vehicles; electric propulsion adds a charging relationship, rather than making every EV equally vulnerable.

What the BYD demonstration actually established

In its 21 September investigation, ABC described tests involving a BYD Shark 6, a plug-in hybrid. The demonstrations included interference with lights, wipers, locks and the entertainment system, alongside location tracking and microphone access. ABC reported that the researcher could not access the brakes or cameras.

The research team’s 28 September technical clarification explains that software was installed with physical access before being controlled remotely. A separate physical connection to the internal vehicle network simulated a compromised electronic controller for the lights and wipers. The team used its own connectivity and did not access BYD’s online infrastructure.

The demonstrated effects therefore do not establish an internet-only compromise of an untouched vehicle or a breach of the manufacturer’s systems. They do show why access obtained locally can have consequences after the person who obtained it has left.

EVIDENCE CHECK: Ask how access was obtained before judging what remote control proves. A staged demonstration, a confirmed vulnerability and an attack against customers are different findings.

The security issue extends beyond the dashboard

A connected vehicle is a collection of computers and services with different responsibilities. The entertainment unit handles media and phone integration. Telematics provides remote communications. Electronic controllers operate vehicle functions. An owner account or fleet portal may sit outside the car altogether.

The US road-safety regulator’s guidance treats wired and wireless entry points as part of a layered security problem. Preventing entry is one layer; limiting consequences and recovering safely are others. A secure design has to consider what happens when a component fails or is compromised.

For a buyer, a useful question is therefore more specific than whether the car is connected: which functions can each connected component reach? Access to a screen should not automatically imply authority over propulsion, and permission to locate a vehicle should not automatically imply permission to change its configuration.

NHTSA’s 2022 technical recommendations call for isolation between wireless-connected components and low-level vehicle controls, strict filtering at gateways, and authenticated communications with external servers. In plain language, every connection needs a defined purpose and a limit.

THE SAFETY BOUNDARY: Assess the effect on the driver as well as the component involved. Interference with visibility or attention deserves scrutiny even when braking and steering remain protected.

A privacy problem does not require a dramatic takeover

Location histories can reveal routines, workplaces and frequently visited addresses. A shared account can create a different problem from a software flaw: someone may retain access because an owner, employer or previous user never removed it. Reviewing who has legitimate access belongs alongside reviewing whether unauthorised access is possible.

There is also a distinction between malicious intrusion and excessive collection by an authorised service. In January 2026, the US Federal Trade Commission finalised an order resolving allegations that a vehicle manufacturer and its connected-service subsidiary collected and sold location and driving-behaviour data without informed consent. The case illustrates why a privacy review must examine ordinary business practices as well as hackers.

Owners should be able to establish what is collected, why it is needed, how long it is retained and who can receive it. A claim that data is stored locally answers only one of those questions. It does not, by itself, explain access permissions, secondary uses or deletion procedures.

The FTC’s connected-rental-car advice also warns that pairing a phone can leave destinations, contacts and communication records in a vehicle. Drivers should grant only necessary permissions and remove their data before returning a rental. The same principle is useful when a company vehicle changes driver or a privately owned car is sold.

THE PRIVACY TEST: Could someone with access to your account or vehicle learn where you live, where you work or who you contact? Check the permissions and retention settings that make that possible.

Charging introduces another connected system

An EV charger can be part of a network that authorises users, manages sessions and communicates with an operator. The NIST profile for extreme fast charging considers four connected domains: vehicles, charging equipment, cloud or third-party operations, and utility or building networks. The profile is a risk-management resource, not a guarantee that a particular charger is secure.

The US Department of Energy identifies potential consequences including exposed user data and interrupted charging. For a delivery fleet, a charger outage could become missed journeys. For an individual driver, it could mean losing access to a planned charging stop. Those operational consequences matter even without any access to driving controls.

A compromised charger does not automatically mean a compromised battery, vehicle or electricity grid. Each wider consequence requires its own access path and failed protections. Operators should investigate what a compromised system can actually command, rather than assume that every connected component is equally reachable.

For a workplace installing chargers, the practical question is who owns security after installation. The facilities team may maintain the hardware while another party manages accounts and software. Contracts and operating procedures should make patching, access reviews, incident notification and recovery somebody’s explicit responsibility.

Updates need protection throughout the vehicle’s life

Remote updates can deliver fixes without a workshop visit, but the update mechanism itself carries authority. NHTSA’s recommendations include authenticating firmware changes, protecting software authenticity and integrity, and restricting attempts to install older vulnerable versions. Owners need a trustworthy update route; manufacturers need controls over what that route can distribute.

For procurement, ask for the support period and update process in writing. A car may remain in service through several owners, while accounts, applications and connectivity arrangements change. A support promise is more useful when it identifies the covered model, market and software components, and explains what happens when support ends.

International rules recognise this continuing responsibility. The UK Vehicle Certification Agency explains that UN Regulation 155 addresses vehicle cybersecurity management, while UN Regulation 156 addresses software updates and their management. Their processes include organisational responsibilities and assessment. Applicability depends on the relevant market, approval scheme and vehicle category; these are not universal guarantees that every vehicle is immune to attack.

BUYER’S QUESTION: Who will investigate a security issue, deliver the fix and confirm it reached this particular vehicle several years after purchase?

What owners and fleet operators should do now

1. Check accounts and access before adding more features

Use a unique password for the vehicle account and enable multifactor authentication where offered. Apply the same protection to its recovery email. Government account-security guidance explains why a second verification factor helps when a password is stolen. Review authorised drivers, active sessions and shared digital keys, using the manufacturer’s supported controls.

2. Confirm updates for the actual vehicle

Record the model, year and installed software version, then ask the authorised dealer about applicable updates or campaigns. An announcement that an update is planned is not confirmation that your vehicle has received it. Follow installation conditions in the owner’s instructions, and avoid unofficial software offered as an easy feature unlock.

3. Treat physical access as part of security

Know who services the vehicle and what devices are connected to it. The Department of Energy’s fleet guidance discusses tamper protection, restricting telematics access and securing remote endpoints. Fleet teams should record approved accessories and investigate unexplained equipment or configuration changes through qualified support.

4. Put charging and fleet administration under clear ownership

Keep an inventory of chargers, administrator accounts and support contacts. Separate charging administration from routine user access and arrange a recovery procedure for an unavailable service. The same fleet guidance recommends measures such as authenticated access and protected communications. For a small business, start by identifying who can change settings and who receives security alerts.

5. Make handover and incident reporting routine

When a vehicle changes hands, remove paired devices and saved destinations, revoke shared access and complete the manufacturer’s ownership-transfer process. Confirm that the new owner controls the account. For a suspected issue, record the time, software version and observed behaviour once safely parked, then contact the manufacturer or fleet manager. An unusual fault alone does not establish a cyberattack.

A 60 second check before connecting your phone

1. Check the vehicle. Is it yours, a rental or a shared company car, and who else can use its account?

2. Read the permissions. Approve only the information required for the feature you want to use.

3. Protect the phone. Keep it locked when unattended and review any voice-assistant access allowed while locked.

4. Plan the exit. Know how to remove the pairing and personal data before returning, selling or handing over the vehicle.

This is a quick privacy check, not a complete security assessment. It helps with everyday exposure while the manufacturer and service operators remain responsible for the systems under their control.

XYBER RESEARCH LAB ASSESSMENT

The central lesson is that vehicle security should be judged through demonstrated access, effective boundaries and sustained support. A useful assessment connects a finding to its prerequisites, the affected functions and the available remedy. It then asks whether the same conditions apply to the vehicle being purchased or operated.

For Xyber Research Lab, the useful focus is the complete ownership experience: who can access the account, what the vehicle retains, how software is maintained and whether charging remains available during an incident. Country of manufacture or powertrain alone cannot answer those questions. Buyers and fleet managers need evidence for the particular vehicle and services they will use.

Our conclusion is that cybersecurity belongs in the purchase, handover and maintenance process. Owners can reduce unnecessary exposure, but they cannot repair insecure vehicle architecture themselves. Manufacturers and operators must make protection and support understandable, testable and available throughout the life of the product.

The question to ask is specific: if one account, connected component or charging service were compromised, what could it reach, and how would that access be stopped safely?