Cyber assurance for a self-driving pilot

Cyber risk can become road risk

A self-driving shuttle can be safe on a test track yet unsafe to operate if an attacker can alter a map, disable a remote support service or interrupt the operator's ability to detect a fault. The applicant therefore needs evidence about the vehicle and the organisations around it. A vehicle cyber report alone cannot explain whether the dispatch centre is resilient. A corporate security certificate alone cannot show how the automated-driving system responds to a compromised sensor or update.

The Department for Transport's pilot applicant guidance treats automated-system cyber security and software updating as a parallel assessment to automated-driving capability. It also asks the operator for a detailed cyber self-assessment with supporting evidence, using the National Cyber Security Centre's Cyber Assessment Framework. The DfT points to the operator's supporting infrastructure and the information flowing between the vehicle and remote operator. These are connected but distinct assurance questions.

This guide owns the pilot's cyber evidence case across vehicle, remote infrastructure, operator and suppliers. The pilot overview owns the overall application route. A separate safety-management owner covers the broad process for maintaining all safety evidence. A future remote-assistance owner can examine the human and communications design in depth. This page explains how cyber threats and controls should be made visible to the pilot assessor and the people who will run the service.

The guidance refers to UN Regulation 155 for vehicle cyber security and UN Regulation 156 for software updating. It also refers to a draft United Nations automated-driving-system regulation that it explicitly says had not been adopted or brought into force at publication. Those references inform the assessment; they should not be collapsed into a claim that every cited standard or draft is automatically a legal obligation for every vehicle. A specialist must verify which requirements apply to the actual configuration, approval path and issued conditions.

Draw the system before scoring its security

The first useful artifact is an architecture diagram that a reviewer can follow. Show the vehicle's automated-driving system, sensors, onboard networks, connectivity equipment, update service, map supplier, dispatch system, remote-assistance interface, maintenance tools, passenger devices and emergency channels. Draw the trust boundaries: which organisation owns each component, which connections cross a network, which accounts can change a safety-relevant setting and where data are stored. The DfT guidance says applicants should be prepared to provide a supporting-infrastructure diagram showing data and information flow between vehicle and remote operator.

A simple box marked cloud is not enough. An assessor should be able to ask what happens when the link to that cloud is lost, when a credential is stolen, when a supplier account is disabled or when a map update is wrong. For each connection, record what information flows, whether it can influence motion, how the connection is authenticated, how failures are detected and what the vehicle does when the service is unavailable. That does not mean publishing secrets in a general report. Sensitive diagrams should be controlled, with an accessible summary that explains the assurance claim.

Distinguish control from advice. The pilot guidance discusses remote assistance to the automated system and says the operator should evidence that assistance is limited to advice in its proposed arrangement. A remote person who must continuously monitor and immediately control a vehicle may undermine the no-safety-driver route. Cyber analysis should identify whether a remote compromise can give an attacker commands that directly move the vehicle or merely information that the automated system can independently reject. The latter still needs testing, because misleading advice can alter a route or trigger an unsafe stop.

Map the lifecycle as well as the runtime system. A development workstation, build pipeline, signing key or diagnostic laptop may never appear in an operations diagram, yet could change the software installed on the fleet. Identify where a release is built, signed, tested, approved, installed and verified. Show how the operator knows which build is on each vehicle. A compromised update process is a road risk even if every deployed vehicle uses encrypted communications.

Separate vehicle assurance from operator assurance

The vehicle assurance case asks how the automated system and connected components are protected from credible threats. It should cover interfaces, diagnostics, software integrity, update mechanisms, vulnerability handling, monitoring and safe behaviour during a cyber-related failure. The DfT guidance says vehicle cyber assessment is informed by UN Regulation 155 and software updating by UN Regulation 156. The technical team should state the applicable approval and design evidence and explain any gaps. It should not write that a citation to a regulation proves the design is secure.

The operator assurance case asks whether the organisation can keep a fleet and its supporting services secure. The DfT guidance calls for a detailed self-assessment against the NCSC Cyber Assessment Framework, with evidence. The framework addresses managing security risk, protection against attacks, detection and minimising incident impact. It is outcome-focused, not a universal product checklist. A pilot applicant should identify the essential functions it is protecting and show how controls work for the actual vehicle and service.

For example, governance evidence may show who accepts cyber risk that can affect vehicle operation. Asset evidence may show all deployed vehicles and remote systems, including supplier-managed components. Protection evidence may show privileged access control, software integrity and resilient networks. Detection evidence may show logs and alerts for unusual commands or failed updates. Response evidence may show how the operator can safely suspend service, isolate affected systems and recover a known-good state. The applicant should connect these records to a specific route and fleet, not hand over a generic corporate cyber policy.

The operator may also be a passenger service provider. Booking, payment, support and onboard passenger systems create additional data and continuity risks. A service outage can strand people even if the automated-driving system remains technically sound. The APS permit route may impose separate conditions, and data protection law applies to personal data. The cyber case should show those interfaces without pretending that the AV pilot guidance replaces every other applicable rule.

Use a threat scenario to test the evidence chain

