Why may a connected car’s weakest point be outside the vehicle?
Modern connected-car cybersecurity extends far beyond the computer physically installed in the vehicle. A 2026 study of 413 recently reported automotive software vulnerabilities found a growing share in external-facing applications such as mobile apps, websites, telematics dashboards, cloud platforms and over-the-air update services. University of Gothenburg researchers said the proportion of risks found in apps, web services and cloud systems had tripled compared with the pattern seen roughly a decade earlier.
This shift matters because one car may communicate with a manufacturer’s servers, a driver’s phone, charging networks, navigation providers, insurers, repair systems and entertainment services. Each connection can improve convenience, but it also expands the attack surface. Securing the vehicle’s internal controllers is still essential; it is simply no longer sufficient. Manufacturers must protect the entire software supply chain, and owners should treat the car account and companion app as security-sensitive systems.
The research in brief
- Researchers analyzed 413 automotive software vulnerabilities reported between 2022 and 2024.
- They scanned 20 automotive software repositories and identified 827 vulnerable libraries.
- Nearly 45 percent of the analyzed vulnerabilities were classified as high severity.
- External apps, APIs, cloud services and update infrastructure are taking a larger share of risk.
- Security must cover development tools, third-party packages and backend systems as well as in-car components.
What makes a modern car a connected ecosystem?
A contemporary vehicle contains dozens of electronic control units responsible for functions such as power management, braking, steering, airbags, infotainment and driver assistance. These internal computers exchange information across vehicle networks. Telematics modules connect some of those systems to cellular networks, satellites, Wi-Fi, Bluetooth and external services.
The ecosystem continues outside the chassis. A mobile app may unlock doors, locate the car, start climate control or manage charging. Cloud services store account data, process diagnostics and deliver over-the-air updates. Dealers and service centers use portals that access vehicle records. Charging points, traffic systems and fleet platforms add further connections.
This architecture creates a chain of trust. If a weak web API accepts unauthorized commands, the attack starts in a cloud service even though the visible result may occur in the car. If a supplier account is compromised, malicious code can enter a build or update pipeline. Defenders therefore need to map data and privileges across organizational boundaries, not only test individual components.
Which connected-car attack surfaces are most important?
Mobile apps and web portals are prominent because they face the public internet and often expose useful remote functions. Common weaknesses include broken authentication, insecure password recovery, excessive API permissions, leaked credentials and insufficient rate limits. An attacker may not need to compromise the car directly if the manufacturer’s backend accepts a fraudulent request as legitimate.
Over-the-air updates are another critical area. Secure updates let manufacturers repair defects quickly, but the system must authenticate software, protect signing keys, prevent rollback to vulnerable versions and recover safely from interruption. A compromised update channel can distribute risk at fleet scale.
Third-party libraries create supply-chain exposure. Automotive software reuses operating systems, web frameworks, cryptographic libraries, containers and monitoring tools. A known flaw in one dependency may affect many products. The study’s scan of 20 repositories found 827 vulnerable libraries, illustrating why a current software bill of materials is operationally important.
| Layer | Typical exposure | Primary defense |
|---|---|---|
| Mobile app | Account takeover, token leakage, unsafe local storage | Strong authentication, secure storage and short-lived tokens |
| Cloud API | Unauthorized vehicle commands or data access | Object-level authorization, validation, monitoring and rate limits |
| OTA update service | Malicious or outdated software delivery | Cryptographic signing, rollback protection and protected keys |
| Infotainment and telematics | Untrusted media, wireless connections and external messages | Sandboxing, isolation and strict input validation |
| Development pipeline | Compromised packages, tools or build credentials | SBOMs, signed builds, scanning and least privilege |
| Service and fleet portals | Broad access through stolen staff accounts | Multi-factor authentication, scoped roles and audit logs |
How can an app or cloud flaw affect physical safety?
Not every cloud vulnerability can control safety-critical functions. Good architecture separates external services from braking, steering and other essential controllers. The concern is that complex integrations can create indirect paths. A backend may send commands to a telematics unit, which communicates with other vehicle networks. Excessive privileges or poor isolation can turn an account or API failure into a more serious event.
Safety also includes privacy and availability. Location histories can reveal home, workplace, medical visits and daily routines. Ransomware against a supplier or manufacturer can interrupt production, service scheduling or parts logistics. A vulnerable charging or fleet platform can strand users even without manipulating a moving vehicle.
Risk assessment should trace the full path from an external input to its potential consequence. Engineers need to ask what the system can reach after the first compromise, what credentials it can obtain and whether network segmentation stops lateral movement.
What does the 2026 study reveal about software supply chains?
The research emphasizes that automotive software is not a single codebase written by one manufacturer. It combines supplier modules, open-source packages, cloud platforms, development tools and communication protocols. Vulnerabilities can enter during requirements, design, development, deployment or maintenance.
A software bill of materials, or SBOM, lists components and versions so teams can determine whether a newly disclosed flaw affects a product. The inventory must connect to an efficient patch process; a static document that no one monitors provides little protection. Teams also need to scan containers, firmware images, source repositories and build manifests because dependencies can hide in multiple places.
Transparency affects interpretation. A supplier that reports many vulnerabilities may have a large market footprint and a mature disclosure program, not necessarily worse security than a silent competitor. Useful metrics include patch time, recurrence, exploitability and the ability to identify affected vehicles—not raw counts alone.
What should automakers and suppliers do differently?
Security must begin with architecture. Infotainment and telematics should be isolated from safety-critical controllers, with gateways allowing only necessary, validated communication. Every external API needs authentication and object-level authorization so one customer cannot access another vehicle by changing an identifier. Sensitive commands deserve stronger confirmation than low-risk requests.
Development programs should combine threat modeling, code review, dependency scanning, fuzz testing and penetration testing. Build systems need protected credentials and reproducible, signed artifacts. Security teams must evaluate the cloud and mobile applications with the same seriousness as embedded firmware.
- Maintain an accurate inventory of software, services, owners and data flows.
- Use least privilege for apps, APIs, staff accounts and vehicle commands.
- Separate public-facing services from critical in-vehicle networks.
- Protect update signing keys in hardened systems and test recovery procedures.
- Monitor abnormal account, API and fleet behavior without collecting unnecessary personal data.
- Provide a clear vulnerability disclosure channel and patch supported vehicles promptly.
- Plan secure decommissioning so sold or retired cars do not retain old owner access.
Standards such as ISO/SAE 21434 and regulatory cybersecurity management requirements provide structure, but compliance should be the baseline rather than the finish line. Real systems evolve through updates, suppliers and new services, so security evidence must remain current.
How can drivers improve connected-car cybersecurity?
Owners cannot repair a manufacturer’s architecture, but they can reduce common account and device risks. Use a unique password for the car account and enable multi-factor authentication when offered. Protect the connected phone with a current operating system, screen lock and remote-wipe capability. Install vehicle and companion-app updates from official channels rather than postponing them indefinitely.
Review which people and services have access. Remove previous drivers, expired fleet managers and third-party apps no longer needed. Before selling or returning a vehicle, follow the manufacturer’s ownership-transfer process, delete profiles, clear paired devices and confirm that remote access has moved to the new owner.
Be cautious with messages claiming an urgent account or charging problem. Open the official app directly instead of following a link. If the vehicle behaves unexpectedly, the app shows an unfamiliar user or location data appears exposed, preserve evidence and contact the manufacturer through a verified channel. Browse DataSecurity resources and our guide to understanding cyber attacks for broader protective habits.
What information should car buyers ask for?
Software support is becoming part of vehicle longevity. Buyers should ask how long security updates are guaranteed, whether updates require a dealer visit, which features depend on cloud subscriptions and what happens when services close. A car may remain mechanically sound after its digital ecosystem reaches end of support.
Privacy documentation should explain what location, driving, voice and diagnostic data is collected; who receives it; how long it is retained; and how the owner can delete it. Vague statements such as “data may improve services” are less useful than specific purposes and controls. Fleet buyers should additionally ask about role-based access, logging, integration security and incident notification.
Frequently asked questions about connected-car security
Can hackers remotely control every connected car?
No. Capabilities vary widely, and manufacturers use different network separation and command controls. Connectivity creates potential paths, but a vulnerability’s actual impact depends on architecture, permissions and exploitability.
Are electric vehicles more vulnerable than fuel-powered cars?
Connectivity and software architecture matter more than propulsion type. Electric vehicles often have extensive apps and update features, while modern combustion vehicles may use similar telematics and cloud services.
Should drivers disable all connected features?
Not necessarily. Connectivity can deliver safety fixes, diagnostics and useful services. Drivers should disable unneeded sharing, secure accounts and keep supported software updated rather than assuming disconnection is always possible or safer.
What is the most important action for an owner?
Protect the manufacturer account with a unique password and multi-factor authentication, then keep both the vehicle and companion app updated. Account takeover is a preventable route to sensitive data and remote functions.
What happens when a connected car is sold?
The seller should remove profiles, phones, garage codes and app access and complete the official ownership transfer. The buyer should confirm that no previous user remains authorized before enabling remote services.
The practical takeaway on connected-car cybersecurity
Why does the software support horizon matter?
Vehicles commonly remain on the road longer than phones and many cloud products. If a manufacturer ends security support while remote services still operate, known vulnerabilities can accumulate in a product that owners reasonably expect to use for years. Manufacturers should publish minimum support periods before purchase, separate safety updates from optional subscriptions and provide a secure reduced-function mode when a backend is retired. Regulators and fleet buyers can encourage longer support by treating update commitments as part of safety and procurement. Owners should know whether discontinued connectivity will disable convenience features only or affect charging, keys, diagnostics or essential operation.
A connected car should be secured as an ecosystem, not a sealed machine. Apps, cloud APIs, suppliers, update systems and development tools can become the first point of failure even when internal vehicle software is well protected. Manufacturers need isolation, strong authorization, accountable supply chains and durable update support. Drivers need secure accounts, current software and careful ownership transfers. The research’s most useful lesson is architectural: when the car depends on services outside itself, safety and privacy depend on those services too.
