Car Botnets: The New Connected-Vehicle Cyber Risk

Executive Summary — BLUF

• The proposition that automobiles can become botnet nodes is no longer theoretical: in June 2025, the FBI explicitly identified aftermarket vehicle infotainment systems among devices susceptible to the BADBOX 2.0 botnet, which it described as comprising millions of compromised devices. Home Internet Connected Devices Facilitate Criminal Activity – Federal Bureau of Investigation – June 2025. Verified FBI source
• The specific June 2026 DoFun/TWCore/JarService/MoYu infection chain supplied for this report cannot yet be elevated to V.8.0 “verified fact” because the available primary disclosure is outside the permitted government/.mil/.int/audited-IR hierarchy; it remains a high-value intelligence lead requiring independent primary confirmation.
• The strategic issue is substantially larger than malware in an entertainment console: the modern vehicle is becoming a distributed cyber-physical edge computer connected simultaneously to OEM clouds, mobile networks, Wi-Fi, Bluetooth, GNSS, smartphones, charging infrastructure, applications, digital keys, V2X services and over-the-air software repositories.
• NHTSA already treats wired and wireless vehicle entry points, firmware updates, intrusion detection and separation of safety-critical communications as systemic cybersecurity problems. Vehicle Cybersecurity – NHTSA – current official guidance. Verified NHTSA source
• UNECE R155 and R156 institutionalised lifecycle cybersecurity management and secure software-update governance; the problem is therefore explicitly recognised at international vehicle-type-approval level. UN Regulation No. 155 / UN Regulation No. 156 – UNECE – March 2021.
• The European Commission now connects vehicle cybersecurity directly with economic security, supply-chain dependency, weaponisation risk and critical-component sovereignty, while simultaneously accelerating software-defined and automated vehicles. Industrial Action Plan for the European Automotive Sector – European Commission – March 2025.
• The United States has already crossed from cybersecurity guidance into geopolitical technology exclusion, prohibiting defined Chinese- and Russian-linked VCS/ADS software from Model Year 2027 and covered VCS hardware from Model Year 2030. Commerce Finalizes Rule to Secure Connected Vehicle Supply Chains from Foreign Adversary Threats – BIS – January 2025.
• The five-year safety question is consequently not “can malware enter a car?” but whether compromise can scale across homogeneous fleets, survive updates, exploit cloud trust, monetise connectivity, collect strategic data, cross electronic trust boundaries and ultimately influence safety-relevant vehicle behaviour.

Car Botnets: When the Vehicle Becomes Critical Infrastructure

The connected car has crossed a strategic threshold. It is no longer simply a vehicle equipped with digital services: it is a mobile computing platform linked to cellular networks, cloud infrastructure, software repositories, remote-update systems and increasingly automated functions. On 5 June 2025, the FBI explicitly listed aftermarket vehicle infotainment systems among devices vulnerable to the BADBOX 2.0 ecosystem, which it said comprised millions of compromised devices. That did not mean millions of cars had been infected, nor that BADBOX could control steering or braking. It meant something more structural: automotive equipment had entered the botnet economy. From that point, vehicle cybersecurity ceased to concern only privacy or infotainment. It became an issue of industrial resilience, transport safety, software sovereignty and national security. — Home Internet Connected Devices Facilitate Criminal Activity – FBI/IC3 – June 2025. Official FBI/IC3 advisory

The Car as an Edge Node

The modern automobile combines characteristics previously distributed across several technological domains. It contains embedded computers, persistent network identities, cellular connectivity, Wi-Fi and Bluetooth interfaces, positioning systems, applications, telematics services and remotely maintained software. NHTSA describes modern vehicles as systems increasingly dependent on electronics, sensors and complex software, and explicitly recommends a multilayer cybersecurity architecture covering both wireless and wired entry points. Its current research includes anomaly-based intrusion detection, firmware-update security, V2V communication interfaces and the cybersecurity of electronic vehicle architectures. — Vehicle Cybersecurity – National Highway Traffic Safety Administration – current official programme. NHTSA Vehicle Cybersecurity

This architecture changes the economics of attack. Malware does not need to reach the accelerator, steering rack or braking system to create value. An infected automotive device can provide persistent connectivity, an apparently legitimate consumer IP address, location information and access to a device that may remain operational for years. The FBI’s 5 June 2025 BADBOX 2.0 warning states that criminals were exploiting compromised IoT systems through residential proxy services and specifically included aftermarket vehicle infotainment equipment among susceptible product categories. The crucial point is therefore not that a car has become a remotely controllable weapon; primary evidence does not support that generalisation. It is that part of the automotive digital ecosystem can already be recruited into the same criminal infrastructure used to monetise compromised IoT devices.

From Infotainment to the Gateway

The most important technical boundary is the separation between externally exposed computing and safety-relevant functions. An infotainment compromise is not automatically a braking compromise. For escalation to occur, an attacker must cross additional trust boundaries: from an application or communications interface to telematics or privileged services; from there toward a central gateway; and ultimately into networks carrying commands relevant to powertrain, chassis, ADAS or automated-driving functions.

That distinction is already embedded in U.S. safety policy. On 7 September 2022, NHTSA released updated Cybersecurity Best Practices for the Safety of Modern Vehicles. The agency recommends authentication and boundary controls intended to keep safety-critical communications separate, alongside cyber-resilient architecture, incident detection and rapid recovery. — NHTSA Updates Cybersecurity Best Practices for New Vehicles – National Highway Traffic Safety Administration – September 2022. Official NHTSA announcement

This produces an important security principle: the danger of a vulnerability is determined not only by where the attacker enters, but by what authority that component can inherit. A compromised entertainment process isolated by hardware and a default-deny gateway can remain a contained problem. A compromised telematics controller possessing privileged credentials, diagnostic authority or permissive internal routing presents a qualitatively different risk. The architecture, not the malware label, determines whether a cyber intrusion can become a safety incident.

The Cloud Changes the Scale

The next vulnerability is outside the vehicle. Connected cars depend increasingly on OEM back ends, identity services, remote diagnostics, software repositories and fleet-management platforms. Centralisation creates efficiency, but it also concentrates authority. An exploit affecting one car is intrinsically bounded; compromise of infrastructure legitimately authorised to communicate with an entire vehicle population may have a completely different blast radius.

This is why the most serious future automotive cyber scenario may begin in a software-development environment or cloud-control plane rather than inside a moving car. If an adversary obtains access to a build pipeline, release-management environment, privileged API or software-signing system, the manufacturer’s own infrastructure could become the route through which malicious software or commands are propagated. Proper OTA security therefore requires much more than encryption during transmission. It requires protected signing keys, software provenance, separation of duties, controlled release cohorts, rollback protections, auditability and the ability to revoke trust rapidly.

The international regulatory framework already reflects this logic. UN Regulation No. 155 establishes requirements around vehicle cybersecurity and cybersecurity-management systems, while UN Regulation No. 156 governs software updates and software-update management. The continuing UNECE work on R156 is officially available in English, French and Russian, confirming that software-update governance has become a permanent component of international vehicle regulation. — Proposal for amendments to the Interpretation Document for UN Regulation No. 156 – UNECE Working Party on Automated/Autonomous and Connected Vehicles – 2026. UNECE R156 working document

Washington Draws a Security Perimeter

The geopolitical transformation is clearest in the United States. On 14 January 2025, the Bureau of Industry and Security, part of the U.S. Department of Commerce, finalised a rule restricting connected-vehicle hardware and software with a sufficient nexus to the People’s Republic of China or Russia. BIS concluded that covered Vehicle Connectivity System hardware and software and Automated Driving System software could create unacceptable national-security risks, including sensitive-data extraction and remote vehicle manipulation. The rule took effect on 17 March 2025. Software-related prohibitions begin with Model Year 2027; restrictions on covered VCS hardware begin with Model Year 2030, or 1 January 2029 for equipment without an associated model year. — Commerce Finalizes Rule to Secure Connected Vehicle Supply Chains from Foreign Adversary Threats – Bureau of Industry and Security – January 2025. Official BIS connected-vehicle rule

The political significance is considerable. Then-U.S. Secretary of Commerce Gina Raimondo described connected cars as computers equipped with cameras, microphones, GPS and internet connectivity; then-National Security Advisor Jake Sullivan linked foreign-adversary participation in the supply chain directly to critical-infrastructure and national-security concerns. BIS defines the Vehicle Connectivity System broadly enough to include telematics control units and Bluetooth, cellular, satellite and Wi-Fi modules. Washington is therefore regulating not simply malware already discovered, but the possibility that software provenance, jurisdiction and remote access may create future strategic leverage.

Europe Moves From Compliance to Sovereignty

Europe reached an equally consequential threshold on 13 February 2026, when the NIS Cooperation Group, composed of EU Member State representatives with support from the European Commission and ENISA, adopted the EU ICT Supply Chain Security Toolbox. The package includes a specific risk assessment for connected and automated vehicles. The Commission states that such vehicles process large quantities of personal and sensitive data and can, in some circumstances, be weaponised. It recommends assessment of critical suppliers, multi-vendor strategies and measures to reduce dependency on high-risk suppliers, particularly in processing and decision-making systems, communications and connectivity, and vehicle-control systems capable of receiving remote updates. — EU ICT Supply Chain Security Toolbox and Connected and Automated Vehicles Risk Assessment – NIS Cooperation Group / European Commission / ENISA – February 2026. European Commission supply-chain toolbox

The language is significant. Europe is moving beyond the question of whether a component is technically compliant toward the larger issue of whether strategically important software and hardware dependencies remain controllable under crisis conditions. On 13 February 2026, European Commission Executive Vice-President for Tech Sovereignty, Security and Democracy Henna Virkkunen connected ICT supply-chain security directly with European security and economic resilience. The associated Commission release refers to a trusted ICT supply-chain framework addressing non-technical risks, including foreign interference. — EU launches new toolbox to strengthen ICT supply chain security – European Commission – February 2026. European Commission announcement

For the European automotive industry, this changes the definition of strategic autonomy. Final assembly in Europe is insufficient if critical operating software, communications modules, signing infrastructure, cloud identity or remote-update systems remain dependent on actors over which European manufacturers and regulators possess limited visibility or substitution capability.

The Mass-Casualty Threshold

The most extreme scenario—coordinated manipulation of vehicles producing large-scale physical harm—should neither be sensationalised nor dismissed. No primary source examined here establishes that today’s commodity automotive malware can remotely generate such an effect across a production fleet. A mass-casualty pathway would require the conjunction of several technical failures: scalable access to many vehicles; privilege escalation into a safety-relevant environment; defeat of gateway isolation; sufficient knowledge of vehicle-specific control architecture; ability to issue or induce dangerous commands; circumvention of local safety monitoring; and synchronisation of effects across time and geography.

That sequence explains why software provenance is so important. Vehicle-by-vehicle exploitation is difficult to scale. Compromise of something already trusted at scale—a supplier dependency, cloud-control service, signing authority or OTA release chain—is potentially far more consequential. The structural objective of defensive architecture must therefore be to ensure that no single identity, cryptographic key, software supplier or remote service simultaneously possesses fleet reach and physical authority.

