Vehicle Cybersecurity and the Reality of Automotive Hacking

The Connected Car Is a Promise, and a Vulnerability

The modern car is no longer a closed mechanical system with a few electronic assistants. It is an always-on digital product with wheels, a product whose behavior is shaped as much by code and cloud services as by steel and torque. That shift has delivered real benefits: remote diagnostics, convenience features, predictive maintenance, over-the-air improvements, and the steady movement toward safer driver assistance. But it has also produced a new reality that many drivers still underestimate and many executives still prefer not to discuss in plain language: cars are now attackable at scale.

This is not alarmism, and it is not an abstract “future risk.” Automotive systems are being probed and exploited today, sometimes by skilled researchers acting responsibly, sometimes by criminals motivated by theft and fraud, and sometimes by actors seeking surveillance or disruption. The industry’s safety culture was built for mechanical failure and manufacturing defects. Cybersecurity introduces a different failure mode: the same weakness can exist simultaneously across thousands or millions of vehicles, and an attacker can often reach those vehicles remotely, without the friction that historically limited harm to local incidents.

Regulators and safety bodies have increasingly framed automotive cybersecurity as a public safety issue rather than a mere IT concern. The U.S. vehicle safety regulator’s best-practices guidance explicitly treats cybersecurity as a lifecycle responsibility tied to safety outcomes, not simply a technical afterthought.*1 This shift matters because it changes what “acceptable risk” means. When failure is physical, societies demand accountability. When the cause is digital, the temptation is to treat it as a niche engineering matter. That temptation is precisely what the connected-car era no longer allows.

The Day the Industry Lost Its Illusion of Distance

The automotive world had security research for years, but its collective attention snapped into focus when a remote compromise became a mainstream story with mainstream consequences. The public demonstration that etched this into memory was the Jeep Cherokee hack publicized in 2015, which showed that remote exploitation could reach into safety-relevant behavior.*2 What made the moment pivotal was not only the technical method, but the message: connectivity had created a bridge from the outside world into systems that drivers assumed were physically insulated.

In the years since, the headline-grabbing “remote steering” narratives have become less central than something more quietly dangerous: weak points in the web platforms that sit behind vehicle connectivity. If a vehicle’s cloud service can be tricked, an attacker may not need to break cryptography or reverse-engineer an ECU. They may only need to exploit the same kinds of failures that have haunted web applications for decades: broken authentication, insecure object access, poor authorization boundaries, and poorly protected administrative functions.

This is why the smartest attackers increasingly aim at the ecosystem, not only the vehicle. A modern car is part of a distributed system made up of mobile apps, identity services, APIs, telemetry platforms, dealer portals, and update pipelines. If you can compromise any part of that, you can often influence the car—or at least the person inside it—without touching the car’s internal networks.

The Real Attack Surface: Cars, Clouds, Apps, and the Spaces Between

To understand automotive cybersecurity in the present tense, you have to abandon the old mental model that placed “the car” at the center and everything else as optional. In today’s architecture, the vehicle is one node. The actual product a customer buys is an interaction between the vehicle, the manufacturer’s backend, the mobile app, and the data services that connect them. This is why cybersecurity must be understood as an ecosystem discipline.

Inside the vehicle, there are multiple networks, gateways, and controllers, and increasingly an Ethernet backbone that supports higher bandwidth functions. There are telematics units connecting to cellular networks, infotainment systems running complex operating systems, and gateways that attempt to separate domains. Yet the vehicle is also paired to a customer identity, and that identity lives in the cloud. Many remote features are mediated by APIs. The customer’s phone becomes a key. A third-party service might also be allowed to query vehicle data. Each integration is an opening.

The shift from “vehicle hacking” to “vehicle ecosystem hacking” changes the nature of the threat. An attacker who finds a flaw in a backend portal or an API can sometimes unlock doors, start engines, track locations, or manipulate account ownership without needing a firmware exploit. That pattern has been documented in modern research and reporting across multiple brands, showing that the weakest point is often web security rather than embedded security.*3 The implications are severe because web flaws scale. One flaw can expose a fleet, a brand, or even multiple brands if they share platforms or suppliers.

This is not a purely technical observation. It is a governance indictment. Web platforms have matured security practices in many sectors, but automotive organizations often built their digital stacks quickly, through mergers, suppliers, and layered legacy systems. In that environment, the identity boundary becomes confused. Who is authorized to do what, and why? If that question cannot be answered precisely in code, the vehicle becomes vulnerable not because the car is poorly built, but because the ecosystem is poorly governed.