Consider a compromised supplier account that attempts to upload a new map. The threat analysis should identify the account privilege, approval step, code or data validation, signing process, alert, rollback path and affected vehicles. The safety analysis should describe how the vehicle behaves if the bad map reaches a live route. The operator's procedure should say who receives the alert, who can stop dispatch and how the fleet is checked. The records should show that those controls were actually tested. If a supplier holds the only log of the attempted change, the applicant needs a lawful way to obtain it quickly.

A second scenario is loss of a remote-assistance link in a location with poor coverage. Cyber assurance should establish whether the loss could be caused by an attack, equipment failure or ordinary network conditions and whether the system can detect it. Safety engineering should define the vehicle's response. Operations should show how it locates, secures and recovers the vehicle. The incident plan should identify when an event becomes externally reportable under the actual issued terms. These disciplines overlap, but each has a different piece of evidence.

A third scenario is stolen credentials for a dispatch administrator. The reviewer should ask whether the account can alter routes, suppress alerts, change vehicle assignments or view passenger data. The applicant can then show authentication controls, access reviews, privileged workstation arrangements, monitoring, rapid revocation and recovery tests. A statement that staff receive annual cyber training is useful only if it is accompanied by effective technical and operational controls for the powers those accounts hold.

Threat scenarios should be chosen from the real architecture and deployment. A small closed-campus pilot with a few vehicles may have a different exposure from a multi-area passenger fleet, but neither should assume that small scale makes cyber risk irrelevant. The DfT guidance says evidence should be risk-based and more detailed for higher-risk deployments, with factors including fleet size and the extent of operator control over vehicles. The applicant should explain why its selected depth is proportionate and what would trigger a reassessment.

Make the NCSC self-assessment auditable

The DfT guidance says the Vehicle Certification Agency will provide a Cyber Assessment Framework template. Before completing it, choose the exact organisation and services in scope. A supplier's completed assessment may help but does not automatically cover the pilot operator's dispatch, remote support or incident response. If several organisations are involved, record what evidence each supplies and who is accountable for the combined answer. The VCA or approving authority may request more evidence, such as an architecture diagram.

For each claimed outcome, link a policy to an implementation record and a test. An access-control policy might link to a current account list, a sample approval, evidence of multi-factor protection where applicable, a review of privileged access and a test showing that a leaver's account was disabled. A backup policy might link to a restoration exercise for a dispatch system. A vulnerability procedure might link to a real issue that was assessed, patched and verified. The goal is to show that a control works, not to fill a cell with a reassuring sentence.

Mark exclusions and assumptions openly. If the pilot has no passenger application, say so and show how that was confirmed. If a cloud provider controls an infrastructure layer, record its responsibility, the evidence available and the operator's remaining obligations. If a vehicle supplier has not supplied a security test result, mark it as an open item. An unresolved safety-relevant gap may block launch or limit the route. The applicant should not convert it into a green status through word choice.

The NCSC framework introduction describes the framework as outcome-focused and discourages a tick-box approach. A useful self-assessment therefore explains the outcome, relevant system, evidence, limitations and improvement owner. It should be updated when the vehicle count, connectivity architecture, remote functions or supplier arrangements change.

Control software updates and vulnerabilities

An automated vehicle may receive updates to perception, planning, maps, operating limits, remote interfaces and ordinary vehicle software. The cyber team should record how each update is authenticated, tested and deployed. The safety team should determine which claims and scenarios the update affects. The operator should know which vehicles received it and how to pause or roll back if behaviour changes. The legal lead should check whether a Vehicle Special Order condition requires notification or further assessment. These decisions should happen before rollout, not after an unexplained event.

Vulnerability handling needs a clear route from discovery to response. A researcher, supplier or operator might find a flaw. Record how reports are received, triaged, reproduced, risk-rated and remediated. If the vulnerability could enable unauthorised vehicle control or disable a safety function, the operator needs a containment decision even before a full patch is ready. Assign who informs the approving authority and insurer when relevant. The precise external notification duties depend on the incident, actual conditions and other law, so do not copy a generic deadline into every case.

A software bill of materials or component inventory may help identify affected versions, but a list is useful only if it matches deployed vehicles. Link the component to a software build and vehicle identifier. When a supplier says a vulnerability does not affect the pilot, ask for the technical reason and the configuration used to reach that conclusion. A vehicle with disabled code, a different library version or an isolated interface may indeed be unaffected, but the reason should be documented.

The DfT guidance discusses vehicle cyber monitoring and reporting with reference to UN Regulation 155. It also sets out operator cyber incident reporting expectations. The issued Vehicle Special Order and any permit may specify reportable events, conditions or recipients. The applicant should keep a condition-specific reporting matrix and have specialists verify it. A web guide cannot determine the exact reporting clock for every deployment, and an initial notification may have to precede a complete investigation.

Join cyber response to vehicle safety response

The pilot's incident plan must tell staff what to do when a cyber event may affect a moving vehicle. An alert that a dispatch server is compromised should trigger an assessment of which vehicles rely on it, what commands it can issue and whether those vehicles can reach a safe state. The safety response may be to stop new journeys, restrict routes or arrange recovery. The cyber response may be to isolate credentials, preserve logs and rebuild systems. The teams need a shared decision point so that one does not restore a service while the other still regards it as unsafe.