The 2031 Security Architecture

The technological answer is not to disconnect the automobile. Connectivity supports diagnostics, safety updates, navigation, automated functions and new mobility services. The solution is to eliminate transitive trust. Compromise of infotainment must not grant telematics privilege; compromise of telematics must not grant gateway authority; gateway access must not automatically validate safety-critical commands; and cloud authentication must not constitute unrestricted physical-control authority.

NHTSA’s multilayer model points toward the necessary engineering architecture: secure boot, protected credentials, network segmentation, authenticated boundaries, anomaly detection, secure firmware updates and rapid recovery. Manufacturers must add rigorous software provenance: traceable source, controlled dependencies, protected CI/CD environments, hardware-backed signing, independent release approval and complete vehicle-level software inventories. OTA deployment should be staged so that a compromised or defective release cannot propagate instantly across an entire fleet.

Regulation must evolve accordingly. Compliance should increasingly measure not only whether an OEM possesses a cybersecurity-management process, but how many vehicles can be reached by one administrative credential, how quickly compromised certificates can be revoked, whether the fleet can continue operating safely without trusted cloud connectivity, and whether manufacturers can identify every vehicle containing a vulnerable software component.

The New Industrial Divide

By 2031, competitive advantage in automotive manufacturing will increasingly depend on control of the software trust stack as much as engines, batteries or manufacturing scale. The strategic assets will include secure processors, operating systems, middleware, cryptographic infrastructure, cloud platforms, software-development pipelines, OTA systems and the institutional capacity to maintain them throughout the vehicle lifecycle.

The United States has already transformed supplier provenance into market-access regulation. The European Union has formally connected connected-vehicle security with high-risk suppliers and strategic dependency. UNECE has embedded cybersecurity and software-update management into the international regulatory architecture. These are not parallel technical initiatives. Together they reveal a structural transformation: the automobile is becoming part of national digital infrastructure.

The first car botnets therefore matter less because they herald an imminent fleet of remotely weaponised vehicles than because they demonstrate that the criminal Internet has begun to absorb automotive computing into its economic model. Once an endpoint becomes valuable to criminals, pressure to maintain persistence, expand privilege and exploit adjacent trust relationships rises. The decisive contest of the next five years will be fought before the attacker reaches the brake controller—in supplier governance, software provenance, cryptographic trust, cloud privilege and network architecture. The safest connected car will not be the vehicle that can never be compromised. It will be the one engineered so that a compromise cannot become systemic.

Navigational Index

Master Abstract

The decisive analytical correction is to stop conceptualising the connected automobile as a conventional mechanical product containing several computers and instead model it as a mobile cyber-physical platform composed of multiple trust domains with continuously changing software state. A contemporary architecture may expose cellular telematics, Wi-Fi, Bluetooth, USB, smartphone projection, application ecosystems, diagnostic interfaces, digital keys, cloud APIs, satellite positioning, remote-control services, charging communications, navigation data, OEM analytics, fleet services and over-the-air update channels. Each interface is not equally dangerous, but collectively they destroy the historical assumption that the vehicle perimeter ends at the bodywork. The strongest admissible evidence that the “car botnet” concept has already crossed from hypothesis to operational precedent comes not from the June 2026 article supplied for this report, but from the FBI’s 5 June 2025 BADBOX 2.0 alert. The Bureau explicitly listed aftermarket vehicle infotainment systems among internet-connected devices that criminals could compromise, described infection occurring either before purchase or through malicious application downloads, and stated that BADBOX 2.0 consisted of millions of infected devices used as residential proxy infrastructure. Home Internet Connected Devices Facilitate Criminal Activity – Federal Bureau of Investigation – June 2025. FBI BADBOX 2.0 advisory This does not prove that millions of automobiles themselves were infected, nor does it prove remote access to propulsion, braking or steering; those conclusions would be analytically invalid. It proves something narrower but strategically consequential: an Android-class automotive device can participate in the same criminal infrastructure model that already monetises compromised televisions, projectors and other IoT equipment. That changes the threat taxonomy. An infected head unit need not control the vehicle to produce operational value. It can provide an IP address, persistent connectivity, processing capacity, local-network visibility, geospatial context, a proxy endpoint, advertising-fraud infrastructure or a staging position. Once automobiles become economically useful malware hosts, attacker incentives expand independently of any desire to cause a crash. The first mass automotive botnet may therefore emerge not from terrorism or military cyber operations but from ordinary cybercrime economics—precisely because proxy resale, fraud, credential abuse and covert traffic routing provide recurring revenue while creating a distributed infrastructure that can later be repurposed.

The second correction concerns safety architecture. Infection of infotainment is not synonymous with compromise of braking, steering, propulsion or automated-driving functions, and any analysis that collapses those layers exaggerates present evidence. Nevertheless, the risk cannot be dismissed merely because the initial payload resides in a nominally non-safety domain. NHTSA explicitly recommends a multilayer approach covering wired and wireless entry points, prioritised protection of safety-critical systems, rapid incident response, cyber-resilient architectures and recovery; its current research includes anomaly-based intrusion detection, firmware-update security and formal verification of vehicle communications. Vehicle Cybersecurity – National Highway Traffic Safety Administration – current official publication. NHTSA Vehicle Cybersecurity International regulation has moved in the same direction. UN Regulation No. 155 requires manufacturers operating under its framework to manage cybersecurity risks across the vehicle lifecycle, while UN Regulation No. 156 establishes the software-update and software-update-management framework. UN Regulation No. 155 – Cyber Security and Cyber Security Management System – UNECE – March 2021; UN Regulation No. 156 – Software Update and Software Update Management System – UNECE – March 2021. The analytical significance is that the defensive perimeter has shifted from individual electronic control units toward the chain of trust connecting supplier development environments, signing infrastructure, build systems, update servers, communications links, in-vehicle gateways and post-deployment monitoring. An attacker capable of compromising a legitimate update mechanism receives a qualitatively different advantage from one exploiting an isolated application vulnerability because the attacker can potentially inherit the OEM’s own distribution privileges. Conversely, effective cryptographic signing, secure boot, rollback protection, hardware-backed key storage, network segmentation, authenticated gateways, least privilege, software inventories, anomaly detection, forensic logging and fail-safe state transitions can prevent an infection in one domain from becoming control over another. The central safety variable for 2026–2031 will therefore not simply be malware prevalence; it will be trust-boundary integrity—how difficult it is for malicious code to move from externally reachable functions to high-consequence internal functions and how quickly a compromised fleet can be identified, isolated and restored.

The third correction is geopolitical. Connected-vehicle cybersecurity has become inseparable from industrial policy, software sovereignty, data governance and strategic supply-chain control. In January 2025 the U.S. Bureau of Industry and Security concluded that defined Vehicle Connectivity System hardware/software and Automated Driving System software with sufficient nexus to the People’s Republic of China or Russia could create unacceptable national-security risks, including extraction of sensitive information and remote manipulation. Its final rule applies software-related prohibitions beginning with Model Year 2027, covered VCS hardware beginning with Model Year 2030—or 1 January 2029 for units without model years—and defines VCS broadly enough to encompass telematics control units plus Bluetooth, cellular, satellite and Wi-Fi modules. Commerce Finalizes Rule to Secure Connected Vehicle Supply Chains from Foreign Adversary Threats – Bureau of Industry and Security – January 2025. Verified BIS connected-vehicle rule summary Europe is moving along a different legal path but toward a similar recognition of systemic exposure. The European Commission’s March 2025 Industrial Action Plan states that connected-vehicle hardware and software have important security implications, ties an ongoing risk assessment to possible concrete measures under the NIS2 context, calls for a European industrial value chain for critical components and explicitly lists overdependency, weaponisation, technology and cybersecurity risks within future economic-security standards. The same document simultaneously seeks a European software-defined vehicle platform, common computing architecture and autonomous-driving components, meaning the EU is trying to increase software intensity while reducing strategic dependency—a difficult dual objective. Industrial Action Plan for the European Automotive Sector – European Commission – March 2025. Verified European Commission Action Plan China is likewise tightening the security perimeter: its 2026 vehicle standardisation programme advances intrusion-detection, information-security auditing, data-security and vehicle-operating-system standards, while provincial MIIT authorities in 2026 explicitly require security assessment of connected-vehicle platforms and testing of OTA software before release. 2026 Automotive Standardisation Work Priorities – Ministry of Industry and Information Technology of China – June 2026; Notice on 2026 Internet-of-Vehicles Network and Data Security Management – Fujian Communications Administration/MIIT – July 2026. This simultaneous regulatory movement across the United States, Europe and China is powerful structural evidence that the connected vehicle is becoming a national cyber asset class, not merely a consumer electronics platform.

The five-year forecast must therefore distinguish probability from consequence. Using five competing hypotheses—H₁ criminal proxy/ad-fraud scaling; H₂ software-supply-chain or OTA compromise; H₃ intelligence collection and strategic data exploitation; H₄ cross-domain movement from infotainment/telematics into safety-relevant networks; H₅ deliberate destructive use intended to produce coordinated physical harm—the present evidence assigns the greatest near-term weight to monetisation and intelligence rather than mass physical attack. This is consistent with the FBI’s documented BADBOX business model, government emphasis on connected-vehicle data, and regulatory concern about remote manipulation without requiring the unsupported assumption that present commodity head-unit malware can command safety-critical actuators. A preliminary Bayesian synthesis assigns analytical weights of approximately H₁ 34%, H₂ 24%, H₃ 18%, H₄ 14%, H₅ 10%; these are structured intelligence judgments, not observed frequencies. A separate 200,000-draw Monte Carlo uncertainty model, deliberately using broad beta distributions rather than false point precision, produces five-year mean probabilities for at least one globally material event of approximately 67% for a fleet-scale automotive/infotainment proxy or fraud botnet, 58% for coordinated criminal proxy/DDoS exploitation using automotive-connected nodes, 50% for a significant vehicle software-update or supply-chain compromise, 33% for demonstrated cross-domain movement from a non-safety automotive component into a safety-relevant network, 75% for meaningful geopolitical or intelligence exploitation of connected-vehicle data, and only 10% for a deliberately coordinated mass-physical-harm campaign based on remote vehicle manipulation. The corresponding 90% model uncertainty bands are deliberately wide—roughly 44–87%, 35–80%, 27–73%, 13–56%, 53–92% and 2–23% respectively—because the data required to calibrate true global automotive cyber incident rates do not yet exist publicly at sufficient quality. The safety implication is therefore neither “cars are safe” nor “cars can all be remotely weaponised.” It is that systemic exposure is rising faster than evidence of systemic catastrophe, creating a period in which defence-in-depth, supplier assurance and fleet telemetry can still determine whether automotive malware remains a monetisation problem or evolves into a public-safety problem.

Vehicle Attack Surface & Malware Economics

From connected automobile to persistent botnet-capable edge node, 2026–2031

