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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Upstream Security's blog post: The revived SELF DRIVE Act could create a federal AV safety framework, but its cybersecurity provisions remain narrow and largely procedural.

Why it matters: This matters because AV programmes will need to align safety-case governance with connected-vehicle security, supply-chain assurance, and incident reporting, not treat compliance as a purely transport-policy exercise.

Context

Federal autonomous vehicle regulation is trying to catch up with commercial deployment, but the governance gap is now as much about cybersecurity and supply chain assurance as it is about safety certification. The article focuses on how a safety-case model can structure oversight while still leaving unresolved questions around connected-vehicle trust, incident transparency, and cross-state consistency.

For IAM and security teams, the relevant issue is not whether AVs are human or non-human identities in the narrow sense, but how a regulated cyber-physical system proves trustworthiness across software, suppliers, and operational environments. When a policy framework borrows from aviation without carrying over comparable security controls, the result is compliance theatre unless technical assurance is built into the operating model.

Key questions

Q: How should AV programmes build cybersecurity into a federal safety-case model?

A: Treat cybersecurity as evidence, not commentary. A credible safety case should show how software integrity, supplier trust, incident handling, and operational monitoring support the safety claim. If the cyber section only restates policy intent, the submission may satisfy paperwork but not regulatory scrutiny or real-world assurance.

Q: Why does state-by-state AV regulation create security and governance risk?

A: Fragmented state rules force manufacturers to maintain different compliance interpretations for the same vehicle platform. That increases the chance of inconsistent controls, duplicated evidence, and gaps between deployment, reporting, and supplier management. A single baseline only helps if it is specific enough to reduce ambiguity rather than relocate it.

Q: What breaks when AV cybersecurity plans are written but not operationalised?

A: Written plans without testing, ownership, and evidence collection create a false sense of assurance. In regulated AV environments, the failure is usually not the absence of policy but the inability to prove that suppliers, software updates, and incident response actually behave as documented.

Q: When should regulators require supplier provenance evidence for connected vehicles?

A: They should require it whenever third-party hardware, firmware, or software can influence automated driving functions or the integrity of updates. That is when supplier trust becomes a direct safety and security dependency, not a procurement detail.

Technical breakdown

How safety cases change AV governance

A safety case is structured evidence that a system meets defined safety expectations under known operating conditions. In the AV context, it forces manufacturers to show how the automated driving system behaves, what assumptions it relies on, and what evidence supports deployment. That is stronger than a simple checklist because it ties approval to documented claims, not marketing language. But safety cases are only as strong as the evidence behind them, and if cybersecurity, supply chain integrity, and incident handling are only lightly represented, the assurance model becomes incomplete. The operational challenge is turning compliance artifacts into a living governance process rather than a one-time filing.

Practical implication: Security and engineering teams should treat the safety case as an evidence register that must include cyber controls, supplier assurance, and incident response proof.

Why federal preemption changes the compliance model

Preempting state ADS design and performance rules would reduce fragmentation, but it also shifts the burden onto a federal rulemaking process that will need to define what sufficient assurance actually means. That matters because AV programmes currently face inconsistent requirements across jurisdictions, which complicates release planning, validation, and documentation. Federal harmonisation can reduce duplication, but it can also create a single point of ambiguity if the standard is too vague or too slow to evolve. The main governance issue is not simply speed, but whether one framework can keep pace with a distributed deployment environment where software, mapping, connectivity, and operational policy change continuously.

Practical implication: Practitioners should map current state-by-state obligations against likely federal requirements so compliance architecture does not have to be rebuilt later.

Connected-vehicle supply chain security is still the weak link

The bill’s cybersecurity section is modest because it focuses on reviewing existing connected-vehicle supply chain rules and asking manufacturers for written cybersecurity plans. That is directionally useful, but it does not by itself solve dependency trust, third-party software risk, or hardware provenance. Connected vehicles are distributed systems, and their attack surface extends across suppliers, update channels, and embedded components. In practice, the security problem is not only malicious access after deployment, but trust in every upstream element that contributes to safe operation. Without stronger supplier accountability and validation of software provenance, the assurance model remains vulnerable at the edges where AVs are most exposed.

