TL;DR: Connected cars collect location, driving behavior and sensor data at scale, according to RunSafe Security, but that volume raises privacy, breach and cost exposure while adding little security value. Less data, not more, becomes the safer design choice because it shrinks the breachable surface before attackers or insiders can exploit it.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on RunSafe Security's blog post: Connected cars collect excessive operational data, and the resulting exposure increases privacy, breach and cost risk.
Why it matters: This matters for automotive security and privacy teams because reducing collected data changes the attack surface, the retention burden and the blast radius of compromise.
Context
Connected vehicles now behave like distributed computing platforms, with sensors, cameras, microphones and telemetry streams feeding multiple software layers. The security problem is not just whether those systems are protected, but whether they should collect and retain so much information in the first place.
When a vehicle collects more data than a feature actually needs, every additional dataset becomes another asset to protect, retain and govern. That creates a privacy, resilience and cost problem at fleet scale, and it is a typical condition for modern connected vehicles rather than an edge case.
Key questions
Q: How do connected cars reduce data exposure without losing core features?
A: Connected cars reduce data exposure by collecting only the data needed for a feature, then processing or storing it with minimisation, local processing and short retention. Core functions such as navigation, diagnostics and remote services can still work when telemetry, location and in-cabin data are scoped tightly and protected in transit and at rest.
Q: What happens when vehicle systems share trust across infotainment and safety layers?
A: Shared trust between infotainment and safety layers can let a compromise in one domain affect the other, including code execution, data tampering or access to vehicle functions. Strong isolation, separate trust boundaries and tightly controlled interfaces limit lateral movement and keep safety-critical systems from inheriting the weaker security of the infotainment stack.
Q: How can software-defined vehicle fleets stay resilient when patching lags?
A: Software-defined vehicle fleets stay resilient when patching lags by using compensating controls such as network segmentation, secure boot, signed updates, runtime monitoring and restricted diagnostic access. These controls reduce the attack surface while vulnerable software remains in service and help contain exploitation until a safe patch can be deployed.
Q: What is the best way to govern keyless entry risk in connected vehicles?
A: Keyless entry risk is governed by using authenticated proximity checks, rolling codes or challenge-response protocols, device binding and secure key storage in the fob and vehicle. Relay attacks exploit intercepted wireless signals, so access decisions should not rely on signal presence alone, especially for passive entry and remote start.
Technical breakdown
Why data minimisation changes the vehicle attack surface
Data minimisation is the practice of collecting only what a system genuinely needs to operate. In connected vehicles, that means treating telemetry, occupancy signals, camera feeds and location history as governed assets rather than default exhaust. The more the platform stores, the more it can expose through compromise, misuse or over-retention. This is not just a privacy concern. It is a security architecture choice because storage, replication, analytics pipelines and third-party sharing all expand the reachable surface area. See the Connected Car Privacy Guide.
Practical implication: Design vehicle data flows so each signal has a documented purpose, retention period and approved consumer.
Why autonomy increases the need for authenticated communications
Autonomous and advanced driver-assistance systems depend on rapid machine-to-machine decisions. That makes message integrity, source authentication and system isolation critical, because unsafe input can change vehicle behaviour in real time. The problem grows as vehicles mix Linux, real-time operating systems and Android components across safety and infotainment layers. When the software stack is heterogeneous, trust boundaries have to be explicit or one compromised component can influence others in ways the driver never sees. See the Connected and Autonomous Vehicle Security Guide.
Practical implication: Separate safety-critical channels from infotainment and external services with strict authentication and isolation boundaries.
How software-defined vehicle lifecycles stretch security assumptions
Vehicles are designed over years and remain in service for more than a decade, which means their software and threat model age together. That long lifecycle creates a mismatch between the speed of vulnerability discovery and the speed of patch deployment. Security has to be designed into the platform early because operational reality will always include delayed remediation, variant configurations and supply-chain dependencies. In practice, the challenge is not simply patching fast, but building systems that remain resilient when patching is slow or unavailable.
Practical implication: Plan for exploit resistance and controlled degradation when patch windows are long or unavailable.
Threat narrative
Attacker objective: The objective is to exploit unnecessary connected vehicle exposure for data theft, unauthorised access or operational disruption without needing visible physical intrusion.
- Entry occurs through the vehicle's exposed data flows, wireless interfaces or external connected services, where unnecessary telemetry and convenience features widen the points an attacker can target.
- Credential or session abuse then follows when trust in legitimate device-to-device communication, keyless entry or cloud-connected services is not tightly bounded.
- Impact lands in privacy leakage, vehicle misuse or unsafe system behaviour, because the platform has more data and more pathways than it needs to operate.
Breaches seen in the wild
- Toyota T-Connect key exposure 2022: A subcontractor left a T-Connect server key on public GitHub from 2017 to 2022; 296,019 customers' emails were exposed, misuse unknown.
- Nissan source code leak 2021: A Nissan North America Git server left on the default admin/admin login was used to copy and leak about 20GB of source code.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Data minimisation is now a security control, not a privacy preference. Connected vehicles accumulate more data than many features require, and that creates avoidable exposure across storage, analytics and sharing workflows. The governance failure is not merely retention discipline; it is allowing default collection to define the architecture. Practitioners should treat data reduction as a design constraint, not a compliance afterthought.
Autonomy amplifies the cost of weak trust boundaries. Once a vehicle makes decisions in real time, authenticated communications and strong isolation become safety requirements as much as cyber controls. The industry cannot rely on post-deployment patching to compensate for poorly separated systems, especially where infotainment and safety functions share complex software stacks. Practitioners need to re-check where trust is assumed between subsystems and where it is actually enforced.
Software-defined vehicles extend the life of risk far beyond launch. Long design cycles and decade-plus deployment windows mean that vulnerability management must be built around delayed fixes, variant configurations and component drift. That makes resilience by design more important than chasing every patch event. Practitioners should assume their control model will age more slowly than the attack surface evolves.
Vehicle convenience features create a standing trust problem. Keyless entry, cloud-linked services and ubiquitous wireless interfaces make legitimate use look indistinguishable from abuse when the security model is too permissive. The named concept here is connected-car exposure drag: the cumulative risk created when every new sensor, feed and integration adds more data than the vehicle actually needs. Practitioners should reduce the number of places where trust can be inherited by default.
What this signals
Connected-car exposure drag: the security burden rises each time a vehicle platform keeps a sensor, stream or service because it might be useful later. That creates governance debt for fleet operators, who have to defend data they did not truly need to keep in the first place.
As connected vehicles become more software-defined, the control model needs to move left into design and architecture choices. That means data minimisation, authenticated communications and trust-zone separation need to be enforced before deployment, not retrofitted after incidents.
For automotive programmes, the practical shift is toward reducing the number of trusted pathways rather than simply hardening every existing one. That is the only durable way to cope with long vehicle lifecycles, delayed patches and expanding external connectivity.
For practitioners
- Map every vehicle data stream to a specific business purpose Document why each telemetry, camera, occupancy and location feed exists, who consumes it and how long it is retained.
- Separate safety and infotainment trust zones Keep safety-critical systems isolated from consumer-facing and third-party-connected components, with authenticated message paths between them only where necessary.
- Design for delayed patching and variant fleets Assume some vehicles will stay exposed between vulnerability disclosure and fix deployment, then build compensating controls and rollback-safe updates around that reality.
- Reduce reliance on keyless and always-on connectivity Limit wireless convenience features where the security model cannot reliably distinguish genuine use from abuse, especially in high-theft or high-exposure scenarios.
Key takeaways
- Connected vehicles create avoidable risk when they collect and retain far more data than the vehicle actually needs to function.
- The core evidence is architectural: more telemetry, more integrations and longer retention all widen the exposure surface that attackers can target.
- Automotive teams should govern connected-car data as a security asset, with minimisation, isolation and resilience designed in from the start.
Related NHI Mgmt Group resources: Connected Car Privacy Guide · Connected and Autonomous Vehicle Security Guide · UNECE R155 Cyber Security Management System Guide · Automotive Cybersecurity Guide
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 CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest | Connected vehicles retain sensitive telemetry and location data that must be minimised and protected at rest. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Connected-car platforms rely on governed access to cloud services, diagnostics and stored vehicle data. | |
| Recommendation — Classify vehicle telemetry as protected data and limit retention to what each feature actually requires. Apply least-privilege entitlements to telematics, diagnostics and partner access paths. | ||
| CIS Controls v8 | CIS-3 — Data Protection | The article centres on reducing unnecessary data collection and retention in connected vehicles. |
| Recommendation — Use data-protection safeguards to shrink collection scope, retention time and disclosure paths. | ||
| MITRE ATT&CK | TA0001;TA0006;TA0040 — Initial Access; Credential Access; Impact | The risk path includes wireless abuse, trust exploitation and operational impact on vehicles and data. |
| Recommendation — Map exposed vehicle interfaces to ATT&CK techniques and harden the paths that lead to initial access and impact. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of Cryptography | Authenticated communications in connected vehicles depend on protecting integrity and trust across systems. |
| Recommendation — Protect vehicle communications with cryptographic controls that preserve message integrity across trust boundaries. | ||
Key terms
- Connected Vehicle: A connected vehicle is a car or mobility platform that uses network connectivity to exchange data and enable digital services. It can support navigation, remote access, payments, and automated interactions with other systems. That connectivity creates useful new experiences, but it also introduces identity, data, and safety risks that must be managed continuously.
- Authenticated Communications: Authenticated communications are network exchanges that verify the identity or origin of the other party before accepting the message. They use mechanisms such as mutual TLS, message authentication codes or signed protocols to reduce spoofing and tampering across APIs, services and device links.
- Data Minimization: Data minimization is the practice of limiting personal data collection to what is adequate, relevant, and necessary for a specific purpose. It reduces exposure by shrinking what is gathered, transferred, retained, and processed. Strong minimization depends on careful form design, purpose review, and strict collection discipline.
- Advanced Driver-Assistance Systems: Advanced Driver-Assistance Systems are vehicle technologies that support the driver with functions such as braking, steering, lane keeping, or collision warnings. They reduce manual workload but still depend on software, sensors, and control logic that can fail or behave unpredictably, making post-incident data capture essential.
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 gives security and identity practitioners a common framework for governing access, privilege and lifecycle risk across modern systems.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org