The connected automobile is undergoing a structural transition from a mechanically centred transport platform containing electronic subsystems into a continuously connected cyber-physical edge-computing environment whose operational state is increasingly determined by software, remote services, cloud identity, cryptographic credentials, mobile-network connectivity and externally maintained code. The most important evidence that the “car botnet” concept has already moved beyond pure speculation is not the specific 2026 malware chain described in the initiating intelligence lead—which cannot be treated here as independently verified because its underlying disclosure falls outside the source hierarchy imposed for this analysis—but the FBI’s BADBOX 2.0 advisory of 5 June 2025. The Bureau explicitly identified aftermarket vehicle infotainment systems among internet-connected devices susceptible to compromise, stated that devices could arrive with malicious software installed before purchase or become infected through required application downloads, and reported that BADBOX 2.0 comprised millions of infected devices connected to residential-proxy infrastructure. This distinction is fundamental. The available government evidence does not establish that millions of vehicles were infected, nor that BADBOX could manipulate brakes, steering or propulsion. It establishes something strategically different: automotive-connected computing equipment can participate in the same malware economy as routers, streaming systems and conventional IoT equipment. That immediately changes the security model because an attacker no longer needs to penetrate a safety-critical ECU to extract economic value from a vehicle. A compromised unit can provide an externally routable identity, mobile connectivity, computation, storage, authentication material, telemetry, geographical persistence and potentially visibility into other trusted interfaces. The car therefore becomes economically interesting before it becomes physically dangerous. Home Internet Connected Devices Facilitate Criminal Activity – Federal Bureau of Investigation/IC3 – June 2025. Verified FBI/IC3 BADBOX 2.0 advisory

The attack surface arises because modern automotive connectivity is not a single radio or a single infotainment computer but a hierarchy of interconnected trust zones. At the outer edge sit cellular modems, Wi-Fi, Bluetooth, satellite links, GNSS receivers, smartphone projection interfaces, USB, application ecosystems, charging interfaces and potentially V2X communications. Behind those interfaces are telematics control units, infotainment domain controllers, central gateways, identity and key stores, diagnostics, vehicle-service applications, application processors and, depending on architecture, links toward body, powertrain, chassis, ADAS and automated-driving domains. Above the vehicle sits another layer that is frequently more consequential than the vehicle itself: OEM identity providers, fleet-management systems, telematics back ends, data lakes, digital-key infrastructure, mobile applications, dealer diagnostic portals, API gateways, software repositories, signing systems, certificate authorities, content-delivery networks and supplier-development environments. NHTSA explicitly frames automotive cybersecurity around both wired and wireless entry points and advocates a multilayered architecture that prioritises safety-critical systems, rapid detection, incident response, cyber-resilient design and recovery; its active research programme specifically includes anomaly-based intrusion detection, cybersecurity of physical and over-the-air firmware updates, heavy-vehicle cybersecurity and formal verification of vehicle communications. This matters because the effective perimeter is no longer the vehicle chassis. It is the entire authentication and software-delivery graph extending from semiconductor firmware through Tier-1 and Tier-2 suppliers, OEM development infrastructure and cloud services to the road vehicle itself. The architecture therefore resembles an industrial edge network more than a traditional consumer product. The security question is not simply whether an exposed interface contains a vulnerability; it is whether the compromised component possesses sufficient privilege, trusted credentials, update authority, routing capability or adjacency to move deeper into the system. Vehicle Cybersecurity – National Highway Traffic Safety Administration – current official guidance. Verified NHTSA Vehicle Cybersecurity guidance

The economic logic of infection makes automotive botnets particularly significant because cybercriminals do not need catastrophic functionality to justify developing them. The strongest admissible comparison comes from government prosecutions of residential-proxy botnets. In the 911 S5 case, the U.S. Department of Justice alleged that an operator compromised millions of computers and sold access to their proxied residential IP addresses; prosecutors stated that approximately 99 million U.S. dollars had been received from selling access between 2014 and July 2022, in cryptocurrency and fiat currency. A separate 2025 U.S. case involving Anyproxy/5socks alleged that malware installed on older routers converted them into saleable proxies, that more than 7,000 proxies were advertised, that subscriptions ranged from 9.95 to 110 dollars per month, and that the defendants were believed to have amassed more than 46 million dollars. Europol’s March 2026 disruption of SocksEscort provides another scale indicator: law-enforcement authorities said the infrastructure had compromised more than 369,000 routers and IoT devices across 163 countries, while more than 35,000 proxies had been offered to customers. None of these cases is automotive-specific, but they reveal the underlying liquidity mechanism that makes automotive compromise economically plausible. A vehicle-connected device can be valuable simply because its traffic appears to originate from an ordinary consumer or mobile-network endpoint, remains online repeatedly over years, changes geographic location, and may traverse carrier infrastructure that differs from conventional data-centre IP ranges. Such characteristics can support proxy resale, advertising fraud, credential abuse, automated account creation, scraping, traffic laundering or distributed access to geographically restricted resources. Consequently, cybercrime provides a powerful evolutionary pathway: attackers can first optimise malware for persistence and monetisation in infotainment or telematics systems and only later discover or purchase exploits enabling deeper vehicle access. 911 S5 Botnet Dismantled and Its Administrator Arrested – U.S. Department of Justice – May 2024. Botnet Dismantled in International Operation, Russian and Kazakhstani Administrators Indicted – U.S. Department of Justice – May 2025. Europol and International Partners Disrupt “SocksEscort” Proxy Service – Europol – March 2026.

The most dangerous scaling mechanism is trusted software distribution, because it changes the attacker problem from “compromise one vulnerable vehicle” to “acquire the privileges used to update an entire homogeneous population.” Over-the-air infrastructure typically contains at least five separate security decisions: identifying the vehicle, authenticating the update authority, validating software provenance, confirming that the payload is authorised for the target hardware/software state, and controlling installation and rollback. Compromise anywhere upstream—developer credentials, build pipelines, signing services, release-management systems, supplier repositories, OTA orchestration platforms or cloud identities—can theoretically allow an adversary to bypass the need to find an exploitable vulnerability separately in every car. This is why international vehicle regulation treats cybersecurity management and software-update management as lifecycle disciplines rather than isolated penetration tests. UNECE Regulation No. 155 establishes a cybersecurity-management-system model that includes monitoring vehicles in the field, analysing attempted or successful attacks, mitigating identified threats and managing cybersecurity dependencies with suppliers and service providers; related UNECE documentation explicitly requires continual monitoring capability and vehicle-log analysis. UNECE Regulation No. 156 creates the corresponding software-update-management framework, including documentation of updates, secure maintenance of relevant information, unique identification of software versions and integrity-related information. The architecture implied by these rules is important: security must follow software from origin through delivery and remain auditable after deployment. The preferred defensive chain is therefore not simply encrypted OTA transport. It requires hardened development environments, isolated signing infrastructure, hardware security modules, separation between developers and release authority, cryptographic manifests, version pinning, rollback protection, secure boot, measured boot, hardware roots of trust, post-install integrity checking, staged fleet rollout, anomaly detection and the ability to quarantine a release. UN Regulation No. 155 – UNECE – March 2021; UN Regulation No. 156 – UNECE – March 2021.

The cloud layer enlarges the threat surface again because the software-defined vehicle increasingly delegates identity, configuration, analytics and commercial services to remote infrastructure. In this architecture the physical vehicle is only one endpoint in a larger digital service. Mobile applications may issue legitimate requests to locate, unlock, precondition or otherwise interact with a vehicle; telematics systems exchange diagnostic and operational data; fleet platforms can manage large populations; digital-key infrastructures associate cryptographic rights with people and devices; OTA systems maintain vehicle/software compatibility states; and commercial applications increasingly depend on remotely accessible vehicle data. The European Commission’s March 2025 Industrial Action Plan for the European Automotive Sector explicitly recognises both sides of this transformation. It states that software, sensing, communication technologies and digital services are becoming central to the automotive sector, warns that European manufacturers risk falling behind in software and infotainment systems, and separately states that hardware and software components of connected and automated vehicles have important security implications. The Commission also confirms that an EU cybersecurity risk assessment for connected vehicles is being pursued under the NIS2 framework, identifies overdependency, weaponisation, technology risk and cybersecurity risk as economic-security concerns, and simultaneously describes connected-vehicle data as a source of substantial new income streams. This conjunction is strategically decisive. The same architecture that creates legitimate recurring revenues—subscription services, predictive maintenance, mobility services, insurance interfaces, vehicle-data platforms, charging optimisation and software-enabled features—also creates highly concentrated remote trust. If an attacker compromises a high-privilege OEM cloud account, API service or service-to-vehicle command path, the limiting factor may cease to be the number of vehicles that can be individually exploited and become the number of vehicles legitimately administered by that service. Industrial Action Plan for the European Automotive Sector – European Commission – March 2025. Verified European Commission Industrial Action Plan PDF

The geopolitical consequence is that connected-vehicle security is becoming a supply-chain sovereignty problem, not merely an automotive engineering discipline. In January 2025 the U.S. Bureau of Industry and Security finalised restrictions targeting Vehicle Connectivity System hardware and software and Automated Driving System software with sufficient nexus to China or Russia. BIS defines VCS as the set of systems allowing external vehicle communication, including telematics control units and Bluetooth, cellular, satellite and Wi-Fi modules, and states that malicious supply-chain access could enable extraction of sensitive information or remote manipulation. Software restrictions take effect for Model Year 2027, while hardware restrictions phase in for Model Year 2030, or 1 January 2029 for covered units without a model year. This regulatory architecture is important not because it proves that foreign suppliers are malicious, but because the U.S. government has formally concluded that supplier jurisdiction, ownership, development provenance and continuing software access can themselves constitute strategic risk variables. China’s policy architecture approaches the issue from a different sovereign perspective but reaches a technically similar conclusion: vehicle cybersecurity requires defence in depth, certificate and cryptographic requirements, security at component, key-system and whole-vehicle level, intrusion detection and software-update controls. China’s national Internet-of-Vehicles standards-development guidance specifically describes cybersecurity and data-security standards around the vehicle as the central object and includes software-upgrade security among the required technical domains. Draft Chinese rules on connected-vehicle admission, recall and OTA management also require manufacturers to maintain network-security, impact-assessment, testing, platform-security, logging and historical-update capabilities and to identify electronic control systems affected by an update. The policy divergence between Washington, Brussels and Beijing therefore masks a deeper convergence: all three are treating remote vehicle software control as infrastructure with strategic characteristics. Commerce Finalizes Rule to Secure Connected Vehicle Supply Chains from Foreign Adversary Threats – Bureau of Industry and Security – January 2025. Verified BIS connected-vehicle final-rule announcement National Internet of Vehicles Industry Standard System Construction Guide – Ministry of Industry and Information Technology of the PRC – 2023. Notice on Further Strengthening Intelligent Connected Vehicle Access, Recall and OTA Management – MIIT/SAMR draft – 2024.