Practical implication: Programmes should extend cybersecurity governance into supplier assurance, update provenance, and component-level trust validation.

NHI Mgmt Group analysis

Safety-case governance is only credible when cyber assurance is part of the evidentiary model. The SELF DRIVE Act’s structure recognises that autonomous vehicles cannot be governed like ordinary consumer products, but a safety case that underweights cybersecurity is incomplete by design. This is especially true for connected vehicles, where software, connectivity, and supplier trust all shape operational risk. Practitioners should treat cyber evidence as a core component of certification, not a parallel workstream.

Federal preemption may simplify compliance, but it also concentrates governance failure if the federal standard is too shallow. A patchwork of 34 state rules is inefficient, yet a single national framework only helps if it meaningfully addresses the real operating model. The article shows that the policy question is no longer whether regulation is needed, but whether the federal layer can absorb the technical complexity of AV deployment. Practitioners should expect federal harmonisation to reduce duplication while increasing scrutiny over what the national baseline actually covers.

Connected-vehicle supply chain assurance is the named governance gap that this bill only partially addresses. The article points to review of existing supply chain rules and written cybersecurity plans, but that is not the same as proving component provenance, update integrity, or third-party accountability. This is the exact failure mode regulators risk if they assume safety oversight alone will secure the platform. Practitioners should build supplier trust, software provenance, and incident evidence into AV governance now.

The market signal is that AV security is moving from innovation debate to regulatory assurance. Once lawmakers ask for safety cases and incident repositories, the conversation shifts from whether autonomous driving is possible to whether it can be governed under defensible controls. That will raise the bar for documentation, operational transparency, and cross-functional ownership across engineering, legal, and security. Practitioners should prepare for governance reviews that look more like regulated assurance programmes than product launch checkpoints.

What this signals

Connected-vehicle governance now depends on proving trust across the supply chain, not just certifying the driving system itself. The article shows that written cybersecurity plans and safety cases are not enough if third-party hardware, software, and update channels remain opaque. For practitioners, the next control conversation is provenance, dependency oversight, and evidence retention across the full vehicle lifecycle.

AV compliance will increasingly resemble regulated assurance rather than product security. Once federal oversight expands, teams will need documentation that survives legal challenge, not just internal approval. That means security, legal, engineering, and supplier management must operate from the same control model before deployment scales further.

For practitioners

• Define cyber evidence inside the safety case Include supplier trust, update integrity, incident handling, and security validation artifacts in the evidence set submitted for ADS approval.
• Map federal and state obligations now Create a control matrix that compares current state AV rules with the likely federal baseline for design, reporting, licensing, and insurance.
• Extend supplier assurance to connected components Require provenance, software origin, and third-party dependency review for hardware and software that support automated driving functions.
• Prepare incident reporting workflows for federal oversight Align crash, security, and operational incident handling so evidence can be submitted consistently to a national repository or regulator.

Key takeaways

• The SELF DRIVE Act revival makes AV regulation more concrete, but its cybersecurity treatment still leans on procedural assurance rather than deep technical control.
• The largest governance gap is not the absence of a federal framework, but whether that framework can absorb connected-vehicle supply chain risk and incident evidence.
• Practitioners should prepare for safety-case driven oversight by integrating cyber evidence, supplier provenance, and incident workflows into the compliance model.

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.
• Federal Preemption: Federal preemption is the legal principle under which a national law overrides conflicting state laws. In privacy, it can simplify compliance by replacing a patchwork of rules, but it can also create tension when states have stronger protections or enforcement expectations. Organisations still need disciplined data governance.
• 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.
• Assurance evidence: The reports, logs, certifications, and operational artefacts that show an identity control is working as intended. For practitioners, assurance evidence matters because audits and customer reviews depend on demonstrable control performance, not policy statements alone.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the governance discipline needed for modern systems with software-driven trust dependencies.