Make the first minutes of response practical. Who can contact the remote centre? How does the operator identify vehicles on a vulnerable build? Can staff distinguish a false alert from an actual loss of control without delaying protective action? Are emergency services given the information needed to secure the vehicle if it stops in the road? The DfT pilot guidance asks for incident management arrangements and separate first-responder information. An exercise should test the communications channels, not merely discuss them in a meeting.

Preserve evidence lawfully. Logs may include vehicle location, passenger information, camera data, staff activity and sensitive security detail. Access must be limited to people who need it, retention must be justified and the applicant should know when data may need to be shared with authorities. The cyber incident record should identify the system version, time, event sequence, affected vehicles, containment, reporting decision and restoration tests. This record can support both the technical investigation and the safety-case update.

Recovery is not just restarting servers. Confirm that the attacker no longer has access, that the software and maps are trustworthy, that the vehicle and remote systems are compatible, and that any authority or permit condition has been satisfied. A change made during response may require the same review as a planned update. Record who approved the return to service and what was tested on each affected vehicle. If a supplier cannot provide evidence of a clean build, a partial service restart should be treated as a new risk decision.

Account for suppliers and physical access

Cyber controls often fail at organisational boundaries. A map provider may update data directly, a maintainer may use a diagnostic laptop, a network operator may control connectivity and a cloud vendor may host remote-support systems. Put each supplier in the architecture and identify its privileged access, notification duty, evidence commitment and incident contact. The pilot operator needs assurance that it can revoke access and investigate a safety-relevant event even when the supplier is unavailable.

Physical access also matters. A person with an unprotected diagnostic port or maintenance credential may change a vehicle without exploiting a remote service. The DfT guidance includes physical and personnel security alongside cyber security. Control vehicle keys, maintenance devices, depots, remote centres and staff access. A vehicle left in public service may be exposed to tampering. The cyber assessment should explain how tampering is detected and how the operator decides whether the vehicle remains safe to use.

Test a supplier handoff. Ask a maintainer to replace a connectivity module, then verify that old credentials are revoked, the new module is configured correctly, the vehicle's identity and logs remain intact, and the release decision is recorded. Ask a software supplier to explain how it would notify the operator of an urgent vulnerability on a weekend. If the answer depends on one person's private message, improve the process before launch.

Contracts should specify information and response obligations without pretending that a contract clause proves implementation. The operator should periodically sample evidence: access reviews, patch status, incident exercises and the version of the architecture used in the latest assessment. If a supplier refuses a necessary test or log, record the resulting assurance gap. A no-driver pilot should not assume that outsourcing transfers all safety or cyber accountability.

A focused evidence pack for assessment

A useful submission pack contains a system and data-flow diagram, asset and supplier inventory, vehicle and operator threat assessments, security governance, privileged access evidence, update and vulnerability processes, monitoring design, incident response plan, business continuity exercise and a current Cyber Assessment Framework self-assessment. Link each record to the specific pilot vehicle, route and operator. Include a known-limitations register and a list of decisions needed from the authority. The DfT may accept or request alternative evidence, so the pack should remain adaptable rather than presenting itself as a guaranteed form.

A reviewer should be able to follow one claim end to end. For example: the remote operator cannot issue direct motion commands; the interface design restricts available messages; tests show unauthorised commands are rejected; logs show attempted commands; staff can isolate a compromised account; and the vehicle reaches a safe state when communications fail. The technical details require specialist assessment. The documentary structure helps the applicant demonstrate what was tested and what remains uncertain.

Prioritise evidence that changes decisions. A hundred policy pages are less useful than a clear diagram and a tested recovery procedure for a safety-critical connection. Equally, a penetration test is not a complete assurance case if it excludes software updates or the operator's privileged accounts. The best pack makes the boundaries explicit so that the approving authority can challenge the right controls.

Where Complys could fit

A pilot may need to track cyber evidence owners, current document versions, supplier reviews, incident actions and recheck dates. Complys could be considered for those administrative tasks only after a product demonstration verifies them. This page does not claim that Complys monitors vehicles, scans vulnerabilities, performs penetration tests, detects attacks, completes a Cyber Assessment Framework assessment or submits a regulatory report. A product owner must confirm any precise capability before publication.

In a demonstration, use a supplier vulnerability affecting one vehicle build. Ask whether the product can identify affected evidence records, assign an operator decision, preserve the earlier assessment and show what remains unresolved. If the vehicle inventory or security monitoring lives elsewhere, record that boundary and the handoff. The AV software overview supports a wider procurement discussion. The AV checker is only a regime pointer and cannot assess a cyber case.

The immediate step is to draw the real vehicle-to-operator architecture, name who owns each interface and test one failure scenario with the operations and cyber teams together. An AV cyber specialist should review the vehicle design, an operator specialist should review the remote infrastructure, and a legal reviewer should check the issued conditions. The outcome should be a defensible evidence case for this particular pilot, not a generic assertion that the company is secure.