The SELF DRIVE Act returns: federal AV regulation meets cyber gaps

At a glance

What this is: The SELF DRIVE Act returns as a federal attempt to standardise autonomous vehicle regulation, with safety cases, incident reporting, and written cybersecurity plans at the centre of the bill.

Why it matters: It matters to practitioners because AV governance now sits at the intersection of safety, supply-chain assurance, and identity-adjacent access controls across connected systems and vendor ecosystems.

👉 Read Upstream Security's analysis of the SELF DRIVE Act and autonomous vehicle regulation

Context

The core problem is regulatory fragmentation across autonomous vehicle operations, not a lack of technical progress. A patchwork of state rules has made nationwide deployment difficult, while the federal bill tries to replace that uncertainty with one compliance model for automated driving systems and their supporting supply chains.

This matters beyond transport policy because modern AV platforms depend on complex software, connected infrastructure, vendor access, and machine-to-machine trust boundaries. Where fleets, OEMs, and suppliers rely on credentialed access, remote updates, and telemetry pipelines, governance gaps can become operational and security gaps at the same time.

Key questions

Q: What breaks when AV regulation is fragmented across states?

A: Fragmentation forces manufacturers and fleet operators to maintain multiple control interpretations, documentation sets, and exception processes at once. That increases configuration drift, weakens auditability, and makes incident response harder because the organisation cannot rely on one common compliance baseline. The result is slower deployment and higher governance risk.

Q: Why do connected vehicles need stronger identity governance than traditional IoT devices?

A: Connected vehicles exchange safety-critical data, receive remote updates, and operate across long asset lifecycles, so identity failures can affect physical safety as well as confidentiality. Unlike many IoT devices, they must maintain trusted communication across suppliers, jurisdictions, and infrastructure layers, which makes certificate governance and revocation quality central to risk management.

Q: How do organisations know if AV cybersecurity plans are actually working?

A: They should test whether the plan can answer three questions quickly: who accessed the system, what changed, and which supplier or software path made the change possible. If the organisation cannot trace incidents back to configuration and access lineage, the plan is mostly documentation rather than control.

Q: Who is accountable when a connected vehicle incident crosses safety, cyber, and supplier boundaries?

A: Accountability should sit with the organisation that owns the operational risk, not with whichever supplier happened to be involved at the end of the chain. That requires clear ownership for access management, change control, incident reporting, and contractual offboarding so responsibility does not disappear in the handoffs.

Technical breakdown

Safety cases and federal certification for automated driving systems

A safety case is structured evidence that a system meets defined safety requirements under stated operating conditions. In the AV context, it forces manufacturers to show how the automated driving system behaves, what assumptions it makes, and where the limits of those assumptions sit. That is a stronger governance model than simple self-attestation, but it only works if the evidence is specific, testable, and kept current as software changes. The real challenge is that autonomous vehicles evolve through updates, model retraining, sensor changes, and supplier substitutions faster than traditional certification cycles.

Practical implication: Practitioners should treat the safety case as a living assurance artefact tied to change control, not a one-time filing.

Connected vehicle supply chain security and written cybersecurity plans

The bill’s cybersecurity language is modest, but the operational risk is large. Connected vehicles depend on layered software, hardware, third-party services, and remote management channels, which creates a supply-chain problem as much as a product-security problem. Written cybersecurity plans only matter if they address provenance, update integrity, access control, and incident escalation across the full supplier chain. In practice, the weakest link is often not the vehicle itself but the administrative and maintenance pathways that connect manufacturers, fleet operators, and component vendors.

Practical implication: Teams should map supplier access, remote maintenance rights, and update paths before treating the written plan as evidence of control.

National incident reporting and the limits of fragmented governance

A national repository for crash and incident reporting would improve visibility, but visibility is not control. Standardised reporting helps regulators, insurers, and manufacturers compare outcomes, yet it does little if organisations cannot connect incidents to specific software versions, operational contexts, or access paths. That is the difference between data collection and governance. Without traceability from event to configuration to supplier dependency, the repository risks becoming a retrospective record rather than an active risk-management tool.

Practical implication: Organisations should align telemetry, configuration baselines, and incident records so they can explain not just what happened, but why it happened.

Threat narrative

Attacker objective: The attacker’s objective is to gain control over connected vehicle functions or undermine the integrity of autonomous operations at scale.

1. Entry begins through connected vehicle software, supplier interfaces, or remote maintenance channels that expand the trusted attack surface.
2. Escalation follows when an attacker abuses inadequate access controls, weak update integrity, or supplier trust to reach vehicle or fleet management functions.
3. Impact occurs when the compromise affects safety, availability, incident visibility, or the integrity of autonomous driving decisions.