Why Modern Automotive Hacking Has Become Easier to Monetize

Some readers still imagine automotive hackers as hobbyists chasing spectacle. That picture is outdated. The economic motivations are obvious once you view a car as a digital asset with physical value. If you can unlock a car remotely, you can steal it. If you can control a vehicle account, you can stalk a person. If you can access location history, you can infer habits and vulnerabilities. If you can compromise a fleet portal, you can extort a logistics company by disrupting operations.

The trend line is clear: the connected car has created new criminal opportunities, and criminals are rational. They will prefer the path of least resistance that yields high reward. That path increasingly runs through weak identity controls and APIs rather than deep embedded exploitation.

The OWASP API Security Top 10 exists because APIs have become the connective tissue of modern systems, and the same failure patterns appear repeatedly: broken authorization, broken authentication, excessive data exposure, poor inventory, and insecure configuration.*4 Automotive platforms are not exempt from these patterns. In fact, they are uniquely exposed, because an API flaw in a connected vehicle platform doesn’t only leak data. It can grant action: unlock, locate, start, honk, flash lights, and in some cases affect operational behavior. When action is attached to API endpoints, API weaknesses become physical risks.

The “Website Bug” Era: When Security Fails Before the Car Is Even Touched

A painful lesson of recent years is that some of the most consequential automotive vulnerabilities have not required advanced vehicle hacking at all. They have required ordinary web exploitation skills. Reporting has described cases where researchers could track or command vehicles by abusing web portal weaknesses and authorization failures, sometimes with surprisingly little friction.*5 These are the kinds of bugs that mature web companies expect and defend against relentlessly. The fact that they appear in automotive platforms is a sign of cultural lag: the industry’s safety rigor has not always been mirrored in its software security rigor.

The strategic damage here is larger than the vulnerability itself. If customers learn that their vehicle’s remote features can be hijacked through a simple backend weakness, their trust collapses not only in the affected brand, but in the broader promise of connected mobility. Trust, once broken, is expensive to rebuild. It requires evidence of change, not assurances.

This is where many automotive companies make a critical mistake. They treat disclosure and patching as the end of the story. But in the public mind, a vulnerability story is rarely about the specific bug. It is about what the bug reveals about competence. The real brand injury comes from the suspicion that the company doesn’t know what it’s doing, or worse, doesn’t care.

Safety and Privacy Have Merged Into the Same Battlefield

Automotive cybersecurity used to be discussed primarily as a safety problem: could someone hack steering, brakes, or acceleration? That remains important, but modern risk has broadened. Privacy is now inseparable from security because the connected car is an intensive sensor platform. Location data alone can reveal patterns that endanger people, and the car often collects far more than location.

When a vulnerability allows access to vehicle location history, the harm may be immediate even if the attacker never touches control systems. Stalking, coercion, targeted burglary, and personal threat are all plausible outcomes when mobility traces are exposed. In other words, an attacker does not need to “drive the car remotely” to cause real harm. They can exploit the informational shadow the car creates.

This merging of safety and privacy is a policy forcing function. It changes the kinds of questions regulators ask and the kinds of liabilities companies face. It also changes how consumers evaluate risk. People accept some mechanical risk as a fact of life. They are far less accepting of a product that quietly creates a map of their life and cannot protect it.

The Embedded Side Still Matters, and the Cost of Being Wrong Is Physical

It would be an error, however, to conclude that embedded vehicle security is now irrelevant. The internal vehicle networks, gateways, and ECUs still matter profoundly. Researchers have continued to document how remote entry points—telematics, infotainment, wireless interfaces—can become bridges into internal networks if segmentation and security controls fail. Technical work explaining remote exploitation chains in vehicles illustrates that attackers have multiple paths, and that once inside, they may be able to influence components unless architectures are designed defensively.*3

The long-term trend in vehicle architecture is moving toward domain controllers, centralized compute, and more unified software platforms. This can improve security if it reduces uncontrolled complexity and enables consistent patching. It can also worsen security if it concentrates power without strong containment and verification. Centralization means fewer places to defend, but it also means a compromised component can be more consequential.

This is where the “cars are computers” analogy becomes dangerous if taken lazily. Cars are not laptops. Their failure modes are physical, and their safety expectations are higher. The appropriate security standard is not “good enough for consumer software.” It is closer to the rigor of critical infrastructure engineering, because the product operates at speed in public spaces.

