How should OEMs monitor autonomous vehicles for signs that safety controls are being tampered with?

OEMs should monitor for activation and deactivation anomalies across both individual vehicles and entire fleets, because safety functions can be manipulated as well as disrupted. The goal is to detect abnormal command patterns, unexpected state changes, and repeated toggling that do not match normal driving conditions. Fleet-wide telemetry is important, since a single compromised vehicle may signal a broader attack path.

What tampering looks like in vehicle telemetry

For OEMs, tampering rarely appears as one obvious event. It more often shows up as control-state volatility, command sequences that do not match expected vehicle mode, or repeated changes to safety-related functions at times that are inconsistent with driving conditions. The practical question is not only whether a command succeeded, but whether the surrounding pattern is credible.

A useful monitoring design treats safety controls as stateful security-relevant signals. If a function should change rarely, or only under narrow conditions, then unexpected enablement, disablement, reset, or rapid toggling becomes a stronger indicator than a single isolated command.

Why fleet-wide visibility matters more than a single vehicle view

OEMs should not limit monitoring to the affected vehicle. A compromised unit can be the first visible symptom of a broader campaign, especially when the same control path, software component, or backend dependency is reused across many vehicles. Fleet-level telemetry makes it easier to distinguish local driver behaviour from a repeated tamper pattern.

That broader view also helps separate malfunction from manipulation. If the same unusual state transition appears across multiple vehicles, or if one vehicle’s anomaly matches a fleet trend after a software update or service event, the issue may be systemic rather than isolated. Correlation is what turns raw alerts into a credible tamper hypothesis.

Which signals deserve the closest scrutiny

Priority signals include abnormal activation or deactivation timing, repeated toggling of a safety feature, commands issued when the vehicle is in an incompatible operating state, and control changes that arrive in clusters. OEMs should also watch for mismatches between command origin, vehicle state, and the expected sequence of operations, because tampering often looks like a control request that is technically valid but contextually wrong.

Telemetry should be rich enough to support attribution at the event level: who or what issued the command, from where it originated, what state the vehicle was in, and whether the change was accepted, rejected, or retried. Without that context, it becomes hard to distinguish a bad sensor, a software defect, and deliberate interference.

Risk and Threat Considerations

Safety-control tampering matters because the control can be altered without immediately disabling the vehicle. An attacker may prefer repeated state changes, abnormal enablement windows, or fleet-wide reuse of a weak control path because those patterns can survive basic health checks and still degrade safety over time.

Failure mechanism: A tampered command path, reused backend credential, or weak trust boundary can produce legitimate-looking control changes that bypass ordinary operational monitoring.

Impact: The OEM may miss a progressing compromise, vehicles may enter unsafe states, and a single successful tamper event may expose a repeatable attack path across the fleet.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1055 — Process Injection	Tampered safety controls can reflect adversary execution inside trusted vehicle software paths.
Recommendation — Correlate abnormal control-state changes with injected or hijacked execution paths in telemetry.
NIST SP 800-53 Rev 5	AU-6 — Audit Record Review, Analysis, and Reporting	Fleet telemetry needs review and correlation to spot abnormal control changes and repeated toggles.
	SI-4 — System Monitoring	Continuous monitoring is central to detecting unsafe or manipulated control-state changes.
	AC-6 — Least Privilege	Tampering risk rises when control paths can be modified by overly broad privileges.
Recommendation — Review and correlate safety-control audit events across vehicles and backends. Monitor vehicle and fleet control signals for anomalous activation and deactivation patterns. Reduce who can change safety controls and flag any unexpected privilege use.
ISO/IEC 27001:2022	A.8.16 — Monitoring activities	The question centers on monitoring for anomalous behaviour across vehicles and fleets.
Recommendation — Define monitoring rules for abnormal safety-control activity and fleet correlations.

Practitioner Guidance

What to verify: Monitor both command content and command context. A safety-control event should be checked against vehicle mode, timing, source, retry behaviour, and whether similar transitions occur elsewhere in the fleet. Context is what separates a real tamper signal from a noisy operational edge case.

What to measure: Track the rate of unexpected state transitions, repeated toggles per vehicle, and the number of vehicles showing the same control anomaly within the same software or backend version. Those metrics reveal whether you are seeing an isolated anomaly or a coordinated pattern.

Practitioner takeaway: Treat safety-control tampering as a correlation problem, not just an alerting problem, because the most important clue is often the repeated pattern that appears across vehicles, versions, or command paths.