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

What the safety case has to prove, not just promise

An AV safety case should make cybersecurity part of the assurance argument, not a side note. The cyber narrative needs to show that the vehicle or autonomy stack can preserve integrity, resist dependency compromise, and detect conditions that could invalidate the safety claim. In practice, that means linking cyber controls to the evidence behind the safety assertion, not just to general programme intent.

That shift matters because regulators and assessors are looking for traceable justification: what was protected, how confidence was established, and what would cause the claim to fail. A weak submission often sounds secure but does not show how cyber conditions were verified in the system that is actually being assessed.

Which cyber evidence belongs in a federal safety-case model?

The strongest submissions connect cybersecurity evidence to the specific safety mechanism being claimed. Software integrity evidence should show that the autonomy stack, updates, and safety-relevant components are controlled against tampering. Supplier trust evidence should show how third-party software, hardware, and hosted services are qualified, monitored, and revalidated when conditions change.

Incident handling belongs in the safety case because safe operation depends on timely recognition and containment of cyber events that could affect behaviour. Operational monitoring belongs because a safety claim is only credible if the programme can detect drift, compromise, or degraded dependencies before those conditions become safety-relevant.

For federal environments, the supporting controls should be anchored in an agreed control baseline rather than ad hoc programme language. A practical reference point is NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where software integrity, logging, configuration control, access management, and incident response need to be tied to evidence. For supply-chain integrity, the build and artifact trail should be explicit enough that reviewers can trace what entered the safety case and why it is trusted.

How to structure the argument so it survives scrutiny

Build the cyber portion as a chain of claims and evidence. Start with the safety claim, then state the cyber dependency that could undermine it, then show the control or process that reduces that dependency, and finally show the evidence that the control actually operated. That structure is stronger than listing tools, policies, or teams because it answers the assessor’s real question: if cyber assurance fails, does the safety claim still hold?

This is where supply-chain and verification discipline matter. A programme that can demonstrate trusted build provenance, controlled dependency updates, and monitored release processes gives the assessor something concrete to evaluate. For software supply-chain integrity, SLSA is a useful reference because it forces the conversation toward provenance, reproducibility, and artifact trust rather than generic “secure development” language.

Monitoring evidence should also be operational, not decorative. If the cyber section cannot show what events are watched, what thresholds trigger action, and how those actions connect back to the safety case, then the model is only describing a control environment, not demonstrating assurance.

Risk and Threat Considerations

Cyber weaknesses in an AV safety case create a direct assurance gap: the system may appear safe on paper while remaining vulnerable to tampering, supplier compromise, or degraded monitoring in operation. That gap matters because an adversary, or even an unmonitored failure, can invalidate the evidence chain that supports the safety claim.

Failure mechanism: The safety case assumes integrity, trust, and observability, but those assumptions are not demonstrated with current, system-specific evidence. A compromised build path, poisoned supplier input, or blind spot in incident detection can break the argument without immediately breaking the vehicle.

Impact: Reviewers may approve a programme that lacks defensible assurance, and operators may discover only after deployment that the safety claim no longer matches real operating conditions. In the worst case, a cyber event becomes a safety event because the programme never proved how it would detect and contain the transition.

Practitioner Guidance

What to prioritise: Tie every cyber control to a specific safety assertion. If you cannot say which part of the claim a control protects, it is probably too generic to belong in the safety case.

What to verify: Require evidence that is current to the release or operating state, including provenance records, supplier assurance artifacts, incident playbooks, and monitoring outputs. Historical policy language is not enough if the system or supplier context has changed.

Common mistake: Treating cybersecurity as a compliance appendix. A federal safety case is stronger when cyber evidence is used to justify confidence in the safety argument, not when it is presented as a parallel narrative about programme maturity.

Practitioner takeaway: The cyber section should prove that the safety claim remains trustworthy under realistic compromise and failure conditions, not merely that the programme has security activities on record.

Related resources from NHI Mgmt Group

• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• How does the consumer-secret-entitlement model help with governance at scale?
• Why do cybersecurity programmes stall even when the risk case is strong?
• Should organisations treat AI safety and cybersecurity governance as separate programmes or one combined risk function?