The Compliance Turn: When Cybersecurity Stops Being Optional

For years, automotive cybersecurity was discussed as guidance, frameworks, and voluntary standards. That world is ending. The arrival of UNECE regulations transformed cybersecurity from a best-practice aspiration into a market access requirement in many jurisdictions. UNECE Regulation No. 155 requires manufacturers to operate a cybersecurity management system, with risk management across the vehicle lifecycle and evidence that threats are identified and addressed.*6 UNECE Regulation No. 156 requires a software update management system, formalizing governance around how vehicle software updates are managed and verified.*7

These regulations matter not only because they impose requirements, but because they force organizational change. A company cannot comply through a single security team writing a policy document. Compliance requires traceable processes, cross-functional accountability, supplier governance, monitoring, and continuous improvement.

The deeper implication is that regulators are implicitly acknowledging a principle: a connected vehicle is not “finished” at the end of production. It is an evolving software product, and the manufacturer remains responsible for its security posture over time. That principle aligns with reality, because vulnerabilities are discovered after release, attackers adapt, and systems change. A one-time security test at launch is not a safety program. It is theater.

The Standard That Shapes Engineering Culture, Not Just Paperwork

Alongside regulation, engineering standards increasingly define what “professional” cybersecurity means in automotive contexts. ISO/SAE 21434 sets engineering requirements for cybersecurity risk management across the lifecycle of vehicle electrical and electronic systems, shaping how teams perform threat analysis, risk assessment, verification, and ongoing management.*8 The value of such a standard is not in its label. Its value is that it demands repeatability. It turns security into an engineering discipline rather than an improvised reaction.

Automotive organizations sometimes treat standards as checklists. That mindset is exactly what will fail them. The real role of ISO/SAE 21434 is cultural: it forces teams to integrate security early, to produce evidence, and to make security decisions visible, reviewable, and improvable. In a complex supply chain, visibility is survival. If you cannot prove what you did and why, you will not be able to respond credibly when something goes wrong.

Industry groups have also provided practical guidance intended to help automotive stakeholders build effective security practices without turning every decision into a bureaucratic performance. The Auto-ISAC best practice guides are explicitly designed to help organizations identify, prioritize, treat, and monitor risks across product, IT, and OT lifecycles.*9 The key point is that cybersecurity is not just inside the vehicle engineering team. It touches dealer systems, corporate networks, manufacturing operations, and vendor ecosystems.

The Supply Chain Problem Is Not a Footnote, It Is the Battlefield

A modern vehicle is assembled from hundreds of suppliers. Many of those suppliers ship software, firmware, cloud services, and development tools. This creates a structural vulnerability: an OEM can build strong security internally and still inherit weaknesses from vendors. Even worse, a vendor weakness can propagate across multiple OEMs, creating systemic risk.

Broader cybersecurity research has repeatedly highlighted supply chain compromise as a significant threat pattern, and guidance from European cybersecurity authorities emphasizes good practices for supply chain cybersecurity because weaknesses in procurement and vendor governance can undermine even strong internal security programs.*10 The automotive industry, with its global supplier networks and long product lifecycles, is particularly exposed.

The most mature automotive security organizations treat supply chain governance as a core function. They enforce secure development requirements, demand evidence, audit processes, monitor vulnerabilities, and create contractual obligations for timely patching and disclosure. The least mature treat suppliers as black boxes and hope nothing goes wrong. Hope is not a strategy when your product is a connected system.

Why Over-the-Air Updates Are Both a Shield and a Knife

Over-the-air updates are often presented as the solution to cybersecurity. In part, they are. If a vulnerability exists, the ability to patch remotely and rapidly can prevent long-term exposure. The problem is that OTA also becomes an attack target. If an attacker can compromise the update pipeline, they can scale their influence across vehicles. This is why governance around software updates is now regulated.*7 It is also why the security of the signing keys, build systems, and deployment infrastructure becomes as important as the security of the vehicle itself.

There is a subtle but crucial point here. Patching is not enough. You must be able to patch safely. You need verification, rollback strategies, monitoring, and resilience. A rushed patch that breaks vehicle behavior can itself become a safety event, and a patch pipeline that is not hardened can become the attacker’s highway.

This is one reason regulators focused on update management systems rather than simply mandating “patch quickly.” They are pushing the industry to treat updates as safety-critical operations.

