Modern vehicles are rolling computers. And like every computer ever made, they can be broken into. Here's what that really looks like, and why the industry is scrambling to catch up.

Picture this: you're driving on the highway at 70 mph when your radio starts blaring, your windshield wipers flick on, and then — the steering wheel jerks out of your control. You didn't do anything. The car just… did it. On its own. Because someone miles away, sitting at a laptop, decided to try something.

This is not a thriller novel. In 2015, it actually happened to a journalist who volunteered to drive a Jeep Cherokee while two security researchers took control of the vehicle remotely over the internet. The world watched, and the automotive industry has never quite been the same since.

We're now deep into an era where the average new car has more lines of software code than a commercial aircraft. These vehicles connect to the internet, talk to each other, receive over-the-air updates, and integrate with your smartphone. That connectivity is genuinely wonderful — but it also opens a door that didn't exist when cars were purely mechanical.

This is the first in a series where we'll dig into automotive cybersecurity properly. Not with surface-level summaries, but with the real stuff: how attacks work, what the regulations actually require, and what engineers in this space deal with every day. Let's start at the beginning.

The Hack That Changed Everything

You have to understand the 2015 Jeep Cherokee incident in its full context to appreciate why it mattered so much. Before that summer, most people inside and outside the auto industry treated vehicle cybersecurity as a theoretical problem. Interesting to think about, perhaps — but not exactly urgent.