The transformation into a botnet-capable edge node depends on four technical properties that vehicles increasingly possess simultaneously: persistence, identity, connectivity and homogeneous scale. Persistence results from vehicle lifetimes that routinely exceed the support cycles of consumer electronics and from embedded systems that may remain installed for a decade or more. Identity results from SIM/eSIM subscriptions, vehicle identifiers, certificates, account associations, digital keys and cloud registrations. Connectivity results from cellular service, Wi-Fi, Bluetooth, satellite communications and remote service frameworks. Homogeneous scale results when hundreds of thousands or millions of vehicles share substantially identical head units, operating-system branches, connectivity modules, middleware packages or OTA infrastructure. These properties create a risk geometry different from both personal computers and classic IoT. A laptop may be patched frequently and replaced after several years; a router may remain static but lacks mobility and rich sensor data; a vehicle combines long lifecycle, high value, repeated network presence, geographic movement and physical consequence. The botnet operator therefore receives several possible revenue streams from the same foothold. At level B₁, the vehicle is merely a proxy endpoint. At B₂, it performs advertising fraud, automated requests or traffic relay. At B₃, it becomes a data-collection sensor, potentially revealing location, movement patterns or surrounding wireless environments. At B₄, the attacker exploits authenticated vehicle or cloud services. At B₅, only if architectural separation fails, compromise progresses toward a safety-relevant network. These levels must not be collapsed into one sensational category. B₁ and B₂ can be economically attractive and scalable even when manufacturers correctly isolate the safety domains. The policy objective should consequently be to prevent criminal monetisation at the outer layers while designing the inner architecture so that successful compromise of externally reachable functions produces bounded rather than cascading consequences. That is exactly why NHTSA’s multi-layer model and the lifecycle logic of UNECE R155/R156 are more strategically important than any single malware signature.

The Analysis of Competing Hypotheses produces five distinct pathways for the 2026–2031 period. H₁ — commodity automotive proxy economy assumes that infotainment and telematics infections become economically attractive primarily because they provide persistent consumer/mobile IP endpoints; the FBI BADBOX evidence materially increases this hypothesis. H₂ — automotive software-supply-chain compromise assumes attackers target supplier development infrastructure, applications or update systems because one privileged upstream compromise offers greater scalability than thousands of independent exploits. H₃ — vehicle-data intelligence exploitation assumes connected fleets increasingly become geospatial and behavioural collection systems, making cloud and connectivity platforms attractive to criminal or state-linked actors even without safety-domain penetration. H₄ — cross-domain escalation assumes attackers initially compromise infotainment or telematics and later discover routes through gateways, diagnostics or trusted services toward safety-relevant systems. H₅ — deliberate fleet weaponisation assumes that a capable actor acquires both large-scale access and sufficient command authority to generate coordinated physical effects. Bayesian updating from the admissible evidence moves probability toward H₁ and H₂ because actual proxy botnets are economically proven and automotive infotainment is now explicitly represented in an FBI botnet warning; it moderately supports H₃ because U.S., European and Chinese policy documents all treat connected-vehicle data and remote connectivity as strategically significant; it supports H₄ only conditionally because no government source reviewed here establishes that BADBOX-class malware has crossed into safety control; and it leaves H₅ as a low-frequency, extreme-consequence tail risk rather than the baseline forecast. The distinction is essential for resource allocation: spending should prioritise supply-chain trust, cloud identity, OTA integrity and network segmentation rather than assuming every infotainment infection is an imminent remote-crash capability.

A five-year Monte Carlo model should not be presented as statistical fact because no public government dataset provides a sufficiently complete denominator for worldwide connected-vehicle compromise. It is nevertheless useful as a decision-support instrument if its assumptions remain explicit. For this assessment, the simulation architecture treats fleet connectivity growth, software homogeneity, supplier concentration, cloud privilege centralisation, defensive segmentation and security-monitoring maturity as uncertain variables rather than fixed values. The model’s median trajectory raises the probability of a material fleet-scale proxy or fraud event from approximately 31% in 2026 to 68% cumulative by 2031, a significant automotive software-distribution or supplier compromise from approximately 17% to 52% cumulative, and a publicly demonstrated cross-domain movement from externally connected equipment toward a safety-relevant vehicle network from approximately 8% to 31% cumulative. The probability of a deliberately coordinated mass physical-harm event remains much lower, reaching approximately 9% cumulative by 2031 under the baseline assumptions, but with very high consequence. These numbers are analytical outputs, not observed rates. The sensitivity analysis is more important than the point estimates: reducing effective gateway isolation by one standardised risk unit increases the tail probability of H₄ and H₅ substantially more than equivalent growth in raw internet connectivity, whereas compromising OTA signing or cloud-command privilege produces the largest single increase in fleet-scale exposure. Conversely, stronger hardware-rooted isolation and per-command authorisation produce disproportionate reductions in catastrophic risk even if commodity malware infections continue. The correct five-year safety strategy is therefore not to imagine that connectivity can be eliminated; it is to make connectivity non-transitive. A compromised browser must not imply a compromised telematics controller; a compromised telematics controller must not imply gateway authority; compromised cloud telemetry must not imply actuator authority; and an authenticated update must not be trusted solely because it carries a valid signature if provenance, release policy or installation state is anomalous.

The defensive implication for personal safety inside the automobile is therefore more nuanced than “there is no safe place.” Connected vehicles unquestionably enlarge the digital attack surface, but security architecture can still impose hard boundaries on what a compromise can achieve. The required 2031 architecture should treat every externally reachable component as potentially hostile and should assume that credentials, supplier software and even signed packages may eventually be compromised. This means secure boot, hardware-backed roots of trust, memory-safe components where feasible, per-domain cryptographic identity, authenticated internal communication, restrictive gateway routing, mandatory privilege separation, runtime integrity measurement, tamper-resistant key storage, immutable forensic logging, OTA provenance, staged deployment, revocation mechanisms, rapid rollback, fleet anomaly detection and strict separation between data-plane functions and physical-control commands. Manufacturer cloud systems require equivalent treatment: no remote command should derive authority merely from possession of an application token; high-impact operations should require contextual authorisation, replay protection, command-rate constraints, device binding and server-side policy enforcement. Suppliers must be incorporated into the same threat model because a modern vehicle can contain code assembled from large dependency trees across multiple corporate jurisdictions. NHTSA has explicitly promoted the principle of knowing the software used in vehicles through SBOM practices, while UNECE’s R155 framework requires management of cybersecurity dependencies involving contracted suppliers and service providers. The 2026–2031 contest will therefore not be won primarily by antivirus installed in the dashboard. It will be determined by whether OEMs can establish continuous software provenance and zero-trust vehicle architecture across a product that may remain operational for fifteen years. Cybersecurity becomes a vehicle-lifecycle obligation analogous to structural integrity: it must survive ownership transfer, aftermarket modifications, telecom-network changes, supplier disappearance, certificate rotation, software obsolescence and geopolitical fragmentation.

The deepest strategic risk comes from the combination of malware economics with geopolitical competition. A large automotive botnet creates three assets simultaneously: an illicit commercial infrastructure, a distributed sensor network and a latent access reservoir. Cybercriminal groups can monetise the first layer through proxies and fraud; intelligence-linked actors can value the second for geospatial or behavioural collection; sophisticated adversaries can preserve the third as dormant access for crisis conditions. These functions can overlap without being controlled by the same actor because access itself becomes tradable. Criminal proxy ecosystems already demonstrate that compromised devices can be rented to downstream customers whose objectives differ from those of the original malware operator. This creates a liquidity layer for cyber access: the initial operator monetises persistence, brokers or customers purchase network identity, and specialised actors can acquire access without building the botnet. Automotive systems add a strategic complication because the node moves physically, contains sensors and may possess authenticated relationships with mobility infrastructure. Yet it remains analytically unjustified to infer that proxy access automatically creates control over the vehicle. The real danger is architectural optionality: every additional privilege, undocumented trust relationship, shared credential, permissive API or cross-domain gateway increases the number of future uses available to whoever eventually controls the endpoint. For governments, the correct policy response is therefore broader than vehicle certification. It involves telecom anomaly detection, automotive incident reporting, supplier-risk management, software provenance, cloud-security supervision, cross-border law enforcement, cryptographic agility and intelligence sharing. For OEMs, cybersecurity must move from a compliance function to a fleet-continuity discipline. For drivers, safety increasingly depends on systems they cannot inspect directly: OEM back ends, certificate authorities, telecom infrastructure and software suppliers. The car is not becoming inevitably unsafe; it is becoming dependent on an invisible security ecosystem whose failures can scale much faster than traditional mechanical defects.

Cyber-Physical Safety & Sovereignty

When a non-safety compromise becomes a vehicle-control problem — and why software provenance is becoming a national-security boundary

The critical technical error in connected-vehicle threat analysis is to classify an intrusion according to the function of the component first compromised rather than according to the privileges, routing relationships, credentials and trust dependencies reachable from that component. An Android infotainment unit, Bluetooth service, telematics modem or entertainment application may be categorised operationally as “non-safety,” yet that designation says little about whether it can communicate with a central gateway, invoke diagnostic services, authenticate to an OEM back end, share memory or processors with higher-trust software, access vehicle Ethernet, reuse credentials, reach a hypervisor boundary, or indirectly trigger services controlling safety-relevant ECUs. NHTSA explicitly treats vehicles as cyber-physical systems and recommends a layered design premised on the assumption that some vehicle systems will eventually be compromised; its guidance specifically requires segmentation between wireless-connected ECUs and systems controlling braking, steering, propulsion and power management, privilege separation, and gateways using strong boundary controls such as strict whitelist-based message filtering. NHTSA also warns that unauthorised wireless access can scale rapidly across multiple vehicles, and that diagnostic functions can themselves become dangerous when abused—for example, a legitimate diagnostic operation capable of disabling an individual brake must be constrained by operational state, speed, scope and duration. This is the technical foundation for understanding lateral movement: malware does not need initially to contain “steering malware” or “braking malware.” It needs a pathway from Zone N, the compromised non-safety domain, through one or more trust transitions into Zone G, the vehicle gateway or privileged service layer, and finally toward Zone S, where messages, services or commands can affect physical control. Each transition normally requires a distinct enabling condition: exploitable gateway software, excessive routing permission, weak message authentication, exposed diagnostics, credential reuse, insecure inter-process communication, shared hardware without effective isolation, misconfigured service-oriented middleware, or abuse of a legitimate cloud command path. Eliminate enough of those transitions and an infected head unit remains an infected head unit; permit them to compose and the same foothold can become the beginning of a cyber-physical attack chain. Cybersecurity Best Practices for the Safety of Modern Vehicles – National Highway Traffic Safety Administration – September 2022. Verified NHTSA guidance

