Security spotlight: connected vehicles are quantum targets

The automotive industry often describes modern vehicles as computers on wheels. That description is accurate, but incomplete. Today’s vehicles are not just computers. They are permanently connected systems, interacting with infrastructure, service platforms, other vehicles, and the cloud throughout their entire lifecycle. This is where security begins to fail.

In the past, cars were largely isolated. You designed them, built them, sold them, and they operated independently for years. Car manufacturers focused primarily on safety and reliability. Today, vehicles are connected every day of their lives. They receive software updates, authenticate with external services, and exchange data continuously. Each connection creates opportunity. Each opportunity creates risk.

Security does not fail first because software is poorly written. It fails when a vehicle cannot reliably determine who it is talking to, or what it is running.

Software-defined vehicles depend on trust

The move toward software-defined vehicles is accelerating. OEMs are building flexible hardware platforms that can support evolving software over many years. This model enables new features, faster updates, and extended product lifecycles. It also creates a strict dependency on trust.

Over-the-air updates only work if the vehicle can verify that the software truly comes from the OEM and has not been altered. That verification relies on cryptographic keys stored inside the vehicle. If those keys are extracted, copied, or broken, the update mechanism itself becomes the attack vector. Without a hardware foundation of trust, software security becomes circular. You rely on software to protect software. Once that loop is broken, control is lost. This is why software updates alone cannot protect vehicles over a 20- or 25-year lifetime.

Quantum computing changes the timeline

For many industries, post-quantum cryptography is treated as a future concern. Automotive does not have that luxury. Vehicles launched today will still be on the road when quantum computers are capable of breaking widely used cryptographic algorithms such as RSA and ECC. The pace of progress in quantum computing has accelerated. Recent research from Bain shows that the gap between theory and practical capability is narrowing. The exact date when current cryptography fails is uncertain. The direction is clear.

When that happens, attackers will not need to exploit software bugs. They will be able to impersonate trusted entities, forge software signatures, and deliver malicious updates that appear legitimate by design. At that point, patching no longer restores security. The trust model itself has failed. This is why post-quantum readiness must be designed into vehicles now. Crypto agility cannot be added later through software alone. It must be supported at the hardware level, even if new algorithms are deployed years in the future.

From software attacks to component impersonation

Vehicle attacks are often discussed as remote hacking scenarios. In practice, the more serious risk is impersonation. Researchers have already demonstrated attack paths that start in non-critical domains, such as infotainment or connectivity modules, often accessed through Bluetooth, USB ports, or user-facing interfaces. From there, lateral movement inside the vehicle becomes possible.

The problem escalates when counterfeit or cloned ECUs enter the system. These components do not only appear during manufacturing. They can enter through supply chains, aftermarket repairs, refurbishing, or service operations over the vehicle’s lifetime. Major automotive players—including teams at the highest level of motor racing—are already preparing for the impact of quantum-era attacks on vehicle systems.  If a vehicle cannot cryptographically authenticate a component at the hardware level, it has no reliable way to reject it. The system trusts behaviour instead of identity. That is not security.

Once attackers can impersonate components, software controls stop being gatekeepers. They become observers.

Trust must be anchored in hardware

Trust is not an abstract concept. It is the ability to authenticate before interaction. In digital systems, that trust must be enforced somewhere that cannot be copied, modified, or extracted. That place is hardware.

A hardware root of trust protects cryptographic keys, enforces which software is allowed to run, and validates which components are permitted to participate in the vehicle system. It continues to function even if higher-level software is compromised. For a non-technical explanation, the difference is simple. Software can always be duplicated. Hardware identity cannot. This is also why lifecycle software updates cannot fix problems that originate at manufacturing or provisioning. If trust is not correctly established at the beginning, updates only reinforce a flawed foundation.

Why this matters now

This discussion is urgent because key architectural decisions are being made today. Vehicle platforms entering development now will define security posture for decades. Five months ago, quantum threats were widely seen as distant. Today, it is clear that the intermediate period is shrinking. Five months from now, many design choices will already be locked.

Regulators are rightly focused on software compliance and update processes. What remains underestimated is systemic risk. If identity fails at scale, safety implications follow directly. For automotive manufacturers, this is no longer a question of adding another security layer. It is a question of where trust lives. If trust is not anchored in hardware from day one, vehicle security will eventually reach a limit it cannot cross. That limit is approaching faster than many expect.

About the author: Gweltas Radenac is Director of the IoT Security Business Unit at SEALSQ, where he is responsible for product strategy, roadmap development, and go-to-market execution for secure connected systems