Driverless cars: the security problems nobody has solved yet, and the controls that help

The attack surface

Four layers matter. Perception: cameras, lidar, radar and ultrasonic sensors that can be dazzled, spoofed or fed adversarial inputs — a few stickers on a stop sign, a projected image on the road, a laser aimed at a lidar unit. Planning: the machine-learning models that turn perception into decisions, which inherit every weakness of the training data and can be manipulated through data poisoning or model extraction. Vehicle networks: the CAN bus and its successors were designed for reliability, not authentication, so a compromised infotainment unit or telematics gateway can often reach braking and steering. Connectivity: cellular links, vehicle-to-everything radio, over-the-air update channels, and the cloud back-end and remote-operator consoles that supervise the fleet.

The 2015 remote compromise of a production vehicle through its cellular head unit — leading to a recall of 1.4 million cars — showed the chain from connectivity to physical control was real. Since then, researchers have demonstrated lidar spoofing that creates phantom obstacles, camera attacks that erase lane markings from the model's view, and keyless-entry relay attacks that are now routine crime. Driverless fleets add a new element: a single back-end that can, by design, issue instructions to every vehicle at once.

Why it is a governance problem, not only an engineering one

Safety and security have different cultures. Automotive safety engineering (ISO 26262) assumes random failures and designs redundancy against them; security assumes an intelligent adversary who targets the redundancy itself. A fleet operator also inherits supplier risk at a scale few industries match — sensors, compute, maps, connectivity and models come from different vendors, each with its own update cadence and disclosure practice — and a privacy problem, because a driverless car records its surroundings continuously and knows where every passenger went.

Then there is the operational centre. Remote assistance operators, fleet-management APIs, and the credentials that let an engineer push a software update are the highest-value targets in the system, and they are ordinary IT: identity, access, logging, change control. Most of what would stop a fleet-wide incident is not exotic.

The frameworks that address it

ISO/SAE 21434 sets out cybersecurity engineering for road vehicles across the lifecycle — threat analysis and risk assessment (TARA), cybersecurity goals and concepts, secure development, validation, production, operations and incident response. UN Regulation No. 155 makes a certified Cybersecurity Management System a condition of type approval in the markets that adopt it, with R156 covering software update management; together they turn vehicle cybersecurity from good practice into a licensing requirement for manufacturers.

For operators and their suppliers, the familiar frameworks still apply: ISO/IEC 27001 for the information security management system around the fleet back-end, ISO/IEC 42001 for governing the machine-learning models that drive, IEC 62443 thinking for the vehicle as an industrial control system, and the privacy laws of every jurisdiction the fleet operates in for the sensor and passenger data. In the Gulf, a fleet serving government or critical infrastructure will also fall under the national controls — NCA ECC and its OT and cloud companions in Saudi Arabia, the UAE IA Standard, Dubai's ISR — and a Malaysian operator under Act 854 if designated NCII.

Controls that actually move the risk

Segment the vehicle: gateways that enforce which network domains may talk to which, with message authentication on safety-critical buses, so a compromised infotainment unit cannot brake the car. Harden perception: sensor fusion that distrusts any single modality, plausibility checks against maps and physics, and adversarial testing of the perception models as a release gate. Secure the update path: signed and verified software, staged roll-outs, a rollback that works, and a change record that says who approved what for which vehicles. Lock down the operations centre: hardware-backed identity for remote operators, least privilege on fleet APIs, session recording, and a kill-switch procedure that has been rehearsed.

Govern the suppliers: a register of every component and model with its provenance, a software bill of materials per vehicle build, vulnerability disclosure commitments in every contract, and evidence — not assurances — that each supplier meets 21434. Monitor and respond: vehicle telemetry into a security operations function that can tell an attack from a fault, with an incident plan that covers the regulator, the safety authority and the public. And measure it: indicators such as time-to-patch a critical vulnerability across the fleet, the share of vehicles on the current software build, and the proportion of suppliers with current assurance are the kind of key risk indicators a board can act on.

Where a GRC platform fits

None of this is a product feature; it is a programme. The operator needs the 21434 and R155 obligations, the ISMS controls, the AI-governance requirements and the privacy law mapped to one control set, evidence attached to each control as it is produced, suppliers assessed in a register that feeds the third-party controls, and indicators with thresholds that turn 'we patch quickly' into a number. That is what GRCLens does for any regulated technology estate, and a driverless fleet is one of the more demanding ones — because when a control fails, the consequence is measured in metres, not records.