Autonomous Vehicle Cybersecurity and Connected Components

Published October 18, 2026

Law checked through October 18, 2026.

Vehicle cybersecurity can affect physical safety, information, certification, reporting, and supply-chain eligibility. NHTSA's cybersecurity best practices are voluntary guidance; binding duties arise from the applicable statutes, rules, orders, and contracts. Texas fleet privacy and breach requirements and the federal connected-vehicle ICTS rule require separate analyses. A secure design and a legally eligible component are different conclusions. [1; 2; 3; 4]

Map safety-relevant access

The inventory should identify vehicle controllers, sensors, radios, diagnostics, mobile applications, fleet systems, remote assistance, update infrastructure, and supplier accounts. It should distinguish access to status information from authority to change motion or safety parameters. A route-planning API and a direct control channel create different hazards.

NHTSA's guidance recommends a layered approach and addresses development, asset inventory, testing, vulnerability reporting, incident response, diagnostic access, communications, logs, and updates. The agency expressly describes the document as nonbinding and voluntary. The company should identify how recommendations apply to its architecture rather than represent the document as a mandatory certification checklist. [1, Sections 1, 4, and 8]

Binding vehicle safety duties

Chapter 301 governs applicable vehicle and equipment safety duties, including defects, noncompliance, notification, and remedies. A vulnerability capable of creating a safety-related condition requires analysis under that framework. The presence of a software cause does not remove the relevant statutory inquiry. [2]

Texas § 545.455 also requires the automated vehicle to satisfy its operating conditions, including federal compliance and fallback capability. A remote-service outage should be evaluated against the actual system design and duty rather than assumed harmless because a human can eventually be dispatched. [5]

Updates and supplier controls

NHTSA's guidance separately addresses software modifications and over-the-air updates. Recommended records identify authenticity, integrity, affected versions, installation conditions, validation, rollback, and safety consequences. A security patch may change a safety function, while delaying it can also create risk. The decision should be coordinated with the actual defect, reporting, and contractual obligations. [1, Sections 8.8 and 8.9]

Supplier agreements should address component inventories, vulnerabilities, access, notification, investigation, support lifetime, and changes. A manufacturer remains responsible for its own legal duties even where the affected software originated with a supplier. An indemnity can allocate costs without replacing a required report or remedy.

Connected vehicle sourcing

Part 791 Subpart D addresses specified connected-vehicle ICTS transactions involving the defined foreign-adversary connections. The actual definitions, prohibitions, model years, declarations, and authorization provisions determine applicability. The current connected-vehicle definition excludes vehicles above 10,000 pounds GVWR, so the rule should not be generalized to every autonomous truck. [3, §§ 791.300 through 791.321]

The assessment should identify who designed, developed, manufactured, or supplied the covered item and relevant ownership or control. A component's cybersecurity test result does not answer those eligibility questions. Conversely, a sourcing declaration is not evidence that the component has no vulnerabilities.

Personal data and incidents

Fleet information can include passenger accounts, precise location, interior imagery, and support conversations. TDPSA coverage, exemptions, controller duties, and processor agreements require the actual entity and data analysis. Texas breach notice uses different definitions and thresholds. A compromised vehicle can create a safety issue, a reportable information breach, both, or neither under a particular instrument. [4; 6]

NHTSA's crash-reporting order applies to served entities and defined qualifying events. The incident plan should separately identify order reporting, defect evaluation, privacy notice, insurance, and contractual obligations. It should not assume that one submission satisfies all of them. [7]

Evidence and operational recovery

Recommended response planning identifies who can restrict remote access, suspend vehicles, preserve logs, coordinate suppliers, and verify a safe configuration before return to service. Network isolation may affect assistance or updates, so fallback assumptions should be known in advance. The record should distinguish confirmed facts from possible causes.

A hypothetical compromised support account illustrates the sequence: secure the affected operation, identify actual permissions and commands, preserve relevant evidence, assess safety and information impacts, and evaluate each legal trigger. Resetting the password alone does not establish that the vehicle's software or calibration remains trustworthy.