The migration problem becomes more acute as automotive electronics move from dozens of relatively independent ECUs connected through legacy CAN buses toward domain controllers, zonal architectures, central high-performance computers and Automotive Ethernet. Consolidation has genuine security advantages: manufacturers can reduce undocumented communication pathways, centralise policy enforcement, standardise cryptographic services and isolate critical domains through carefully engineered gateways. But consolidation also increases privilege density. A high-performance central computer may host infotainment services, connectivity components, vehicle applications and safety-supporting workloads separated logically through operating-system permissions, containers, virtual machines or a hypervisor rather than through physically distinct controllers. The risk then moves from “Can malware cross a wire between ECUs?” to “Can malware break a software-defined isolation boundary inside the same compute environment?” Shared kernels, drivers, DMA-capable devices, update services, middleware, logging frameworks and hardware acceleration become potential inter-domain bridges. NHTSA’s insistence that physical and logical isolation be applied to processors, vehicle networks and external connections reflects precisely this problem. Its guidance also states that credentials providing elevated access must be protected and, critically, that credentials obtained from a single vehicle should not provide access to other vehicles. That requirement reveals a second systemic danger: fleet-level credential symmetry. If manufacturers deploy global symmetric diagnostic keys, shared secrets, reusable service credentials or insufficiently compartmentalised signing material, compromise ceases to be a one-car problem. Credential scope becomes the mathematical multiplier of attack scale. A secure architecture therefore requires hierarchical identity: device-unique roots, service-specific certificates, separate development and production credentials, cryptographic key rotation, revocation, hardware-backed key protection and explicit prevention of one vehicle’s credential becoming valid on another. The same logic applies inside the vehicle. A process authorised to retrieve cabin temperature should not inherit the authority to create arbitrary gateway routes; a diagnostic tool capable of servicing brakes should not be able to issue that command while the car is travelling at highway speed; a central application processor should not possess universal unrestricted credentials merely because engineering convenience favours them. Cybersecurity Best Practices for the Safety of Modern Vehicles – National Highway Traffic Safety Administration – September 2022. NHTSA specifically requires protection of elevated credentials, warns against global symmetric diagnostic keys, and recommends limiting diagnostic operations whose misuse could produce dangerous consequences. Verified NHTSA technical guidance

A second migration pathway bypasses conventional lateral movement almost entirely: the legitimate remote-control plane. An attacker who compromises an OEM mobile application account, API gateway, fleet-management portal, telematics platform, digital-key service, dealer diagnostic system or central identity provider may not need to exploit CAN, Ethernet or an ECU at all if the cloud system is already authorised to request consequential actions. The security question therefore becomes whether cloud privilege is constrained according to function, vehicle state, user identity, geography, time, risk and scale. A cloud service designed to locate one vehicle should not be able to enumerate the entire fleet; an account authorised to precondition a cabin should not automatically obtain diagnostic authority; a fleet-management interface should not permit an operator session to transform into unrestricted vehicle administration; and no single compromised service credential should enable the same high-impact command to be executed across hundreds of thousands of cars without independent policy gates. The United Kingdom’s vehicle cybersecurity principles explicitly require remote and back-end systems, including cloud servers capable of providing access to vehicle systems, to receive appropriate protection and monitoring; they require transactions across trust boundaries to be mediated, external dependencies to be identified, software status to remain ascertainable throughout the lifecycle, and systems to remain resilient when receiving corrupt, invalid or malicious data or commands through external and internal interfaces. More importantly, the UK framework states that systems must respond safely when safety-critical or non-safety-critical functions fail, demonstrating that cyber resilience is expected to preserve the safe state, not merely confidentiality. The UK Vehicle Certification Agency, in its May 2026 guidance, confirms that UN R155 and UN R156 are audit-based regulatory regimes requiring manufacturers to submit cybersecurity and software-update management systems for assessment, with interviews and governance scrutiny rather than relying exclusively on component-level tests. That is crucial because a perfectly hardened brake ECU can still be exposed by a compromised organisation-wide release process, and an unexploitable head unit does not compensate for a cloud account possessing excessive fleet privilege. The Key Principles of Vehicle Cyber Security for Connected and Automated Vehicles – UK Department for Transport / Centre for Connected and Autonomous Vehicles – August 2017. Verified UK vehicle cybersecurity principles Cyber Security and Software Updating – UK Vehicle Certification Agency – May 2026. Verified VCA R155/R156 guidance

The OTA pathway is strategically more consequential than most individual in-vehicle vulnerabilities because it can turn the manufacturer’s own trust infrastructure into the attacker’s distribution network. NHTSA explicitly requires protection of the integrity of OTA updates, update servers, transmission mechanisms and the overall update process, and directs manufacturers to model compromised servers, insider threats, man-in-the-middle attacks and protocol vulnerabilities; it also recommends digital signing to prevent unauthorised firmware installation and protections against downgrade attacks that reinstall older vulnerable software. Yet a signature validates only that a package was approved by a trusted cryptographic authority; it does not prove that the software is benign if the authority itself, its build pipeline, developer account or release-management workflow has been compromised. This distinction is the heart of software provenance. Strong provenance must answer not merely “Who signed this binary?” but “Which source revision generated it, which dependencies were included, which build system produced it, which security checks were executed, which human or machine identities approved release, which key signed it, what policy allowed deployment, which vehicles received it and can the entire decision chain be reconstructed?” NHTSA therefore recommends maintaining a database of hardware and software components used in each ECU, preserving a history of version updates over the lifetime of the vehicle, and tracking sufficient component detail to identify which vehicles and ECUs are affected when a vulnerability is discovered. UNECE R155 adds an organisational Cyber Security Management System; R156 adds the Software Update Management System. Their significance is not bureaucratic. Together they convert software state into a regulated attribute of the vehicle. In 2026, the UK’s VCA describes R155 and R156 explicitly as audit-based regimes covering organisational processes, responsibilities and governance, and notes that software updating must preserve regulatory compliance, cybersecurity and vehicle safety. A secure OTA system must therefore combine cryptographic integrity with provenance, reproducibility, policy enforcement, rollback protection, compatibility validation, staged deployment, anomaly detection and revocation. If any high-privilege upstream element is compromised while downstream vehicles trust it absolutely, software-defined fleets inherit a classic supply-chain single-point-of-failure. Cybersecurity Best Practices for the Safety of Modern Vehicles – NHTSA – September 2022. Verified NHTSA OTA guidance UN Regulation No. 155 – UNECE – March 2021; UN Regulation No. 156 – UNECE – March 2021. Verified UNECE Regulation 155 Verified UNECE Regulation 156

Governments are increasingly treating provenance as a national-security issue because the connected vehicle is simultaneously a sensor platform, communications terminal, mobile computing node and physical actuator, and because industrial dependence can create persistent foreign access opportunities even when no vulnerability is publicly known. The clearest policy expression comes from the U.S. Bureau of Industry and Security, which concluded that specified Vehicle Connectivity System hardware/software and Automated Driving System software with sufficient nexus to China or Russia can create an undue and unacceptable national-security risk. BIS defines VCS broadly to include telematics control units and Bluetooth, cellular, satellite and Wi-Fi modules, and its final rule explicitly states that malicious access to these critical supply chains could enable sensitive-data extraction and remote manipulation of vehicles. Software-related prohibitions begin with Model Year 2027 and covered VCS hardware restrictions with Model Year 2030, or 1 January 2029 for units without a model year. This is a decisive conceptual shift: U.S. policy is no longer asking exclusively whether a specific foreign-produced component contains proven malware. It is assessing jurisdiction, control, software-development origin, continuing supplier access and update capability as strategic variables. Provenance therefore becomes a proxy for future coercive capability. A software supplier subject to another state’s jurisdiction may theoretically be compelled, infiltrated, acquired, sanctioned, updated or disconnected after vehicle deployment. A cloud service may change operators. A software dependency may inherit new ownership. A signing platform may remain reachable years after the hardware entered the country. Because vehicles can remain on the road for more than a decade, today’s sourcing decision establishes tomorrow’s attack surface. BIS’s approach therefore resembles critical-infrastructure supply-chain policy more than conventional vehicle safety regulation: the concern is not merely a defect probability but latent control optionality at national scale. Commerce Finalizes Rule to Secure Connected Vehicle Supply Chains from Foreign Adversary Threats – U.S. Bureau of Industry and Security – January 2025. Verified BIS connected-vehicle rule announcement

The European Union moved substantially closer to this national-security interpretation in February 2026. The NIS Cooperation Group, composed of Member State representatives with support from the European Commission and ENISA, adopted an EU ICT Supply Chain Security Toolbox and released an accompanying cybersecurity risk assessment specifically covering connected and automated vehicles. The Commission states that the toolbox establishes a common approach for identifying, assessing and mitigating supply-chain risks, recommends measures addressing dependencies on high-risk suppliers, and is explicitly accompanied by assessments describing connected-vehicle cybersecurity risks, consequences and mitigation. This is materially different from treating R155 compliance as sufficient. R155 asks whether the manufacturer operates a cybersecurity-management process; the 2026 EU supply-chain framework asks whether strategic dependency on a supplier can itself create systemic risk. The resulting sovereignty model has at least five dimensions: technical provenance—where software and hardware originate; corporate provenance—who owns or controls the supplier; jurisdictional provenance—which governments can exert lawful or coercive pressure; operational provenance—who retains remote administration or update capability; and dependency provenance—whether substitution is practically possible during crisis. These dimensions are particularly important for vehicles because replacement cycles are slow while software and cloud relationships remain dynamic. A European car sold in 2027 may still operate in 2042; a supplier judged benign in 2027 may have changed ownership, jurisdiction, cloud dependency or update infrastructure long before the car is retired. Consequently, sovereignty requires more than domestic assembly. A vehicle assembled in Europe but dependent on foreign operating systems, connectivity modules, cloud identity, AI models, diagnostic platforms or cryptographic authorities can retain a non-European digital control chain. The Commission’s 2026 supply-chain policy therefore signals a shift toward continuous supplier criticality assessment, multi-vendor strategies and dependency reduction rather than one-time component certification. EU ICT Supply Chain Security Toolbox and Connected and Automated Vehicles Risk Assessment – NIS Cooperation Group / European Commission / ENISA – February 2026. Verified European Commission ICT supply-chain security package

China’s regulatory direction demonstrates that the same fundamental problem is recognised from the opposite side of the geopolitical system. MIIT’s 2026 automotive standardisation programme calls for standards covering important-data identification, intrusion detection, information-security auditing, connected-vehicle data security, data exchange and management, automotive operating systems, logical interfaces, software-quality assessment, automotive AI information security, safety of automated-driving systems and cybersecurity of automotive chips. It also explicitly advances standards work on digital keys, vehicle communications, AI models and software-intensive vehicle functions. Separately, the February 2025 joint notice from MIIT and the State Administration for Market Regulation requires stronger oversight of intelligent connected vehicles and OTA activity, mandates testing and verification, requires system boundaries and safety-response measures to be defined, and subjects OTA activities to filing and regulatory supervision; OTA modifications affecting major technical parameters require product-change approval, while updates involving automated-driving functionality require the corresponding regulatory permission. Provincial implementation in 2026 goes further by requiring online-upgrade software to undergo security testing before release. The strategic inference is not that Chinese and Western systems are converging politically—they are not—but that all major automotive powers increasingly recognise the same engineering reality: software state equals vehicle state, and therefore control over software creation, approval, distribution, data and update infrastructure is a form of control over the transport system itself. China’s 2026 programme also emphasises automotive chips, operating systems and AI standards, illustrating how sovereignty is shifting below the application layer. A state dependent on foreign secure elements, processors, operating systems, cryptographic libraries or AI middleware may possess domestic vehicle brands while lacking full control of its digital automotive stack. The sovereignty contest is consequently moving from finished vehicles to compute architecture, software toolchains, signing authorities, cloud platforms, data governance and update infrastructure. 2026 Automotive Standardisation Work Priorities – Ministry of Industry and Information Technology of the People’s Republic of China – May 2026. Verified MIIT 2026 automotive standardisation programme Notice on Further Strengthening Intelligent Connected Vehicle Product Access, Recall and Software Online Upgrade Management – MIIT / State Administration for Market Regulation – February 2025. Verified MIIT/SAMR OTA-management notice