The Insurance and Liability Wave That Many Companies Are Not Ready For

Cybersecurity failures in vehicles do not stay in engineering departments. They move outward into insurance pricing, legal exposure, and brand perception. As vulnerabilities become more public, insurers will inevitably ask what risk they are underwriting. If an incident can affect many vehicles at once, the risk resembles catastrophic exposure rather than individual accident probability. That is a different type of underwriting problem.

Legal liability will also evolve. When a vehicle’s security failure leads to theft, stalking, injury, or loss, courts will examine whether the manufacturer acted reasonably. What counts as reasonable will increasingly be shaped by standards, regulations, and industry best practices. Guidance from safety regulators and the presence of binding UNECE requirements create a baseline expectation that cybersecurity is a managed responsibility, not an optional feature.*1 *6

Companies that treat cybersecurity as a compliance performance will discover that compliance documents are not persuasive when customers are harmed. Courts and regulators are interested in real behavior: did you design defensively, did you monitor, did you respond, and did you patch within a reasonable timeframe?

The Organizational Truth: Most Automakers Are Not Structured for Software Risk

Here is the part many leaders prefer to avoid because it implicates power structures: automotive cybersecurity often fails because the organization was designed for a hardware era. In many companies, software security responsibilities are split between IT and engineering, with unclear authority and competing priorities. Engineering may focus on functionality and timing. IT may focus on corporate systems. Meanwhile, the cloud platform that mediates vehicle features sits in a third place entirely, sometimes under a digital business unit pressured to ship features.

In that environment, nobody owns end-to-end risk. Vulnerabilities appear in the seams, where accountability is ambiguous. Attackers love seams.

The regulatory demand for a cybersecurity management system is, in part, a demand for organizational clarity.*6 It forces companies to define responsibilities, escalation paths, and evidence of risk management. That is not paperwork for its own sake. It is an attempt to impose systemic control over a complex socio-technical product.

What “Security by Design” Means When the Product Moves at 120 km/h

In the automotive context, “security by design” is not a slogan. It means that security is integrated into architecture decisions and lifecycle operations. It means systems are segmented so that compromise of a non-safety domain cannot trivially influence safety-critical behavior. It means identities are scoped, permissions are minimal, and backends enforce authorization with discipline. It means the company maintains an accurate inventory of assets and endpoints so that “unknown interfaces” do not persist. The OWASP API guidance stresses the importance of knowing what you expose, because undocumented or poorly governed endpoints become attack magnets.*4

It also means the company can detect and respond. Vehicles and backends must produce telemetry that supports anomaly detection and incident investigation without turning customers into surveillance subjects. That tension is difficult but manageable if governance is mature. If governance is immature, companies swing between two extremes: collecting too much data without clear purpose, or collecting too little and being blind when attacks happen.

And it means training and incentives align. Engineers and product managers must be rewarded for building secure systems, not only for shipping features. If speed is rewarded and safety is assumed, cybersecurity will be consistently sacrificed.

Practical Advice for OEM Leaders Who Want the Truth, Not Comfort

If you lead an automotive organization, your first task is to stop asking whether cybersecurity is “important” and start asking where your system is weakest. The weakest points are often boring: identity flows, dealer portals, customer support tools, partner integrations, and API authorization boundaries. The most common large-scale failures are not cinematic. They are procedural and architectural.

Your second task is to build governance that matches the product. If your connected vehicle platform is global, your incident response must be global. If your vehicle features are controlled through APIs, your security program must treat API security as a first-class discipline, aligned to established web security realities.*4 If your vehicles patch via OTA, your update governance must be hardened and auditable.*7

Your third task is to treat cybersecurity as a brand property. In a world where vulnerabilities are publicly reported and rapidly amplified, secrecy is not a strategy. Resilience is. Mature disclosure programs, external testing, and rapid remediation do not make you look weak. They make you look competent.

Finally, your fourth task is to confront the economic trade-off honestly. Security costs money and time. A breach costs far more. The choice is not “security versus profit.” It is “planned cost versus catastrophic cost.” The companies that win will be the ones that understand this before they are forced to learn it through humiliation.

Practical Advice for Engineers Who Build the Future Car

If you build vehicle software, backend services, or mobile apps connected to vehicles, you are working in a cyber-physical safety domain. You may not hold a safety engineer title. The risk does not care. Your design decisions will either contain attackers or empower them.