NHI Mgmt Group analysis

Safety-case governance is now the right model for autonomy, but only if it includes cyber evidence. The bill borrows the aviation idea of proving a system is safe before scale, which is directionally sensible for autonomous vehicles. But safety without security evidence is incomplete because connected vehicles fail through software, supplier access, and update paths as often as through physical malfunction. Practitioners should treat safety cases as combined safety and cyber assurance files, not as pure regulatory paperwork.

Regulatory fragmentation has become an operational security problem, not just a policy problem. When 34 states maintain overlapping requirements, organisations end up duplicating controls, documentation, and exception handling across jurisdictions. That increases the chance of drift between policy, vehicle software, and supplier access governance. The practical conclusion is that AV programmes need one internal control baseline that is stricter than any single state rule and flexible enough to map to multiple jurisdictions.

Connected vehicle supply chains now resemble extended identity ecosystems. Manufacturers, suppliers, fleet operators, and service providers all need some form of access, authentication, and delegated trust to keep vehicles operating. That means identity governance principles apply even when the bill speaks in safety language. Practitioners should expect access review, least privilege, and supplier offboarding discipline to matter as much as technical vehicle controls.

Incident reporting will expose more gaps than it closes unless organisations improve traceability. A central repository improves transparency, but transparency without configuration and access lineage only produces better hindsight. The named concept here is traceable autonomy governance: the ability to link a vehicle event to the software version, supplier dependency, and access path that made it possible. Teams that cannot do that will struggle to defend either compliance or safety claims.

What this signals

The next phase of AV governance will reward organisations that can prove access lineage, supplier responsibility, and configuration integrity in the same control model. In practice, that moves AV programmes closer to identity governance patterns used in complex enterprise environments, even when the legislation is framed as transportation safety.

Traceable autonomy governance: the market will increasingly expect programmes to show how a vehicle event maps back to software version, access path, and supplier dependency. That is where auditability becomes a design requirement, not a reporting afterthought.

For practitioners

• Build a combined safety and cyber evidence pack Tie AV safety-case claims to software versions, security testing, supplier attestations, and change approvals so the submission reflects current operational risk.
• Map supplier access and remote maintenance pathways Document who can reach vehicle management interfaces, what authentication they use, and how access is revoked when contracts or support relationships end.
• Create one control baseline across jurisdictions Use a single internal control set for AV operations, then map it to state, federal, insurance, and supplier obligations to reduce drift and duplicated exceptions.
• Link incident records to configuration lineage Record the vehicle build, software release, telemetry source, and supplier dependency for each incident so reporting supports root-cause analysis instead of only compliance filing.

Key takeaways

• The SELF DRIVE Act is as much a governance document as a safety bill, because connected vehicles fail through cyber and supplier pathways as well as mechanical ones.
• Federal preemption may reduce state-by-state friction, but it will also expose whether organisations can maintain one reliable control baseline across jurisdictions.
• The strongest programmes will treat AV incidents as traceable identity and configuration events, not isolated safety exceptions.

Key terms

• Safety Case: A safety case is structured evidence showing that a system meets defined safety requirements in a specific operating context. In autonomous vehicles, it should also capture cybersecurity assumptions, change history, and supplier dependencies so the assurance claim remains valid after updates and integration changes.
• Traceable Autonomy Governance: Traceable autonomy governance is the ability to link an autonomous system event to the software version, access path, supplier dependency, and configuration state that produced it. It turns incident reporting into actionable assurance and gives regulators, auditors, and operators a shared basis for accountability.
• Connected Vehicle Supply Chain: A connected vehicle supply chain includes the hardware, software, services, and remote support relationships that keep an AV platform running. Because each link can introduce access, update, or data integrity risk, the supply chain must be governed as an operational trust network rather than as procurement only.
• Federated Regulatory Baseline: A federated regulatory baseline is one internal control set that can satisfy multiple overlapping jurisdictional rules without being rewritten for each state or region. It reduces drift, simplifies audit evidence, and gives organisations a stable governance core even when local requirements remain fragmented.

What's in the full article

Upstream Security's full article covers the legislative and operational detail this post intentionally leaves for the source:

• The bill language that expands NHTSA authority over Level 4 and Level 5 automated driving systems.
• The proposed National Automated Vehicle Safety Data Repository and its role in crash and incident reporting.
• The federal preemption debate affecting state-level licensing, registration, and insurance requirements.
• The cybersecurity plan obligations tied to safety case submissions and supply-chain review.

👉 The full Upstream Security article covers the bill mechanics, preemption debate, and compliance timeline.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is suited to practitioners who need to apply identity controls across complex operational and supplier ecosystems.