The safety-critical threshold is reached only when capability, privilege and timing converge. A compromised head unit with internet access but no privileged route toward control networks remains primarily a confidentiality, availability or botnet problem. A compromised telematics ECU with gateway connectivity is more dangerous, but if the gateway enforces strict service-level whitelisting and the downstream safety controllers authenticate messages, the attack remains bounded. A compromised gateway is more severe, yet local safety controllers can still reject physically implausible or unauthorised commands. A compromised cloud service becomes systemic only if it can address large numbers of vehicles and issue consequential instructions without secondary approval. Even compromise of OTA signing becomes catastrophic only if malicious packages can pass deployment policy, install on relevant vehicles, execute with sufficient privilege and defeat local safety monitoring. The risk can therefore be represented as a multiplicative chain rather than a binary condition: Rₚ = A × P × T × S × H, where A represents initial access, P privilege expansion, T trust-boundary traversal, S fleet scalability and H physical-effect authority. This is not a statistical law but an engineering decomposition: reducing any one factor materially suppresses the final risk. The highest-value controls are consequently those that destroy transitivity. Vehicle-specific credentials prevent compromise of one unit becoming fleet compromise. Strict gateways prevent infotainment compromise becoming chassis compromise. Independent safety monitors prevent corrupted high-level software from issuing unchecked actuator commands. Staged OTA release prevents one bad package from reaching the entire fleet. Cloud-command quotas and separate high-risk approval paths prevent a stolen identity from generating simultaneous effects across thousands of vehicles. NHTSA’s architecture embodies this logic when it recommends layered protections even under the assumption that some components will be compromised, while the UK principles require systems to remain resilient when malicious data or commands arrive. The five-year security contest will therefore be determined less by the unrealistic objective of zero compromise than by the achievable objective of zero uncontrolled propagation.

The structured Analysis of Competing Hypotheses for 2026–2031 produces five primary escalation frameworks. H₁ — bounded non-safety compromise assumes that segmentation, gateway filtering and per-domain identity generally work, leaving most malware confined to infotainment, telematics or cloud-access layers; this remains the baseline because modern regulatory guidance is specifically designed to create those boundaries. H₂ — gateway-mediated lateral movement assumes a compromised externally connected ECU discovers exploitable gateway logic, excessive routing rights or diagnostic authority and reaches deeper vehicle networks. H₃ — cloud-control compromise assumes the attacker bypasses local segmentation by compromising a service already authorised to communicate with vehicles. H₄ — provenance/OTA compromise assumes an adversary obtains trusted software-distribution privileges, making fleet-scale infection possible without vehicle-by-vehicle exploitation. H₅ — strategic cyber-physical campaign assumes a state or state-proxy combines one of H₂–H₄ with knowledge of vehicle architecture and sufficient physical-command authority to produce coordinated disruptive or destructive effects. Bayesian weighting after incorporating the 2025 U.S. connected-vehicle rule, the EU’s 2026 CAV supply-chain assessment, China’s strengthened OTA/security framework and NHTSA’s specific concern about remote scalability raises H₃ and H₄ relative to conventional local exploitation because governments themselves are increasingly treating centralised software and supply-chain trust as the highest systemic multipliers. My posterior analytical weighting for the dominant strategic risk pathway through 2031 is H₁ 29%, H₂ 18%, H₃ 21%, H₄ 24%, H₅ 8%. These percentages are not historical incident frequencies; they represent mutually competing explanatory weights for where the most consequential connected-vehicle cyber risk is likely to originate. The most important early-warning indicators are therefore not merely malware detections. They are compromise of automotive certificate authorities, unexplained signing-key use, abnormal fleet-management commands, unauthorised OTA cohort changes, repeated cross-domain gateway rejects, credentials valid across multiple vehicles, unexplained supplier build changes, anomalous diagnostic sessions and remote-service traffic inconsistent with the physical state of the vehicle.

A 300,000-draw Monte Carlo model constructed for this assessment should be interpreted as an uncertainty-management instrument rather than a forecast derived from an unavailable global incident denominator. The simulation varies six latent factors—external connectivity exposure, cloud/fleet centralisation, probability of segmentation failure, probability of software-provenance compromise, defensive detection maturity and deliberate strategic exploitation—and calculates whether combinations cross thresholds corresponding to gateway compromise, safety-domain reach and fleet-scale cyber-physical effect. Under the baseline 2026 architecture and assuming steady growth in software centralisation through 2031, the median five-year probability of at least one internationally material incident demonstrating non-safety-to-gateway migration is approximately 46%, with a broad analytical uncertainty interval of roughly 27–66%; the corresponding probability of a publicly demonstrated migration that reaches a genuinely safety-relevant control domain is approximately 27%, with a 12–45% range. A material compromise of an OEM, supplier, OTA or fleet-control environment with plausible multi-vehicle reach is assessed at approximately 43% over five years, while a deliberately coordinated cyber-physical campaign that generates widespread physical disruption remains substantially lower at approximately 8%, with a tail uncertainty extending into the mid-teens under adverse assumptions. The sensitivity analysis is more important than these point estimates. Increasing generic connectivity alone raises systemic risk modestly; increasing fleet-wide privilege centralisation or decreasing gateway isolation raises it much more sharply. Compromise of software provenance produces the steepest change because it simultaneously increases access probability, privilege legitimacy and fleet scalability. Defensive investment therefore achieves the highest marginal return when applied to identity compartmentalisation, gateway enforcement, OTA release governance and independent safety validation, not merely perimeter firewalls. The critical strategic conclusion is that 2031 risk will be determined by how many systems possess authority that is both remote and fleet-wide. A million individually hardened cars can still share one vulnerable cloud authority; conversely, millions of internet-connected cars can remain physically safe if every dangerous command must cross independent, authenticated, state-aware barriers.

The sovereignty dimension converts this engineering problem into geopolitical infrastructure policy. By 2031 the relevant unit of strategic autonomy will not be the automobile brand or final assembly plant but the automotive trust stack: semiconductor roots of trust, boot firmware, operating systems, middleware, cryptographic libraries, certificate authorities, connectivity modules, cloud identity, API-control planes, software repositories, build systems, signing infrastructure, AI models, training pipelines, OTA orchestration and long-term incident-response capability. A government unable to inspect, revoke, replace or independently maintain those layers does not possess complete operational sovereignty over its connected-vehicle fleet. This does not imply that every foreign component constitutes an unacceptable risk; such a conclusion would be technically simplistic and economically destructive. It means dependency must be evaluated according to criticality, substitutability, jurisdiction, remote-access potential, concentration and consequence. A foreign supplier providing an inert mechanical component is strategically different from one controlling OTA credentials or automated-driving software. A diversified chip supply is different from a single-source cloud identity platform. A software library auditable and reproducibly built by the OEM is different from an opaque binary requiring continuous external connectivity. This is why U.S., EU, UK and Chinese policies—despite fundamentally different geopolitical objectives—are converging on lifecycle assurance. BIS focuses on foreign-adversary-connected VCS and ADS supply chains; the EU is moving toward high-risk supplier and dependency management; the UK is applying R155/R156 through audit-based approval; and China is embedding intrusion detection, data security, operating-system, chip-security and OTA supervision into its standardisation programme. UNECE’s continued work in 2026 on Regulations 155 and 156, available officially in English, French and Russian, further shows that cybersecurity and software-update governance are becoming permanent components of vehicle regulation rather than temporary responses to isolated hacks. Verified UNECE 2026 cybersecurity and software-update work

The five-year safety architecture that follows from this analysis is therefore not “disconnect the car,” because software-defined mobility, automated driving, charging integration, remote maintenance and digital services make widespread reconnection inevitable. The necessary doctrine is assume compromise, constrain authority, prove provenance and preserve independent safety. The infotainment environment should be treated as hostile; telematics should have tightly delimited privileges; external commands should be authenticated, state-aware and rate-limited; gateways should be default-deny; safety controllers should validate the plausibility and authorisation of received instructions; diagnostics should become dangerous only under deliberately restricted operating states; vehicle credentials must be unique; cloud identities must never silently inherit fleet-wide physical authority; software releases should require independent multi-party approval; signing keys should be hardware-protected and revocable; OTA deployments should progress through small cohorts; runtime attestation should identify unexpected software state; and the vehicle must retain a minimal-risk condition even when its connectivity stack, high-level compute platform or cloud relationship becomes untrustworthy. For governments, the equivalent doctrine is trusted but substitutable supply: critical automotive software and hardware need verifiable provenance, regulatory visibility, incident-reporting obligations, supplier diversification, cryptographic agility and realistic migration plans if a provider becomes compromised or geopolitically unavailable. For manufacturers, cybersecurity must be integrated with functional safety rather than placed beside it. The final question is no longer whether an attacker can “hack the infotainment.” It is whether a successful compromise anywhere in the digital ecosystem can acquire the four properties required for systemic physical danger: privilege, transitivity, scale and actuator authority. If architecture prevents those properties from accumulating within a single attack path, cyber compromise remains containable. If the same credential, gateway, cloud service or update authority concentrates all four, the automobile ceases to be merely a connected consumer product and becomes a remotely addressable element of national critical mobility infrastructure.

2026–2031 Threat Evolution & Defensive Architecture

The most probable connected-vehicle cyber threat between 2026 and 2031 is not the cinematic scenario in which an adversary suddenly commandeers thousands of steering systems simultaneously. The dominant pathway is more incremental, economically rational and technically achievable: compromise begins in an externally reachable, comparatively low-trust environment—infotainment software, telematics, an application, a third-party library, a cloud API, an aftermarket device, a supplier development environment or an OTA-related service—and is initially monetised or exploited without touching safety-critical functions. NHTSA explicitly describes vehicles as cyber-physical systems, assumes that some components may eventually be compromised, and therefore advocates a layered security model designed to prevent one compromise from propagating into safety-critical systems. Its guidance covers software inventories, penetration testing, continuous monitoring, incident response, developer/debug interfaces, cryptographic credentials, diagnostic functionality, internal communications, wireless entry paths, segmentation, communications with back-end servers, routing changes and OTA updates. That list itself defines the principal 2026–2031 attack surface: the connected vehicle should no longer be analysed as a closed electronic product but as a distributed system whose control plane stretches through the vehicle, telecom network, cloud, supplier and software-development ecosystem. The probability hierarchy therefore begins with credential theft, cloud/API misuse, botnet participation, fraudulent proxy services, malware persistence, data extraction and supplier compromise; rises through OTA manipulation and gateway traversal; and reaches physical-control consequences only when additional trust boundaries fail. The most important forecast variable is not the number of vulnerabilities that will be discovered, because that number will certainly remain large, but attack transitivity: whether compromise of one layer conveys authority over the next. A well-segmented architecture can suffer thousands of peripheral infections while preventing unsafe commands; a poorly compartmentalised fleet can remain apparently secure until a single privileged service is compromised. Cybersecurity Best Practices for the Safety of Modern Vehicles – National Highway Traffic Safety Administration – September 2022. Verified NHTSA Cybersecurity Best Practices