Treat identity and authorization as sacred. Make sure every action endpoint enforces authorization in the backend, not only in the UI. Assume clients are compromised. Scope tokens tightly. Rotate keys. Validate every access path. The most embarrassing failures are those where a user can act as another user because an ID was trusted. These are precisely the categories web security communities have warned about for years.*4

Treat observability as part of safety. Logs are not just for debugging; they are for detecting abuse. But logs must be designed responsibly, with privacy safeguards, because careless monitoring can become its own form of harm.

Treat OTA like a medical procedure, not an app update. It must be controlled, verified, reversible, and secure.*7 If your update system cannot roll back safely, you are one bad update away from a recall-level incident.

And perhaps most importantly, treat simplicity as a security feature. Complexity multiplies risk. If you can reduce the number of trust relationships and external interfaces, you reduce your exposure. No security team can outwork a chaotic architecture forever.

Practical Advice for Consumers Living in the New Trust Economy

Consumers cannot audit vehicle cybersecurity, but they can develop wiser instincts. A brand’s public posture matters. Does the manufacturer publish security guidance? Do they acknowledge security research? Do they patch transparently? Do they offer account protections such as strong authentication? Do they allow users to control remote access features responsibly?

The uncomfortable truth is that consumer trust will become a competitive variable. In the same way crash test ratings and reliability reputations shaped buying behavior, cybersecurity posture will begin to matter more—especially as stories of tracking and remote command vulnerabilities enter mainstream awareness.*5

Consumers will also increasingly expect control: control over data, over remote features, over what is shared with third parties. Companies that treat customer data as a business asset without restraint will eventually face backlash, regulation, or both.

The Future: Cybersecurity Will Shape Regulation, Insurance, and the Definition of a “Safe Car”

The automotive industry is entering an era where cybersecurity is inseparable from product safety and customer trust. The regulatory direction is already set, and it is becoming stricter and more operational.*6 *7 Standards are shaping what “professional engineering” looks like in this domain.*8 Industry bodies are providing guidance because the ecosystem is too complex for any single company to solve alone.*9

The key question is no longer whether cars can be hacked. They can. The question is whether the industry can mature fast enough to make hacking difficult, containment strong, detection rapid, and response credible.

If it does, the connected car becomes a net benefit and remains worthy of trust. If it doesn’t, connectivity will be seen not as progress, but as reckless exposure—an avoidable risk imposed on the public.

The industry is at a fork. It can treat cybersecurity as compliance and PR, or it can treat it as the next great safety engineering frontier. The path it chooses will determine not only what regulators demand, but what customers believe, and what attackers attempt.





References

*1 National Highway Traffic Safety Administration. (2022). Cybersecurity best practices for the safety of modern vehicles. https://www.nhtsa.gov/sites/nhtsa.gov/files/2022-09/cybersecurity-best-practices-safety-modern-vehicles-2022-pre-final-tag_0_0.pdf

*2 Greenberg, A. (2015, July 21). Hackers remotely kill a Jeep on the highway—with me in it. Wired. https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

*3 Miller, C., & Valasek, C. (2015). Remote exploitation of an unaltered passenger vehicle (white paper). IOActive. https://www.ioactive.com/wp-content/uploads/pdfs/IOActive_Remote_Car_Hacking.pdf

*4 OWASP. (2023). OWASP Top 10 API security risks – 2023. https://owasp.org/API-Security/editions/2023/en/0x11-t10/

*5 Newman, L. H. (2024, September 26). Millions of vehicles could be hacked and tracked thanks to a simple website bug. Wired. https://www.wired.com/story/kia-web-vulnerability-vehicle-hack-track/

*6 United Nations Economic Commission for Europe. (2021). UN Regulation No. 155: Cyber security and cyber security management system. https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security

*7 United Nations Economic Commission for Europe. (2021). UN Regulation No. 156: Software update and software update management system. https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update

*8 International Organization for Standardization. (2021). ISO/SAE 21434: Road vehicles — Cybersecurity engineering. https://www.iso.org/standard/70918.html

*9 Automotive Information Sharing and Analysis Center. (2025). Best Practice Guides (BPGs). https://automotiveisac.com/best-practice-guides

*10 European Union Agency for Cybersecurity. (2023). Good practices for supply chain cybersecurity. https://www.enisa.europa.eu/sites/default/files/publications/Good%20Practices%20for%20Supply%20Chain%20Cybersecurity.pdf