Why does relying on IT security alone create risk for connected vehicles?

Relying on IT security alone creates risk because connected vehicles operate in environments that differ from corporate IT. Embedded systems, diverse data flows, proprietary protocols, and physical safety consequences all change the threat model. Controls that work well for enterprise networks may miss vehicle specific attack paths, leaving product security gaps across the field and the supply chain.

Why vehicle security cannot be treated like office IT

Connected vehicles are not just laptops on wheels. They combine embedded controllers, safety-critical functions, wireless interfaces, telematics, mobile apps, and third-party services, so the security boundary is wider and the failure modes are more physical. IT security tends to optimise for confidentiality and enterprise uptime, while vehicle security must also account for availability, integrity, and safe operation under real-world conditions.

A vehicle-specific threat model has to include operational technology style constraints, intermittent connectivity, and components that may remain in service for years. That makes patching, trust decisions, and access assumptions much harder than in a managed corporate network.

What IT-only controls miss in the vehicle environment

Enterprise controls often assume stable endpoints, central administration, and uniform protocol stacks. In a connected vehicle, those assumptions break quickly. ECUs, gateways, infotainment, mobile pairing, cloud back ends, and supplier interfaces each introduce different trust boundaries, and many of them use proprietary or constrained protocols that generic IT tooling cannot inspect deeply.

The practical gap is not just technical visibility. A control that blocks suspicious network traffic in an office may do little against command paths exposed through diagnostics, firmware update channels, Bluetooth, cellular links, or third-party integrations. Vehicle security therefore has to cover the full data flow, from design and integration through update and decommissioning.

For a broader control lens, the principle of layered security is reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls, but connected vehicles need those controls translated into embedded, distributed, and safety-aware implementations.

Why the supply chain and physical safety change the answer

Connected vehicle risk extends beyond one organisation’s perimeter because the product is assembled from multiple suppliers, software components, cloud services, and update mechanisms. If any one of those pieces is weak, the vehicle can inherit the weakness even when the enterprise IT environment is well defended. That is why product security, supplier assurance, and secure update design matter as much as perimeter defense.

Physical consequence is the other major difference. In a vehicle, a security failure can become a safety failure, not just an outage or data exposure. That changes the acceptable risk threshold, the testing standard, and the urgency of remediation. If the security team only thinks about malware or account compromise, it can miss attack paths that interfere with braking, steering, diagnostics, or remote functions.

Connected vehicles also benefit from identity and access controls that are tuned to the device and service landscape. The NIST Cybersecurity Framework 2.0 is useful as a governance scaffold, but the implementation has to address vehicle-specific assets, supplier dependencies, and operational resilience. Similarly, the EU NIS2 Directive highlights how supply chain security and access control become board-level issues when connected systems are part of critical operations.

Where the real risk shows up in practice

The biggest practical risk is assuming that enterprise authentication, network segmentation, or endpoint protection automatically protects the vehicle. It does not. Vehicles often need long-lived support, remote update capability, diagnostic access, and third-party maintenance pathways, all of which can reopen exposure long after launch.

Attackers tend to look for the weakest trust edge: supplier updates, exposed APIs, remote access features, or insecure diagnostics. Defenders who focus only on enterprise IT often overinvest in the wrong layer and underinvest in firmware integrity, authorization boundaries, and safe fail states. That leaves a product security gap that can persist across fleets, not just in one deployment.

Risk and Threat Considerations

When connected vehicle security is reduced to IT security alone, the main risk is blind spots in attack surface, trust boundaries, and safety impact. Controls may look strong on paper while leaving firmware, telematics, update mechanisms, or supplier interfaces exposed to compromise or misuse.

Failure mechanism: Generic IT controls often do not model vehicle-specific protocols, embedded constraints, or safety-critical dependencies, so attackers can abuse update paths, diagnostics, third-party integrations, or weak trust assumptions outside the enterprise perimeter.

Impact: The result can be remote compromise, fleet-wide exposure, service disruption, or a security incident that crosses into physical safety and product liability.

Standards & Framework Alignment

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

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.SC-01 — Cybersecurity Supply Chain Risk Management	Connected vehicles depend on suppliers, updates, and third-party components.
	PR.AA-05 — Identity Management, Authentication, and Access Control	Vehicle trust paths depend on controlled access to diagnostics, services, and updates.
	PR.PS-01 — Configuration Management	Vehicle software, firmware, and trust settings require controlled secure configuration.
Recommendation — Map supplier and update dependencies, then verify controls across the vehicle supply chain. Enforce least-privilege access on vehicle and backend interfaces. Baseline and validate secure configurations across embedded and backend components.
NIST SP 800-53 Rev 5	SA-12 — Supply Chain Protection	Vehicle security depends on supplier assurance and component integrity.
	IA-9 — Identification and Authentication (Non-Organizational Users)	Connected vehicle services and external ecosystems require controlled machine and service authentication.
Recommendation — Assess and monitor suppliers that can affect vehicle software or hardware trust. Authenticate external systems and services before allowing vehicle trust interactions.
ISO/IEC 27001:2022	A.5.19 — Information security in supplier relationships	Connected vehicles inherit risk from vendors, cloud services, and component suppliers.
	A.8.9 — Configuration management	Vehicle security depends on controlled configuration of embedded and connected components.
	A.8.32 — Change management	Vehicle updates and firmware changes can create safety and security exposure.
Recommendation — Define supplier security requirements for vehicle and backend integrations. Control and review configurations that affect vehicle trust and update behaviour. Require formal review and testing before deploying vehicle-related changes.

Practitioner Guidance

What to prioritise: Treat the vehicle as a product and system-of-systems, not as an endpoint. The first question is whether a control protects the embedded asset, the cloud service, the supplier interface, or only the corporate network around it.

What to verify: Check whether update signing, diagnostics access, command authorization, and supplier pathways are validated under vehicle conditions, including intermittent connectivity and long support lifecycles. If a control cannot be tested outside the office network, it is not yet vehicle-ready.

Practitioner takeaway: The security model has to follow the vehicle’s operational reality, because the controls that protect enterprise IT often fail at the exact places where connected vehicles are most exposed.