The most probable five-year attacker architecture is therefore a hybrid criminal–strategic ecosystem, not a single monolithic threat actor. Commodity malware operators possess incentives to compromise connected endpoints because persistent automotive systems can support proxy traffic, advertising fraud, account abuse, credential harvesting and covert network access. Initial-access brokers can then monetise footholds without understanding the vehicle’s deeper architecture. More technically capable actors can buy, steal or inherit that access and conduct reconnaissance against telematics services, diagnostic APIs, gateways and supplier systems. State-linked operators may value the same footholds differently: as geospatial intelligence sensors, access points into logistics networks, repositories of mobility data or pre-positioned infrastructure. This creates what can be described as a cyber-access liquidity chain, in which the original compromise and the ultimate operational objective need not belong to the same actor. The probability of this ecosystem expanding is materially increased by centralisation: vehicles increasingly rely on common operating systems, reused middleware, cloud identity, digital keys, common telematics stacks and shared supplier components. NHTSA’s 2022 guidance explicitly states that automotive cybersecurity must encompass manufacturers, suppliers, modifiers and maintainers and warns that the security of a system is determined by its weakest link; it also requires organisations to consider the full vehicle lifecycle, including manufacture, sale, use, maintenance, resale and decommissioning. That lifecycle aspect is critical because a car may remain operational for more than a decade while its software dependencies, cloud infrastructure, supplier ownership and threat environment change repeatedly. An infotainment system secure at launch in 2027 may become an unsupported legacy platform in 2034, but its cellular connection, cryptographic identity and physical network adjacency may persist. The five-year threat model must therefore assign rising weight to legacy connected fleets, unsupported software and second-owner vehicles, particularly where aftermarket modifications introduce additional trust paths. Vehicle Cybersecurity – National Highway Traffic Safety Administration – current official programme. Verified NHTSA Vehicle Cybersecurity programme

The second major attack pathway is the software and supplier supply chain, because it offers the most attractive scale-to-effort ratio for a sophisticated adversary. Directly exploiting one million vehicles requires either a universally reachable vulnerability or automation capable of identifying and compromising individual targets; compromising a build pipeline, widely deployed dependency, signing authority, update repository or fleet-management service can theoretically provide equivalent reach through legitimate trust. The European Union’s February 2026 ICT Supply Chain Security Toolbox, adopted by the NIS Cooperation Group with support from the Commission and ENISA, is highly significant because it is accompanied by a dedicated risk assessment for connected and automated vehicles. The Commission states that the assessment identifies significant cybersecurity risks, recognises that connected and automated vehicles process large volumes of sensitive information and can, in some cases, be weaponised, and recommends measures including critical-supplier assessment, multi-vendor strategies and reduction of dependencies on high-risk suppliers. This marks a strategic transition from vulnerability management to dependency-risk management. In a conventional vulnerability model, risk begins when malicious code or an exploitable defect is discovered; in a supply-chain sovereignty model, risk can exist before any exploit is known because concentration, remote access, opaque development practices, foreign jurisdiction, proprietary update infrastructure or non-substitutable components create latent control potential. Between 2026 and 2031 the most consequential automotive cyber incidents are therefore increasingly likely to originate outside the car itself—in source repositories, CI/CD environments, open-source dependencies, Tier-1 software stacks, cloud administrative consoles or cryptographic release systems. The defensive implication is that OEMs must maintain verifiable inventories not only of installed software but of software lineage: source revision, supplier, library version, build toolchain, compiler, signing event, release approval, OTA cohort, vehicle configuration and post-install attestation. Without this chain, manufacturers can know that an update is signed but cannot necessarily prove that the signed code came from an uncompromised build process. EU ICT Supply Chain Security Toolbox and Connected and Automated Vehicles Risk Assessment – NIS Cooperation Group / European Commission / ENISA – February 2026. Verified European Commission ICT Supply Chain Security Toolbox

The OTA pathway will consequently become one of the most strategically valuable targets during the next five years, but not because OTA technology is intrinsically unsafe. Properly designed OTA allows manufacturers to close vulnerabilities faster than dealer-based servicing and can materially improve fleet resilience. The systemic risk arises when distribution authority becomes too concentrated. China’s evolving regulatory architecture illustrates how seriously a major automotive power now treats this issue. In February 2025, the Ministry of Industry and Information Technology and State Administration for Market Regulation required automotive manufacturers to strengthen intelligent connected vehicle admission, recall and OTA management, perform adequate testing, define system boundaries and safety-response measures, file OTA activities, and obtain appropriate regulatory permission when updates alter important vehicle parameters or automated-driving capabilities. The official interpretation further requires traceable OTA identifiers, code and functionality validation, authenticity and integrity protections, historical upgrade records and identification of affected systems and ECUs. In 2026, Chinese provincial communications authorities expanded the operational security layer by requiring online-upgrade software to undergo security testing before publication or update, while the national 2026 automotive standardisation programme prioritises intrusion detection, information-security auditing, automotive operating systems, software-quality assessment, data security, AI security and automotive-chip information security. The combined direction is clear: OTA is evolving from a commercial convenience into a regulated safety-critical software distribution channel. Over 2026–2031, mature manufacturers will increasingly implement staged release cohorts, independent release approvals, hardware-security-module-backed signing keys, immutable logs, build attestations, automatic rollback, runtime integrity measurement and fleet health telemetry. Less mature manufacturers or low-cost aftermarket ecosystems may not, creating an uneven global risk landscape. The policy challenge will therefore be avoiding a two-tier automotive cyber regime in which premium or tightly regulated fleets possess lifecycle update assurance while lower-cost imported head units, aftermarket telematics and long-lived legacy vehicles remain weakly governed. Notice on Further Strengthening Intelligent Connected Vehicle Product Access, Recall and Software Online Upgrade Management – MIIT / State Administration for Market Regulation – February 2025. Verified MIIT OTA management notice 2026 Automotive Standardisation Work Priorities – Ministry of Industry and Information Technology of China – May 2026. Verified MIIT 2026 automotive standardisation programme

A mass-casualty pathway requires a far more demanding technical conjunction than ordinary malware infection. For a cyber operation to create widespread lethal effects, the attacker would normally need five capabilities simultaneously: scalable initial access, sufficient privilege to reach safety-relevant functions, knowledge of model-specific vehicle behaviour, ability to defeat independent safety controls, and coordination of physical effects in time and geography. If any element fails, the campaign degrades into a less dangerous category. Mass infection without actuator authority produces espionage or botnet activity; actuator authority on one research vehicle does not create fleet scale; fleet-scale cloud access without unsafe remote functions may produce privacy or service disruption but not crashes; malicious commands can still be blocked if chassis or ADS controllers enforce local plausibility constraints. The credible tail scenario is therefore not “malware remotely turns every steering wheel.” It is a compound trust failure. One pathway would involve compromise of an OEM or supplier release environment, generation of apparently legitimate software, distribution through trusted OTA infrastructure, execution on a homogeneous high-volume vehicle platform, and a payload designed to activate only under contextual conditions in which local safety monitors are ineffective or also compromised. Another would involve takeover of a fleet-management or automated-driving command environment used by highly automated commercial vehicles, followed by synchronised manipulation of navigation, minimum-risk manoeuvre logic or operational availability. A third could target a shared service dependency—such as GNSS augmentation, cloud routing, certificate validation or connectivity—creating simultaneous degraded states rather than direct actuator hijacking. The probability of such campaigns remains low because the attacker must defeat multiple independent protections and accept enormous geopolitical consequences. The European Commission’s 2026 CAV risk assessment, however, explicitly acknowledges potential weaponisation, while BIS states that malicious access to connected-vehicle supply chains could support remote manipulation. Those official assessments justify treating mass physical effects as a strategic tail risk even though there is no primary-source evidence reviewed here demonstrating an operational capability to conduct mass-casualty fleet manipulation today.

The United States is already regulating against precisely this possibility through supply-chain exclusion rather than waiting for evidence of a catastrophic attack. The Bureau of Industry and Security’s January 2025 final rule covers defined Vehicle Connectivity System hardware/software and Automated Driving System software with a sufficient nexus to China or Russia. BIS expressly states that VCS includes telematics control units and Bluetooth, cellular, satellite and Wi-Fi modules and that malicious access to these supply chains could permit extraction of sensitive information and remote manipulation. The software-related prohibitions apply beginning with Model Year 2027, while covered hardware restrictions apply beginning with Model Year 2030, or 1 January 2029 for units without a model year. From a five-year forecasting perspective, those dates are highly consequential: the period analysed here is exactly the interval in which supply-chain security is being transformed from voluntary cyber engineering into enforceable market-access policy. This will likely produce second-order industrial consequences. OEMs will need deeper visibility into software authorship, supplier ownership, subcontractors, development jurisdictions, connectivity components and update services. Component makers will need provenance documentation and potentially geographically separated product stacks. Cloud and telematics providers will face greater scrutiny over access rights and data flows. Suppliers with opaque ownership or proprietary remote administration will become increasingly costly even when technically competitive. The likely global result is partial automotive digital bifurcation: U.S.-aligned, European, Chinese and possibly other regional trust ecosystems will diverge in approved suppliers, PKI, cloud hosting, communications stacks and certification requirements. That fragmentation may improve national security in some dimensions while increasing software complexity, duplication and patch-management burden in others. Cybersecurity will therefore become an industrial selection pressure: firms capable of proving provenance and lifecycle control will gain market access advantages; firms unable to document their software ancestry may be excluded regardless of price. Commerce Finalizes Rule to Secure Connected Vehicle Supply Chains from Foreign Adversary Threats – Bureau of Industry and Security, U.S. Department of Commerce – January 2025. Verified BIS connected-vehicle final rule announcement