Researchers Charlie Miller (who'd previously hacked iPhones) and Chris Valasek (a longtime car security enthusiast) had been poking at vehicle systems for a couple of years. They'd done earlier demos requiring physical access to the car. But the 2015 attack was something else entirely. It required no physical access whatsoever. Miller was sitting in his living room in St. Louis while the Jeep's victim-driver, Wired journalist Andy Greenberg, drove on a highway outside the city.

The entry point was the Jeep's Uconnect entertainment system, which connected to the Sprint cellular network. It had a publicly routable IP address and a software vulnerability that allowed the researchers to push new firmware to a chip in the head unit. From there, they could communicate with the vehicle's internal CAN bus — the nervous system that connects nearly every electronic component in a modern car.

What made this attack genuinely alarming wasn't just that it worked — it was the breadth of what the researchers could do once they were in. They could kill the engine, disable the brakes at low speeds, turn the steering wheel (at reverse speeds), crank the AC, blast the radio, and activate the windshield wipers. All remotely. All while the driver sat helplessly.

The CAN bus problem at the heart of this exploit is worth understanding. The CAN protocol was designed decades ago specifically to allow the many electronic control units in a vehicle to talk to each other efficiently. It's elegant engineering, but it was built in an era when no one imagined a car's radio would have an internet connection that could reach the brakes. There's essentially no authentication on the CAN bus. If you can get a message onto it, the receiving component will generally trust it and obey.

This is the foundational tension in automotive cybersecurity: legacy systems built for reliability in isolated environments are now connected to a world full of adversarial actors.

Tesla's Approach: Move Fast, Patch Faster

Tesla presents a fascinating contrast. As a software-first car company, Tesla has faced its own security incidents — but its response model has been strikingly different from legacy automakers.

In 2019 at the Pwn2Own hacking competition, a team from Fluoroacetate broke into a Tesla Model 3 in a way that earned them a $35,000 bounty and the car itself. They exploited a vulnerability in the browser's renderer to gain control of the infotainment system. Within days, Tesla had an over-the-air patch rolling out to every affected vehicle.

That turnaround time is essentially impossible for traditional automakers. When your software update process requires physical dealer visits or complex fleet logistics, a days-long patch cycle becomes a months-long exposure window. Tesla's OTA (over-the-air) update infrastructure — the same technology that adds new features while you sleep — is also a genuine security advantage.

Tesla also runs a persistent bug bounty program that invites security researchers to find and report vulnerabilities in exchange for cash rewards. This is standard practice in software security, but was essentially unheard of in the auto industry until Tesla normalized it. The logic is simple: you'd rather pay a friendly researcher $10,000 to find a hole than discover it was found by someone with worse intentions.

The Attacks You Don't Read About

The Jeep hack makes headlines because it's dramatic. But there's a quieter, more common category of automotive attack that affects far more people every year: keyless relay attacks.

If you have a modern car with keyless entry, here's something a little unsettling to know. The car and your key fob communicate using short-range radio signals. Your car is constantly listening for that signal, and when it detects the key fob nearby, it unlocks and allows you to start. It seems simple and smart. But "nearby" is determined by signal strength — and signal strength can be manipulated.

The uncomfortable reality is that this attack doesn't require sophisticated hacking skills or expensive equipment. Relay device kits have been found selling online for a few hundred dollars. And it works against a wide range of vehicles from multiple manufacturers. Insurance fraud investigators and police departments in the UK, US, and Germany have all documented significant increases in keyless theft using this method.

The fix isn't straightforward, it requires changing how the authentication protocol works, not just patching a software bug. Some manufacturers have introduced "ultra-wideband" technology that can more accurately determine the key's physical location, and others have moved to motion sensors that put the key fob to sleep when stationary. But millions of existing vehicles remain vulnerable.

Mapping the Threat Landscape

When security professionals talk about a "threat landscape," they mean all the different ways something can be attacked. Modern vehicles have an attack surface that has expanded dramatically over the past decade — and continues to grow with each new connected feature.

The supply chain threat deserves special attention because it's the hardest to defend against. A modern vehicle contains software and hardware components from hundreds of suppliers. If any one of those suppliers ships a compromised component — whether through their own negligence or because they were targeted by an adversary — that compromise can propagate into millions of vehicles. This isn't hypothetical; it's a known attack pattern in other industries, and automotive is increasingly exposed to it.

⚠ The OTA Update Paradox: Over-the-air update capability is simultaneously one of the best security tools in automotive and one of the most dangerous attack surfaces. A compromised OTA system doesn't just affect one car — it potentially affects every car in a fleet. Securing the update pipeline (cryptographic signing, secure boot, integrity verification) is now one of the most critical tasks in automotive cybersecurity.

How Regulators Responded

The automotive industry is not short of opinions about how regulation tends to work: slow, reactive, and occasionally painful to implement. But give credit where it's due, the cybersecurity regulatory response to these threats has been reasonably substantive, even if it took longer than it should have.

Two frameworks dominate the current landscape, and understanding both is essential if you work anywhere in the automotive supply chain.

The ISO/SAE 21434 standard is worth understanding beyond the acronym. Its core methodology , TARA requires engineers to systematically identify every asset in a vehicle that could be attacked, analyze the potential threats to those assets, assess the risk of each threat, and design mitigations accordingly. That sounds like common sense, but doing it rigorously across a vehicle with hundreds of ECUs and thousands of software components is genuinely difficult work.

The standard also does something that matters enormously in practice: it places security obligations on suppliers, not just OEMs. A tier-2 supplier providing a telematics module must now demonstrate cybersecurity engineering — not just functional safety. This has rippled through the entire supply chain and created a significant demand for engineers who understand both domains.

Hardware Security: The Silicon Layer

Software defenses are essential, but they have an inherent limitation: they run on hardware, and if that hardware is compromised at boot time, no amount of software checking will save you. This is why Hardware Security Modules — HSMs — have become central to automotive cybersecurity architecture.

An HSM is a dedicated piece of silicon designed to handle cryptographic operations and store secret keys in a way that's physically resistant to tampering. In an automotive context, an HSM embedded in a vehicle's main microcontroller does a few critical things. It verifies at boot that the software being loaded is legitimate and hasn't been tampered with (secure boot). It stores and manages the cryptographic keys used to authenticate communications between ECUs. It provides an isolated execution environment for security-critical operations that malicious software running elsewhere in the system cannot access.

Why HSMs Matter: Without hardware-anchored trust, an attacker who compromises the main software environment can fake any security check. With an HSM, even a fully compromised operating system cannot forge signatures or access cryptographic keys stored in the secure enclave. It's the difference between a lock that only works when nothing is broken and a lock that works even when everything else has failed.

The challenge is that HSMs add cost and complexity. In an industry that measures margins carefully and designs ECUs to last fifteen years, integrating new silicon is not trivial. The industry has made progress — HSMs are increasingly common in new designs — but the installed base of vehicles without them is enormous and will remain on roads for decades.

What This Means for Engineers

These aren't abstract recommendations — they're the gaps I've seen firsthand across OEM and Tier-1 projects, and the skills that separate engineers who can talk security from those who can actually design it.

If you're an automotive engineer who trained primarily in mechanical systems, powertrain, or even classical embedded software, this landscape can feel like it arrived overnight. In one sense, it did. The industry went from "cybersecurity is not our problem" to "cybersecurity is a regulatory requirement for market access" in roughly a decade.

The demand for people who can bridge automotive engineering and cybersecurity is genuinely significant — and the skill set is rare. You need to understand vehicle architecture deeply enough to reason about what matters if compromised, but also understand security engineering well enough to design proper defenses. That combination doesn't appear automatically in either a traditional automotive engineering program or a computer science security curriculum.

Certifications are beginning to emerge that formalize this knowledge — including programs aligned specifically to ISO/SAE 21434. While no certification replaces hands-on experience, they do help engineers demonstrate competence to employers and provide a structured framework for self-study. If you're looking to transition into this space, the combination of the 21434 standard itself (which is public) and a structured training program will give you a significant head start.

Where This Goes Next

Autonomous vehicles add a new dimension that makes everything discussed here higher stakes. A vehicle that drives itself based on sensor data can be attacked not just through its network interfaces, but by manipulating what its sensors perceive — spoofing GPS signals, confusing LIDAR with carefully positioned reflectors, fooling camera-based systems with adversarial patterns. These are active research areas with real demonstrations behind them.

V2X (Vehicle-to-Everything) communication — the emerging technology that allows vehicles to communicate with each other and with road infrastructure — introduces yet another protocol layer to secure. And as vehicles become more tightly integrated with cloud backends for navigation, insurance telemetry, and feature delivery, the attack surface extends well beyond the vehicle itself into data centers and mobile applications.

The honest picture is this: the attack surface is expanding faster than the defenses are maturing. That's not a reason for panic — it's a reason for urgency. The industry has recognized the problem, regulation is compelling action, and there's a genuine generation of engineers being built around this discipline. But it remains one of the more serious open challenges in consumer product security today.

In the next part of this series, we'll go deeper into threat modeling — specifically, how TARA works in practice, what it looks like to apply it to a real vehicle system, and where teams typically get it wrong. If you're an engineer starting to work with ISO/SAE 21434, that's the piece you won't want to miss.

Stay Connected

Automotive cybersecurity is evolving rapidly, and new threats continue to emerge as vehicles become more connected and software-defined.

I will continue publishing deep insights, real-world attack analysis, security architecture breakdowns, and updates on emerging automotive cyber threats and compliance standards. If you're working in IVI, ECU firmware, SDV platforms, or connected vehicle ecosystems, I invite you to follow this publication and stay informed.

Your feedback is valuable — feel free to share thoughts, corrections, or discussion points in the comments.

For professional discussions, collaboration, or technical exchanges, you can reach out directly at: sharmabudhdi@gmail.com

Let's build safer vehicle platforms together.

About Me

Automotive Software Architect with a decade of experience across OEM and Tier-1 environments. His background spans AOSP architecture, ECU design, embedded firmware, and adversarial AI security in edge and embedded systems. Connect on LinkedIn →