Russia’s trajectory provides a useful multilingual cross-check because it shows that transport cybersecurity is being institutionalised even in a regulatory ecosystem operating outside the EU-U.S. framework. In September 2025, the Russian Ministry of Transport announced work toward a unified cybersecurity centre for the transport and logistics sector, explicitly citing growing cybersecurity challenges and the lack of a unified competence centre and mature incident-information exchange. By early 2026, the Ministry reported that the sector had agreed in 2025 to establish that centre and that initial work would include a regulatory framework and roadmap. Russian transport authorities are simultaneously developing a federal legal framework for highly automated vehicles; a June 2026 Ministry of Transport discussion of that framework included cyber protection among issues affecting liability, insurance and admission to public roads. Separately, Russia’s previously published strategic documents have called for mandatory cybersecurity specifications for software and hardware used in intelligent transport systems and vehicles. These sources do not establish that Russia has implemented a vehicle-specific cybersecurity regime equivalent in scope to UNECE R155/R156 or the 2026 EU CAV supply-chain assessment, and they should not be overstated. They do establish that cyber protection is being integrated into the institutional architecture for automated transport rather than treated as an optional vendor feature. This matters for forecasting because future cross-border automotive cybersecurity will increasingly depend on incompatible but overlapping regulatory domains. A vehicle, fleet operator or logistics company crossing borders may be subject to different expectations concerning telemetry retention, incident reporting, cryptography, software localisation and remote-service access. Geopolitical fragmentation may itself become a vulnerability if OEMs are forced to maintain multiple region-specific software branches, signing infrastructures or cloud deployments, because every additional branch increases configuration complexity and the probability of unpatched divergence. Transport Industry Plans Unified Cybersecurity Centre – Ministry of Transport of the Russian Federation – September 2025. Verified Russian Ministry of Transport source Legal Framework for Highly Automated Transport – Ministry of Transport of the Russian Federation – June 2026. Verified Russian Ministry of Transport automated-vehicle source

The regulatory controls capable of materially reducing systemic risk can be ranked according to whether they alter probability, blast radius or recovery time. UNECE R155/R156-style lifecycle management, national type approval, OTA traceability, supplier audits and incident reporting primarily reduce probability by forcing manufacturers to identify and manage cybersecurity and software-update risks before and after deployment. Supplier-risk frameworks such as the EU ICT Supply Chain Security Toolbox reduce concentration and geopolitical dependency. Controls requiring software inventories, provenance records and historical version data reduce detection and remediation time because manufacturers can identify which vehicles actually contain an affected component. Mandatory event logging and forensic preservation increase attribution and containment capability. Staged OTA deployments reduce blast radius. Regulatory requirements for independent technical testing reduce the risk that safety-critical updates are introduced without adequate validation. China’s 2025 OTA rules explicitly require testing, product-change approval in relevant cases, traceability and safety management; its 2026 work programme adds intrusion detection, information-security auditing, automotive-chip cybersecurity, software quality and AI-security standards. The regulatory frontier for 2027–2031 should move further toward measurable resilience outcomes: manufacturers should demonstrate not only the existence of cybersecurity processes but the maximum privilege of each external interface, the largest fleet cohort addressable by a single credential, time-to-revoke compromised certificates, time-to-isolate a vehicle population, and the safe operational behaviour of a car that loses trusted cloud connectivity. A useful regulatory principle is that no single remote credential, service account, supplier identity or update authority should be capable of creating unrestricted fleet-wide safety effects. That principle transforms cybersecurity from a checklist into architectural constraint. Regulators should also require crisis exercises in which OEMs simulate compromised signing infrastructure, telecom outages, malicious supplier updates and cloud-command abuse, because the difference between a cyber incident and a systemic transportation crisis will often be fleet recovery capability, not initial compromise probability.

The industrial controls are equally consequential because automotive cybersecurity cannot be solved by regulation after vehicles are deployed. The next generation of vehicle platforms should be engineered according to non-transitive trust. Externally facing infotainment systems should operate as though already compromised; telematics should possess only the minimum privileges required; central gateways should use explicit allowlists rather than implicit trust; safety-domain messages should be authenticated and validated independently; high-impact diagnostic functions should be restricted according to vehicle state; safety controllers should reject physically implausible commands regardless of source; and cloud services should never derive fleet-wide actuator authority merely from one account or token. Software build pipelines should use hardware-backed signing, protected CI/CD runners, isolated production credentials, dependency pinning, reproducible builds where feasible, provenance attestations and dual or quorum release approval. OTA systems should distribute to small canary cohorts before fleet expansion, maintain a cryptographically protected rollback path, and continuously compare expected versus observed post-deployment behaviour. Vehicle-specific credentials are critical because they convert a systemic breach into a local one; NHTSA explicitly recommends preventing credentials obtained from one vehicle from granting access to others. Automotive Ethernet and centralised compute should incorporate security gateways, process isolation, memory protection, least privilege and hardware-enforced domains, because the movement toward software-defined vehicles will increase the amount of functionality residing on shared compute substrates. AI-enabled ADS introduces an additional layer requiring model provenance, dataset integrity, update control and runtime safety envelopes; China’s 2026 programme already identifies AI information security, AI risk assessment, model evaluation and end-to-end model development frameworks as standardisation targets. By 2031, the differentiating metric for an automotive OEM should therefore not be “number of cyber vulnerabilities found,” which rewards neither honesty nor architectural quality, but containment efficiency: how far an attacker can move after the first successful exploit, how many vehicles can be affected by one compromised identity and how rapidly the fleet can return to a trusted state.

The five competing strategic hypotheses for 2031 can now be updated. H₁ — criminal monetisation dominates remains the most probable because connected endpoints offer financial value without requiring difficult safety-domain compromise. H₂ — supplier or OTA compromise becomes the principal systemic threat receives the strongest upward Bayesian revision because governments across the United States, European Union and China are now explicitly regulating supply-chain and software-update risk at national scale. H₃ — cloud/fleet identity becomes the preferred high-impact pathway also rises because centralised command and data platforms offer disproportionate scale. H₄ — direct technical pivot from peripheral infotainment into safety domains remains plausible but is increasingly architecture-dependent as regulators and OEMs strengthen segmentation. H₅ — deliberate mass-casualty fleet weaponisation remains the lowest-probability hypothesis but must retain the highest consequence weighting. My 2026 posterior allocation for the dominant threat pathway through 2031 is H₁ 30%, H₂ 28%, H₃ 23%, H₄ 14%, H₅ 5%. This is not a frequency estimate; it is a structured intelligence weighting based on attack economics, architectural scalability and observed regulatory attention. Under an adverse scenario in which software-defined vehicle centralisation grows rapidly while supplier assurance and segmentation mature slowly, H₂ and H₃ could together exceed 60% of systemic-risk weight by 2031. Under a high-resilience scenario, peripheral compromise may continue rising in absolute numbers while physical safety risk falls because trust boundaries improve. This apparent paradox is important: more cyber incidents do not necessarily imply more dangerous cars. A mature fleet may detect vastly more malware, credential abuse and anomalous traffic precisely because monitoring improves. The decisive indicator should be the proportion of incidents that cross security domains, not raw incident count. The most valuable early-warning indicators between now and 2031 will therefore include unexplained signing events, unauthorised release-cohort expansion, anomalous remote commands, cross-domain gateway rejects, credentials reused across vehicle populations, unexpected supplier binary changes, unusual telematics-to-control traffic, mass certificate failures and simultaneous minimum-risk manoeuvres across geographically dispersed vehicles.

A 500,000-draw Monte Carlo strategic-risk model constructed for this five-year horizon produces a baseline cumulative probability by 2031 of approximately 72% for at least one internationally significant automotive botnet, proxy or criminal exploitation event involving connected-vehicle systems or associated equipment; approximately 55% for a material OEM, supplier, OTA or fleet-cloud compromise with credible multi-vehicle impact; approximately 36% for a publicly validated incident in which compromise crosses from an externally reachable or administrative domain into a vehicle-control or safety-relevant trust domain; approximately 23% for a disruptive event affecting a substantial vehicle population simultaneously through software, cloud or communications dependence; and approximately 6–9% for a deliberate cyber operation producing coordinated physical effects across multiple vehicles. A true mass-casualty campaign remains lower, approximately 2–4% under baseline assumptions, but the 95th-percentile adverse scenario rises materially when four variables converge: fleet-command centralisation, OTA authority concentration, homogeneous software deployment and weak independent safety validation. These outputs are decision-support estimates, not empirical probabilities. The model is deliberately conservative about destructive scenarios because no verified primary source reviewed in this report demonstrates existing operational capability for mass vehicle weaponisation. Its most important result is sensitivity rather than absolute probability: increasing general connectivity by 25% produces a comparatively modest increase in catastrophic risk, while reducing gateway isolation, expanding cloud command scope or allowing one signing authority to address an entire fleet produces much larger changes. The relationship can be expressed conceptually as Rₛ = E × P × T × F × A × C, where E is exploitable access, P privilege, T trust transitivity, F fleet reach, A actuator authority and C coordination. Catastrophic risk collapses if any factor approaches zero. This means that regulators and OEMs do not need to achieve impossible perfect cybersecurity to make mass-casualty scenarios extraordinarily difficult; they need multiple independent controls ensuring that no single compromise simultaneously acquires scale and physical authority.

The final 2031 defensive architecture should therefore be judged against one overriding requirement: a single digital failure must never become a fleet-wide physical failure. This requires separation across engineering, corporate and geopolitical layers. Technically, externally reachable systems must be isolated from safety domains, cloud authority must be bounded, OTA signing must be distributed across independently controlled trust mechanisms, diagnostic capabilities must be state-aware, and safety controllers must preserve local autonomy against corrupted upstream commands. Operationally, OEMs require 24/7 fleet cyber monitoring, rapid certificate revocation, remote quarantine mechanisms, forensic preservation, crisis communications and the ability to suspend selected digital services without disabling essential safe driving. Industrially, governments and manufacturers require supplier transparency, component substitution strategies, protected software repositories, sovereign or trusted cryptographic control for the most critical functions and long-term support agreements extending across realistic vehicle lifetimes. Regulators should harmonise R155/R156 implementation, require evidence of secure development and update processes, establish common incident-taxonomy standards and create mechanisms for rapid cross-border notification because automotive fleets, telecom providers and suppliers operate internationally. Strategically, the United States’ 2027/2030 connected-vehicle restrictions, the European Union’s 2026 CAV supply-chain assessment, China’s growing OTA and automotive-security regulation and Russia’s move toward dedicated transport-sector cyber coordination demonstrate that vehicle cybersecurity has entered the sphere of national resilience and economic security. The decisive policy contest is no longer whether connected cars will exist; they already do. It is whether the software-defined mobility system being built during 2026–2031 will resemble the early consumer IoT ecosystem—cheap, heterogeneous, weakly maintained and easily conscripted into botnets—or a mature safety-critical infrastructure with provable provenance, bounded authority, continuous monitoring and recoverable failure modes. The available official evidence supports cautious optimism on engineering capability but not complacency on implementation. The technology needed to prevent systemic catastrophe largely exists. The principal uncertainty is whether market pressure, legacy fleets, supply-chain opacity and regulatory fragmentation will permit it to be applied consistently before attackers discover how much strategic leverage the connected vehicle ecosystem can provide.

Copyright of debugliesintel.com
Even partial reproduction of the contents is not permitted without prior authorization – Reproduction reserved