A Lifecycle-Oriented Review of Security and Privacy Protection in the Internet of Vehicles

Abstract

The Internet of Vehicles (IoV) is reshaping intelligent transportation through pervasive connectivity, real-time data exchange, cooperative perception, and vehicle–edge–cloud services, while also expanding cybersecurity and privacy risks across heterogeneous cyber–physical environments. This paper presents a PRISMA 2020-informed systematic review of IoV security and privacy protection research. A cross-layer and lifecycle-oriented analytical framework is developed by integrating a four-layer IoV architecture—sensing layer, network access layer, coordinative computing layer, and application layer—with a five-stage data lifecycle covering data collection, transmission, storage, usage, and disposal. Based on this framework, the paper examines representative threat surfaces, vehicle-to-everything (V2X) communication security, public key infrastructure (PKI) based authentication, trust management, privacy-preserving data sharing, intrusion detection, active defense, and AI-assisted security analytics. Privacy-preserving mechanisms, including differential privacy, federated learning, blockchain, homomorphic encryption, and secure multi-party computation, are further compared in terms of deployment layer, lifecycle stage, real-time suitability, and representative performance evidence. In addition, the review discusses the engineering relevance of UNECE WP.29 R155/R156, ISO/SAE 21434, and related national standards, with emphasis on compliance evidence, over-the-air (OTA) governance, supply-chain coordination, and lifecycle cybersecurity management. The review shows that no single protection mechanism can simultaneously satisfy the requirements of real-time performance, scalability, privacy preservation, trustworthiness, and regulatory compliance in dynamic IoV environments. Future research should emphasize lightweight and adaptive protection, cross-layer trust coordination, privacy–utility co-optimization, trustworthy AI-assisted security operations, and evidence-based lifecycle governance. This review provides a structured reference for researchers and a practical basis for secure and privacy-aware IoV system design.

1. Introduction

Driven by the development of intelligent transportation systems and software-defined vehicles, the Internet of Vehicles (IoV), as an important extension of the Internet of Things in the transportation domain, has become a core enabling platform for connected and cooperative mobility. By supporting information exchange among vehicles, roadside infrastructure, pedestrians, edge nodes, and cloud platforms, IoV systems improve traffic safety, transportation efficiency, cooperative perception, and data-driven mobility services. The global deployment of connected vehicles has continued to accelerate. Recent industry estimates indicate that the number of connected vehicles worldwide reached approximately 876 million by the end of 2025 and is expected to increase to about 2.1 billion by 2035 [1]. This expansion indicates that vehicles are no longer merely mechanical transportation tools but are becoming large-scale mobile cyber–physical and consumer data platforms that continuously generate, transmit, store, and share security- and privacy-sensitive data.

The security and privacy risks of IoV should therefore be understood not only within the automotive domain, but also within the broader ecosystem of connected consumer technologies. Modern vehicles integrate sensors, infotainment systems, mobile applications, cloud services, remote diagnostics, and over-the-air (OTA) update mechanisms, making them structurally similar to other data-intensive cyber–physical consumer systems. Although image-encryption studies in consumer electronics do not directly address vehicular security, they illustrate a broader technical concern shared by connected consumer devices: privacy-sensitive data must be protected during acquisition, processing, transmission, and service-level use. This concern is also relevant to IoV systems, where vehicle trajectories, sensor observations, user interactions, and cloud-service data may be exposed across heterogeneous terminals, roadside infrastructure, edge nodes, and cloud platforms [2]. Therefore, this review treats IoV security and privacy not as an isolated automotive issue, but as part of a wider connected-device security problem involving encrypted data processing, access control, privacy preservation, and trustworthy information exchange.

However, the rapid proliferation of IoV also brings increasingly prominent cybersecurity and privacy challenges. If malicious attackers exploit vulnerabilities in vehicular networks, cloud interfaces, mobile applications, or in-vehicle software, the consequences may include traffic disruption, personal data leakage, unauthorized remote access, and even threats to driving safety [3]. The 2015 remote compromise of a Jeep Cherokee by Miller and Valasek remains a landmark historical case showing that cyberattacks on connected vehicles can propagate from communication and software interfaces to physical driving functions [4]. Nevertheless, the current IoV attack surface has expanded far beyond individual vehicle exploitation. With the increasing use of vehicle-to-everything (V2X) communication, cloud-connected services, OTA updates, mobile applications, and supply-chain software components, cybersecurity risks now extend across the full vehicle–edge–cloud lifecycle.

Despite the wide range of security mechanisms that have been proposed, the inherent dynamics, heterogeneity, high mobility, and lifecycle complexity of IoV systems impose significant limitations on the practical deployment of existing solutions. In view of these challenges, this paper provides a structured review of security and privacy protection strategies for IoV in intelligent transportation scenarios. The review follows a PRISMA 2020-informed literature identification and screening process and further develops a lifecycle-oriented analytical framework by integrating the IoV system architecture with the data lifecycle. This combined perspective enables a more systematic comparison of security threats, privacy risks, communication protection mechanisms, active defense approaches, and standards-oriented implementation requirements.

To clarify how this review differs from and complements prior studies, ten representative surveys are comparatively discussed across five dimensions: IoV architectural coverage, data-lifecycle coverage, cross-layer × lifecycle perspective, the breadth of privacy-preserving techniques considered, and the treatment of regulations and standards. This comparison highlights differences in research focus and coverage boundaries, thereby motivating the positioning and necessity of our work.

As shown in

Table 1. Comparison Between This Review and Representative Existing Surveys.

Ref.	Year	Primary Focus	Hierarchical Architecture Coverage	Data Lifecycle Coverage	Cross-Layer × Lifecycle View	Privacy Protection	Regulation & Standards
[5]	2023	Security and privacy issues in V2X communication systems	Partial	Partial	Limited	Partial	Partial
[6]	2025	V2X/ICV communication survey and taxonomy	Partial	Limited	Limited	Partial	Limited
[7]	2022	PKIs in C-ITS	Partial	Limited	Limited	Limited	Partial
[8]	2022	Trust management in VANETs	Limited	Limited	Limited	Limited	Limited
[9]	2022	Blockchain-based privacy protection in IoV	Partial	Partial	Limited	Partial	Limited
[10]	2025	Pseudonym change strategies	Partial	Limited	Limited	Limited	Limited
[11]	2020	Vehicular cloud computing security and privacy	Partial	Partial	Limited	Partial	Limited
[12]	2024	Zero-trust security in connected vehicles	Partial	Partial	Limited	Partial	Limited
[13]	2025	Distributed security enhancement in VANETs	Partial	Limited	Limited	Partial	Limited
[14]	2025	Security challenges in IoV for ITS	Partial	Limited	Limited	Partial	Limited
This work	2026	Lifecycle-oriented IoV security and privacy survey	Comprehensive	Comprehensive	Substantial	Comprehensive	Partial

Note: The comparative ratings are expressed as Limited, Partial, Substantial, and Comprehensive. “Limited” indicates that the topic is only briefly mentioned or addressed from a single perspective; “Partial” indicates that several aspects are covered but without a systematic mapping; “Substantial” indicates that most relevant dimensions are discussed with some integrative analysis; and “Comprehensive” indicates that the topic is examined through a structured framework with explicit relationships among architectural layers, lifecycle stages, threats, and countermeasures.

, the existing literature exhibits a clear degree of topic fragmentation. Some studies focus primarily on V2X/ICV communication systems and related security issues (e.g., [5,6]), while others emphasize public key infrastructures and credential management (e.g., [7]) or trust and reputation mechanisms (e.g., [8]). Still others concentrate on specific privacy directions, such as blockchain-based privacy protection or pseudonym strategies (e.g., [9,10]), or on cloud/vehicular platform security and zero-trust-oriented designs (e.g., [11,12]). As a result, prior reviews often provide valuable depth on individual subtopics, but less frequently offer an integrated synthesis spanning architectural layers, lifecycle stages, privacy-preserving mechanisms, and standards- or governance-related implementation concerns. Motivated by these observations, this work further adopts a four-layer architecture as the system boundary and uses the IoV data lifecycle—including collection, transmission, storage, usage, and disposal—as the organizing backbone to unify the review and comparative discussion of security and privacy strategies, thereby offering a more holistic reference framework for IoV security design and research option selection in intelligent transportation scenarios.

The category “Regulation & Standards” is marked as “P” because this review focuses primarily on mainstream standards and major regulatory frameworks that are most relevant to lifecycle cybersecurity management in IoV. Rather than attempting exhaustive coverage of all regional policy variations, the discussion emphasizes technically and engineering-relevant compliance drivers that have more direct implications for secure system design and deployment.

The main contributions of this review are summarized as follows:

(1)

A lifecycle-oriented analytical perspective is developed to organize IoV security and privacy issues across data generation and collection, transmission, storage, usage and sharing, and deletion or destruction, thereby enabling a more continuous understanding of risks and protection requirements throughout the full data handling process.

(2)

A cross-layer synthesis framework is established by combining the four-layer IoV architecture with lifecycle analysis, which helps clarify how threats, communication security mechanisms, privacy-preserving techniques, and defensive controls are distributed and interact across perception, network, platform, and application layers.

(3)

Representative technical approaches—including authentication and key management, trust management, privacy-preserving computation, intrusion detection, and active defense—are comparatively reviewed with attention to their engineering roles, deployment constraints, and trade-offs in dynamic vehicular environments.

(4)

Standards, regulations, and implementation-oriented security requirements are incorporated into the review to connect technical mechanisms with governance and compliance considerations, particularly in relation to OTA security, auditability, and lifecycle cybersecurity management.

(5)

Based on the comparative synthesis of existing studies, the review identifies major open challenges and outlines future directions for developing more lightweight, adaptive, privacy-aware, and governance-aligned IoV security frameworks.

2. Review Methodology and Analytical Framework

2.1. Search Strategy and Data Sources

To improve the transparency and reproducibility of the review process, this review was conducted and reported in accordance with the PRISMA 2020 statement where applicable to systematic reviews of heterogeneous engineering and cybersecurity literature. The literature identification, screening, eligibility assessment, and inclusion process followed the PRISMA 2020 reporting framework. This review was not registered, and no formal review protocol was published before the literature search and screening process.

The literature search was conducted across major academic databases, including Web of Science Core Collection, Scopus, IEEE Xplore, ScienceDirect, SpringerLink, ACM Digital Library, and MDPI. These databases were selected because they provide broad coverage of cybersecurity, vehicular networks, intelligent transportation systems, Internet of Vehicles, privacy-preserving computation, and applied engineering research. In addition to peer-reviewed academic publications, standards, regulatory documents, and technical reports related to vehicular cybersecurity and privacy governance were also examined, particularly where they were directly relevant to engineering implementation, compliance alignment, OTA security, or lifecycle cybersecurity management.

The search period mainly covered publications from January 2016 to March 2026. Earlier foundational works were retained only when they were necessary for explaining basic concepts, landmark security incidents, cryptographic mechanisms, or standardization background. This strategy allowed the review to balance historical continuity with recent developments in IoV security and privacy protection.

2.2. Search Strings and Screening Criteria

The search strategy combined IoV-related terms with security- and privacy-related terms. The main search string was constructed as follows:

(“Internet of Vehicles” OR IoV OR “connected vehicles” OR “intelligent connected vehicles” OR V2X OR VANET OR “vehicular networks”) AND (“cybersecurity” OR security OR “privacy protection” OR “data privacy” OR authentication OR “trust management” OR “intrusion detection” OR “misbehavior detection” OR “federated learning” OR “differential privacy” OR “blockchain” OR “data lifecycle”)

The inclusion criteria were as follows:

(1)

studies directly related to IoV, V2X, VANET, intelligent connected vehicles, or vehicle–edge–cloud systems;

(2)

studies addressing cybersecurity threats, privacy risks, authentication, trust management, intrusion detection, privacy-preserving computation, access control, or standards-oriented implementation;

(3)

review papers, research articles, conference papers, standards, regulations, or technical reports with clear relevance to vehicular cybersecurity or privacy protection; and

(4)

publications that provided sufficient methodological, technical, or engineering information to support comparative analysis.

The exclusion criteria were as follows:

(1)

studies focusing only on general IoT security without an explicit vehicular or intelligent transportation context;

(2)

studies discussing traffic control, routing, or mobility management without security or privacy relevance;

(3)

duplicate records;

(4)

publications with unavailable full texts or insufficient technical details; and

(5)

non-English studies unless they provided essential standardization or regulatory information.

2.3. PRISMA-Based Literature Screening Process

The literature screening process was organized according to the main phases of the PRISMA 2020 flow diagram: identification, screening, eligibility assessment, and inclusion. In the identification phase, records were retrieved from academic databases and supplementary sources such as standards, regulations, and technical reports. Duplicate records were removed before title and abstract screening. In the screening phase, records clearly unrelated to IoV, V2X, vehicular cybersecurity, or privacy protection were excluded. In the eligibility phase, the full texts of potentially relevant studies were assessed according to the inclusion and exclusion criteria. Finally, representative studies were included for qualitative synthesis and comparative analysis.

The first author conducted the initial database search, duplicate removal, and preliminary title and abstract screening according to the predefined inclusion and exclusion criteria. The corresponding author reviewed the screening criteria, verified borderline cases, and checked the final inclusion decisions. For reports assessed at the full-text stage, the first author extracted the relevant information, including publication type, research focus, IoV architectural layer, data lifecycle stage, threat category, security or privacy mechanism, evaluation context, representative findings, and standards or governance relevance. The corresponding author reviewed the extracted information for consistency with the analytical framework. Disagreements or uncertain cases were resolved through discussion until consensus was reached. No automation tools were used to make eligibility decisions.

During the screening and eligibility assessment, borderline cases mainly involved studies that addressed general IoT/ITS security without a clear vehicular context, studies focusing on routing or mobility optimization with only marginal security relevance, and standards or technical documents with indirect relevance to IoV governance. These cases were checked by the corresponding author against the predefined inclusion and exclusion criteria. Because the screening process was organized as initial screening followed by verification rather than two fully independent parallel screenings, no formal inter-rater agreement metric such as Cohen’s kappa was calculated. No third reviewer was consulted, because all uncertain cases were resolved through discussion between the two authors before the final inclusion decision.

The included studies were not treated as statistically homogeneous evidence units. Instead, they were categorized according to their relevance to the main analytical dimensions of this review, including IoV architecture, data lifecycle stages, communication security, identity authentication, trust management, privacy-preserving technologies, intrusion detection, active defense, and standards or regulatory implementation.

Following the search strategy described above, 468 records were identified from academic databases, including Web of Science Core Collection, Scopus, IEEE Xplore, ScienceDirect, SpringerLink, ACM Digital Library, and MDPI. No records were identified from registers. After removing 143 duplicate records and 12 records for other reasons, 313 records were screened by title and abstract. Among them, 164 records were excluded because they were not sufficiently related to IoV, V2X, VANET, intelligent connected vehicles, cybersecurity, or privacy protection. A total of 149 reports were sought for retrieval, of which 3 could not be retrieved. The full texts of 146 reports were assessed for eligibility, and 45 reports were excluded according to the predefined inclusion and exclusion criteria. Finally, 101 reports identified from database searches were included in the qualitative synthesis. In addition, 37 records were identified through other methods, including websites, standardization or regulatory organizations, technical reports, and citation searching. After eligibility assessment, 14 records from these supplementary sources were included. Overall, 115 studies/documents were included in this review. The complete study selection process is shown in Figure 1.

The completed PRISMA checklist is provided in the Supplementary Materials.

2.4. Analytical Framework of This Review

To support a coherent synthesis, this review analyzes the selected literature through three complementary dimensions.

The first dimension is the IoV system architecture. To avoid terminological inconsistency, this paper follows the layer terminology used in the cited IoV architecture literature, namely the sensing layer, network access layer, coordinative computing layer, and application layer. The sensing layer is responsible for acquiring vehicle status and environmental information; the network access layer supports V2X communication and heterogeneous network connectivity; the coordinative computing layer provides edge/cloud-based data aggregation, storage, processing, and coordination; and the application layer delivers intelligent transportation, vehicle services, and user-facing functions.

The second dimension is the data lifecycle, which covers data collection, data transmission, data storage, data usage and sharing, and data disposal. This dimension makes it possible to trace how security threats, privacy risks, and protection requirements evolve as vehicular data move from physical sensing to network communication, platform processing, service utilization, and eventual deletion or archiving.

The third dimension concerns governance-oriented implementation factors, including compliance alignment, auditability, OTA security, incident response, supply-chain security, and lifecycle cybersecurity management. These factors are particularly important because IoV security is not only a technical issue, but also an engineering and regulatory problem involving manufacturers, suppliers, service providers, regulators, and users.

By integrating these three dimensions, this review establishes a cross-layer and lifecycle-oriented analytical framework. Rather than listing isolated security techniques, the subsequent sections examine how different protection mechanisms correspond to specific architectural layers and lifecycle stages. For example, secure sensing and data minimization mainly address the sensing layer and data collection stage; message authentication and encrypted transmission mainly address the network access layer and data transmission stage; secure storage, access control, and privacy-preserving analytics mainly operate at the coordinative computing and application layers during data storage and usage; and audit logging, retention control, and verifiable deletion are closely related to the data disposal stage and governance requirements.

3. IoV Architecture, Threat Surface, and Communication Security

3.1. Overview of the IoV Architecture

The IoV is commonly regarded as a multi-layered system that supports comprehensive connectivity among vehicles, infrastructure, pedestrians, and cloud/edge service platforms. Following the terminology used in the cited IoV architecture literature, this review adopts a four-layer architecture consisting of the sensing layer, network access layer, coordinative computing layer, and application layer [15]. To present the overall analytical logic of this review, Figure 2 provides a cross-layer and lifecycle-oriented framework that integrates IoV architectural layers, data lifecycle stages, representative threat surfaces, security and privacy mechanisms, and governance support.

As shown in Figure 2, IoV security and privacy protection cannot be understood from a single architectural or technical perspective. Vehicular data are generated at the sensing layer, transmitted through the network access layer, processed and stored at the coordinative computing layer, and ultimately used by application services and governance processes. At each stage, different threat surfaces and protection mechanisms become dominant. Therefore, this framework provides the analytical basis for the subsequent sections: Section 3 focuses on architecture, threat surfaces, and communication security; Section 4 further expands the lifecycle-oriented data and privacy protection mechanisms; Section 5 discusses active defense and trust management; and Section 6 connects technical controls with standards and compliance requirements.

Together, these four layers cover the complete IoV data pipeline, from data acquisition and transmission to processing and service delivery. Architectural classifications may vary across the literature. Some studies focus primarily on underlying communications and adopt a three-layer VANET protocol stack (physical/MAC, network, and application) to optimize routing and channel access [16]. Other works further extend the architecture to a five-layer model by introducing a middleware or management layer between perception and networking to handle data filtering and protocol translation [17]. In addition, several authors introduce an independent “security management layer” or “privacy protection layer” beyond four- or five-layer models, abstracting functions such as identity management, intrusion detection, and key distribution to improve modularity and system maintainability [18]. For example, Contreras-Castillo et al. proposed a seven-layer architecture that separates user interfaces, data filtering, and security management into dedicated layers, thereby enhancing modularity and security [19].

3.2. Security Threat Surface in IoV

The IoV integrates wireless communications, Internet-based services, edge/cloud platforms, and in-vehicle control systems, resulting in a broad and heterogeneous attack surface. To avoid presenting the threat list as an arbitrary enumeration, this review derives the threat categories in

Table 2. Representative security threats in the IoV.

Threat Type	Description	Representative Attack Examples
Spoofing	Attackers impersonate legitimate entities to transmit forged information.	A malicious vehicle sends falsified speed information to follow vehicles, causing sudden braking events [20].
Data Tampering	Attackers intercept and maliciously modify data during transmission.	Coordinated ECU-based CAN bus tampering attacks enable real-time modification of in-vehicle data, realizing man-in-the-middle (MITM) tampering [21].
Information Disclosure	Unauthorized access to sensitive data, such as location and identity information.	A malicious endpoint injects ML-based models to infer CAN signals in real time, achieving up to 99% accuracy in driver behavior inference and enabling identity leakage [22].
Denial of Service (DoS)	Attackers disrupt services through flooding or interference, rendering them unavailable.	DoS attacks limit sensor update rates by targeting vehicular communication channels, degrading perception and control performance [23].
Sybil Attack	A single attacker forges multiple virtual identities.	Multiple fake nodes broadcast forged GPS and ID information to interfere with traffic scheduling; blockchain-based PoL consensus is used to revoke malicious identities [24].
Replay Attack	Attackers retransmit previously captured legitimate messages.	Replayed Basic Safety Messages (BSMs) mislead following vehicles into emergency braking; RF fingerprinting detects timing-drift anomalies in real time [25].
Message Suppression	Attackers prevent critical messages from reaching their destinations.	Legitimate warning messages are selectively dropped while forged messages are propagated, inducing unsafe acceleration or rear-end collisions [26].
Black Hole Attack	Malicious nodes discard all received data packets.	Black-hole nodes discard all AODV routing packets, reducing the packet delivery ratio (PDR) to 34% [27].
Malware	Injection of malicious code to compromise in-vehicle systems.	Trojanized navigation applications upload CAN logs via LTE backhaul, increasing energy consumption by approximately 12% [28].

through a synthesis of three sources of evidence: (i) representative IoV, V2X, VANET, and connected-vehicle security surveys; (ii) recent attack-specific studies addressing vehicular communication, in-vehicle networks, sensor systems, and cloud-connected services; and (iii) the security objectives commonly affected in vehicular cyber–physical systems, including confidentiality, integrity, availability, authenticity, privacy, and accountability.

Specifically, the threats are organized according to two complementary criteria. The first criterion is the attack mechanism, namely how an adversary compromises the system, such as identity impersonation, message modification, service disruption, identity multiplication, packet replay, message suppression, malicious routing behavior, or malware injections. The second criterion is the targeted asset or affected security objective, such as V2X safety messages, CAN bus data, sensor observations, routing packets, location and identity information, cloud-connected services, or in-vehicle applications. Following this synthesis logic, Table 2 summarizes representative IoV security threats together with their descriptions and typical attack examples.

It should be noted that the categories in Table 2 are not mutually exclusive. In practical IoV attacks, multiple threat types may occur simultaneously. For example, a false warning attack may involve spoofing, data tampering, and replay, while a compromised in-vehicle application may combine malware infection with information disclosure or unauthorized remote access. The purpose of this classification is therefore to provide an analytically useful taxonomy for subsequent discussion, rather than to define isolated or exhaustive attack classes.

As summarized in Table 2, security threats in the IoV span multiple architectural layers and directly affect both cyber and physical domains. Unlike conventional networked systems, many vehicular attacks can propagate from communication interfaces, cloud services, or in-vehicle applications into safety-related vehicle functions, thereby causing tangible consequences such as unintended braking, acceleration, or traffic miscoordination. The representative attack examples also show that IoV threats are closely coupled with vehicle-specific components and protocols, including V2X safety messages, CAN bus communications, sensor observations, vehicular routing protocols, cloud-connected services, and in-vehicle applications.

From a system-security perspective, these threats compromise different security objectives and therefore require different categories of countermeasures. Spoofing, replay, Sybil attacks, and message suppression mainly undermine message authenticity, freshness, trustworthiness, and timeliness in V2X communications, which makes authentication, certificate management, replay protection, and misbehavior detection essential. Data tampering and malware injection primarily threaten the integrity of in-vehicle data, software components, and control-related messages, requiring secure boot, message authentication, intrusion detection, software integrity verification, and isolation mechanisms. Denial-of-service and black-hole attacks mainly affect communication availability and routing reliability, and therefore require redundancy, secure routing, anomaly detection, and resilient communication mechanisms. Information disclosure attacks expose identity, location, trajectory, and behavioral data, which cannot be addressed by authentication alone and instead require privacy-preserving mechanisms such as data minimization, pseudonym management, access control, encryption, and anonymization.

This diversity of affected assets, attack mechanisms, and security objectives explains why a single defense mechanism cannot provide sufficient protection for IoV systems. For instance, PKI-based authentication can verify message origin and integrity, but it cannot by itself prevent denial-of-service attacks, detect compromised insiders, protect trajectory privacy, or guarantee secure data deletion. Similarly, encryption can protect confidentiality during transmission and storage, but it does not ensure data freshness, behavioral trustworthiness, or resistance to false-data injection. Therefore, effective IoV protection requires a coordinated defense-in-depth strategy that combines authentication, encryption, privacy-preserving data processing, access control, intrusion detection, trust management, secure software update, and lifecycle governance across different architectural layers and data lifecycle stages. This observation provides the basis for the layered communication security analysis, lifecycle-oriented privacy protection, and active defense mechanisms discussed in the following sections.

3.3. Privacy Leakage Risks in IoV

Beyond conventional cybersecurity threats, user privacy protection represents another critical challenge in the IoV. Connected vehicles continuously generate and exchange large volumes of behavior-related data, including driving trajectories, driving patterns, and in-vehicle interaction information. Without adequate privacy-preserving mechanisms, such data may be improperly collected or exploited, resulting in severe privacy leakage risks. Among various privacy concerns, location privacy is particularly prominent. In V2X communications, vehicles frequently broadcast location and identity information, enabling adversaries to infer sensitive attributes such as home addresses, workplaces, and daily routines through long-term observation and correlation attacks [29]. Among various privacy concerns, location privacy is particularly prominent. In V2X communications, vehicles periodically broadcast safety-related messages and interact with C-ITS stations or location-based service providers, during which position, speed, heading, pseudonym certificates, and trajectory-related information may be exposed. Recent studies have shown that replacing long-term identifiers with short-term pseudonyms is necessary but insufficient for robust location privacy protection, because adversaries may still link messages and reconstruct trajectories through spatiotemporal continuity, traffic-context information, semantic location features, or inefficient pseudonym-changing strategies. Dynamic mix-zone, safety-aware pseudonym update, C-ITS privacy management, and semantic obfuscation schemes have therefore been proposed to reduce long-term traceability while balancing anonymity, communication overhead, and driving safety [30,31,32,33,34,35]. These findings indicate that IoV location privacy should be addressed through a combination of pseudonym rotation, context-aware pseudonym-changing strategies, trajectory obfuscation, data minimization, and privacy-aware certificate management.

In addition to location privacy, identity privacy and data usage privacy also pose substantial risks in IoV systems. Vehicle identifiers, such as license plates, vehicle identification numbers (VINs), and digital certificate identities, may expose drivers’ personal identities once associated with real-world individuals, potentially leading to harassment or more severe security threats [36]. Moreover, IoV applications increasingly rely on cloud-based data aggregation and sharing, involving vehicle operational data and passenger-related information [37]. If access control and data isolation are insufficient, such data may be misused by unauthorized parties, undermining users’ rights to data awareness and control. Therefore, from a survey perspective, privacy protection in IoV should be addressed in conjunction with security mechanisms, emphasizing systematic strategies that balance data utility, real-time requirements, and privacy preservation.

To establish a rigorous connection between the physical system configuration and the logical data flow, this paper constructs an explicit mapping between the IoV architectural layers and the data lifecycle stages. Specifically, the Sensing layer, as the source of raw information, corresponds to the Data Collection stage; the Network access layer, leveraging diverse V2X communication technologies, facilitates the Data Transmission stage; the Coordinative computing layer (comprising cloud and edge resources) provides essential support for Data Storage and ultimate Data Disposal; and the Application Layer focuses on service logic, encompassing Data Usage and sharing. This mapping transforms the static architecture into a dynamic data-centric perspective, providing a unified logical framework for the subsequent in-depth analysis of security threats and defensive mechanisms across the entire lifecycle.

3.4. PKI and Identity Authentication Mechanisms

Modern IoV systems rely heavily on wireless interactions among vehicles, roadside infrastructure, and networked service entities, making communication-layer security a fundamental prerequisite for the reliable operation of intelligent transportation systems [38]. In such highly dynamic and open environments, communication entities must not only exchange information efficiently, but also establish whether the sender is legitimate, whether the message content has been tampered with, and whether malicious or replayed transmissions can be detected and excluded. Therefore, PKI-based credential management and identity authentication constitute the common trust foundation of IoV communications.

Unlike conventional static networks, IoV communications are characterized by high mobility, frequent broadcast exchange, heterogeneous participants, and stringent latency constraints. As a result, identity authentication in IoV should not be understood merely as an access control function. More fundamentally, it is the starting point for building trusted interactions across message dissemination, cooperative perception, decision support, and subsequent security response. In this sense, the core role of PKI is to provide a scalable trust framework that simultaneously supports authenticated identity establishment, message integrity protection, privacy-preserving credential use, and controllable accountability.

3.4.1. PKI Architecture

The IoV commonly adopts a public key infrastructure (PKI) to issue digital certificates to vehicles and roadside units, thereby establishing a trusted communication environment. In typical deployments, each vehicle is provided with a long-term credential for identity establishment and authorized enrollment, together with multiple short-term pseudonym certificates that are periodically updated for routine communications in order to reduce privacy leakage risks. This dual-credential design reflects a central requirement of IoV systems: communication participants must be authenticated and accountable, while their routine message exchanges should not be easily linkable over extended periods.

Both the U.S. Security Credential Management System (SCMS) and the European C-ITS trust architecture employ hierarchical certificate authority models to support vehicular trust management. In these architectures, vehicles obtain trusted initial credentials during manufacturing, registration, or onboarding, and subsequently retrieve batches of short-term certificates from credential management entities for day-to-day V2X message protection. These certificates typically contain the public key, validity period, and issuing authority signature, thereby binding cryptographic credentials to legitimate participants within a verifiable trust domain.

Overall, vehicular PKI provides the common institutional and cryptographic basis for IoV trust establishment. Its value lies not only in authenticating entities but also in supporting message authenticity, integrity verification, privacy-aware credential rotation, and revocation-based accountability. Accordingly, PKI should be viewed not as an isolated security mechanism, but as the trust backbone connecting communication protection, privacy management, and system governance in IoV environments.

3.4.2. Trust Chain and Certificate Hierarchy

Vehicular PKI (V-PKI) is typically organized as a hierarchical trust chain comprising a Root Certificate Authority (RCA), Enrollment or Registration Authorities (EA), Authorization Authorities (AA), and vehicle pseudonym certificates (PCs), as illustrated in Figure 3.

Within this hierarchy, the root certificate issued by Root CA acts as the trust anchor of the whole infrastructure and is securely provisioned into trusted in-vehicle hardware such as a hardware security module (HSM). Based on this trusted anchor, the vehicle verifies the legitimacy of the enrollment-related authority and obtains an enrollment certificate (EC), which represents its long-term authorized identity within the system domain. This credential is generally used for identity establishment and authorization rather than for routine safety-message signing.

During system operation, the vehicle subsequently requests short-term pseudonym certificates from the authorization-related authority for V2X message signing. These pseudonym certificates are rotated periodically so that routine messages cannot be easily linked over time, thereby reducing long-term tracking risks and improving privacy protection. Meanwhile, the certificate hierarchy also supports certificate update, trust anchor rollover, and revocation or suspension mechanisms, which are essential for maintaining the long-term scalability, resilience, and manageability of IoV trust domains.

From the perspective of common security logic, this trust chain enables a relatively complete authentication loop in IoV communications. First, the sender proves that it belongs to a trusted domain through a valid credential. Second, transmitted messages are protected through digital signatures or equivalent authentication mechanisms to ensure authenticity and integrity. Third, the receiver verifies both the credential and the message before accepting the transmitted content. Finally, the broader trust system maintains accountability and resilience through certificate lifecycle management, revocation, and misbehavior isolation. Although the specific protocol realization differs across communication scenarios, this underlying trust logic is shared by vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-pedestrian (V2P), and vehicle-to-cloud (V2C) interactions.

3.4.3. Authentication Enhancement Under Performance and Post-Quantum Constraints

Although PKI-based authentication provides a robust trust foundation, its practical deployment in IoV must also accommodate strict real-time constraints and evolving cryptographic threats. Safety-critical vehicular communications often involve frequent message transmission under dense traffic conditions, which makes per-message authentication overhead a non-negligible engineering concern. At the same time, the long-term sustainability of current cryptographic mechanisms is challenged by the emergence of post-quantum attack scenarios.

In this context, Twardokus et al. proposed a partial-hybrid authentication strategy to balance security strength and communication performance in vehicular environments [39]. The key motivation of this approach is that a uniform cryptographic mechanism may not be equally suitable for all communication stages. Stronger asymmetric protection is necessary during identity establishment or critical trust negotiation, whereas high-frequency safety-message exchange requires lower computational and transmission overhead. This design idea highlights an important trend in IoV authentication research, namely that authentication mechanisms should be differentiated according to security function, communication density, and latency sensitivity, rather than evaluated solely in terms of absolute cryptographic strength.

More broadly, this observation suggests that IoV identity authentication can no longer be assessed only from the perspective of “whether entities can be authenticated”, but must also be evaluated according to efficiency, scalability, privacy preservation, and future security sustainability. In other words, the design objective is not simply to maximize cryptographic robustness for every message, but to achieve an effective balance among trustworthiness, timeliness, deployment feasibility, and long-term resilience.

Overall, PKI-based credential management and identity authentication provide the common trust foundation for IoV communications. Across different communication counterparts, the core protection logic remains broadly consistent, namely authenticated identity establishment, integrity protection of exchanged messages, replay resistance, and accountability through certificate lifecycle management. On this basis, the security design of specific IoV communication modes is mainly differentiated by communication characteristics, infrastructure dependence, privacy sensitivity, device capability, and latency constraints. Therefore, the following section shifts from the common authentication foundation to the scenario-specific security requirements of V2V, V2I, V2P, and V2C communications.

3.5. Scenario-Specific Security Requirements Across IoV Communication Modes

3.5.1. Common Security Objectives and Scenario Differences in IoV Communications

V2X is used in this review as an umbrella term covering multiple vehicular communication modes, including V2V, V2I, V2P, and V2C communication. These modes share a common objective of enabling trustworthy information exchange among traffic participants and service entities, but they differ significantly in communication range, latency requirements, infrastructure dependence, device capability, and privacy exposure.

IEEE 802.11p-2010 [40], originally developed for Wireless Access in Vehicular Environments (WAVE), has been superseded as a standalone amendment because its functionality was incorporated into the revised IEEE 802.11 standard, beginning with IEEE Std 802.11-2012 [41]. In this paper, the term IEEE 802.11p is used in the conventional sense to refer to OCB-based vehicular communication mechanisms derived from this incorporated amendment It provides an important technical basis for DSRC/WAVE-style V2X communication, especially for low-latency local interactions between vehicles and roadside infrastructure. Meanwhile, cellular V2X and 5G-based vehicular communication further extend V2X connectivity toward broader coverage, higher capacity, and stronger integration with edge/cloud services. Therefore, security mechanisms for V2X should be analyzed not only according to communication counterparts, but also according to the underlying communication technology and deployment architecture.

Building upon the PKI- and credential-based trust foundation described above, different IoV communication modes share a common set of core security objectives. In essence, whether the interaction occurs between vehicles, between vehicles and infrastructure, between vehicles and pedestrians, or between vehicles and cloud-connected services, the communication process must ensure sender legitimacy, message authenticity, data integrity, replay resistance, and a certain degree of accountability. These requirements are fundamental because IoV communications often carry safety-critical information, and any forged, tampered, delayed, or replayed message may directly affect traffic efficiency, cooperative awareness, or even driving safety.

At the same time, communication security in IoV cannot be reduced to cryptographic verification alone. In practice, communication protection must also consider privacy preservation, scalability, timeliness, and operational resilience. For instance, while short-term pseudonym certificates can reduce long-term tracking risks, frequent certificate validation and message authentication also introduce computational overhead, especially in dense and latency-sensitive environments. Similarly, mechanisms for revocation, misbehavior reporting, and trust maintenance are necessary for accountability, but their implementation must be compatible with highly dynamic topologies and heterogeneous device capabilities. Therefore, the common security goal of IoV communication is not only to establish trust, but to establish it in a way that remains efficient, privacy-aware, and sustainable under real-world vehicular conditions.

Despite these shared objectives, the security priorities of different IoV communication modes are not identical. The differences mainly arise from five factors: communication counterparts, traffic patterns, infrastructure dependence, device capability, and privacy exposure. V2V communication is dominated by high-frequency broadcast exchange under strict latency constraints, making efficient authenticity verification and resistance to replay, spoofing, and Sybil attacks particularly important. V2I communication, by contrast, relies more heavily on the trustworthiness and availability of roadside infrastructure and edge-assisted coordination, so its security focus extends to infrastructure trust anchoring and localized trust management. V2P communication involves resource-constrained and highly heterogeneous pedestrian devices, where lightweight authentication and privacy-sensitive protection become more critical. V2C communication further extends the trust boundary to cloud and remote service domains, thereby introducing additional concerns related to end-to-end trust continuity, remote access protection, service interface exposure, and secure OTA support.

Accordingly, the following subsections examine how this shared trust foundation is adapted to the distinct operational characteristics, threat exposure, and engineering constraints of V2V, V2I, V2P, and V2C communications. This scenario-oriented discussion helps clarify that the main challenge in IoV communication security lies not in redefining authentication for each case, but in tailoring common security principles to different communication contexts while preserving both system efficiency and trustworthiness [5].

To clarify the scenario-specific security priorities of V2X communication, Figure 4 presents a taxonomy that maps the main IoV communication modes to their corresponding lifecycle stages, representative threats, and core defense mechanisms.

As shown in Figure 4, V2V, V2I, V2P, and V2C communications share the basic requirements of authentication, integrity protection, and trustworthy message exchange, but their security priorities differ significantly. V2V communication is mainly associated with low-latency transmission and real-time usage of safety messages, making spoofing, replay, Sybil behavior, and message suppression particularly critical. V2I communication depends more strongly on infrastructure trust and edge-assisted coordination, while V2P communication introduces stronger privacy concerns because pedestrian-side devices are heterogeneous and resource-constrained. V2C communication extends the trust boundary to cloud platforms, remote services, APIs, and OTA update systems.

Although V2V, V2I, V2P, and V2C communications share a broadly similar trust foundation, their security priorities are shaped by different communication counterparts, traffic patterns, infrastructure dependence, device capabilities, and privacy exposure. To make this distinction clearer,

Table 3. Common security logic and scenario-specific requirements across IoV communication modes.

Communication Mode	Shared Security Logic	Security Focus	Key Constraints	Representative Risks
V2V	Authentication, integrity, replay resistance, accountability	Low-latency broadcast trust	Dense traffic, mobility, delay sensitivity	Forgery, replay, Sybil, verification overload
V2I	Authentication, integrity, accountable interaction	Infrastructure trust and secure coordination	RSU dependence, local trust concentration	Fake RSU, false warnings, regional disruption
V2P	Authentication, integrity, privacy-aware exchange	Lightweight and privacy-sensitive protection	Weak devices, heterogeneity, privacy exposure	Tracking, spoofing, delayed warnings
V2C	Mutual authentication, secure transport, access control	End-to-end cloud-connected trust	Cross-domain links, backend exposure, OTA dependence	Remote intrusion, malicious updates, service hijacking

summarizes the common security logic and the scenario-specific protection focus, constraints, and representative risks associated with the major IoV communication modes.

As shown in Table 3, the main challenge in IoV communication security does not lie in redefining authentication for each communication mode, but in adapting a shared trust logic to different operational contexts. Accordingly, the following subsections further discuss how V2V, V2I, V2P, and V2C communications differ in their security emphasis, engineering constraints, and risk exposure.

3.5.2. V2V Communication Security

V2V communication is the most latency-sensitive and broadcast-intensive communication mode in IoV systems. Vehicles periodically exchange Basic Safety Messages (BSMs), cooperative awareness messages, or maneuver-related state information to support collision avoidance, lane-change coordination, and local situational awareness [42]. In such scenarios, confidentiality is often not the primary design objective, because many safety messages must be disseminated rapidly to all nearby vehicles. Instead, the central security requirement lies in ensuring that broadcast messages are authentic, untampered, fresh, and attributable within a manageable trust framework. Figure 5 further details the security logic of V2V communication by illustrating the relationship among broadcast safety messages, representative attacks, receiver-side verification, and core defense mechanisms.

As shown in Figure 5, V2V communication is dominated by high-frequency broadcast interactions among nearby vehicles. The transmitted messages usually contain pseudonym identifiers, vehicle state information, timestamps, event types, and digital signatures. This communication pattern makes authenticity, integrity, freshness, privacy, and low latency the central security objectives. Pseudonym certificates and message authentication help receivers verify the legitimacy and integrity of safety messages, while timestamps, sequence numbers, and plausibility checks reduce replay and delayed-message risks. Misbehavior detection further complements cryptographic verification by identifying forged, inconsistent, or suspicious behaviors that cannot be fully addressed by authentication alone. Therefore, V2V security requires a coordinated combination of credential management, efficient message verification, replay protection, and behavior-level monitoring.

This challenge becomes even more prominent when stronger future-proof cryptography is considered. Twardokus et al. pointed out that directly applying post-quantum authentication mechanisms to high-frequency V2V safety messaging may introduce significant communication and verification overhead, and thus practical deployment must carefully balance cryptographic robustness against real-time performance requirements [39]. This observation reinforces the engineering reality that V2V security design must remain tightly coupled with latency budgets, communication density, and on-board processing capability.

At the same time, privacy protection remains inseparable from V2V authentication. Although pseudonym-based credential systems are widely adopted to reduce long-term traceability, privacy is not automatically guaranteed once identifiers are changed. Escher et al. showed that under the European C-ITS pseudonym scheme, vehicle tracking may remain feasible under certain observational conditions, indicating that pseudonym rotation alone cannot fully eliminate link ability risks in practice [43]. Therefore, V2V security should be understood as a coordinated problem involving not only authenticity and integrity, but also privacy-aware credential use, scalable verification, and resilience against insider misuse. In this sense, the distinctive focus of V2V protection lies in achieving low-latency trust establishment without sacrificing either operational efficiency or location privacy.

3.5.3. V2I Communication Security

V2I communication refers to the interaction between vehicles and roadside infrastructure such as RSUs, smart traffic signals, roadside sensing units, and edge-assisted work-zone devices. Compared with V2V, V2I communication is typically less dominated by pure broadcast density and more dependent on the trustworthiness, availability, and coordination capability of infrastructure nodes. As a result, the security focus of V2I extends beyond message-level authenticity to include infrastructure trust anchoring, localized coordination integrity, and the protection of data flows between roadside systems and higher-layer platforms. Figure 6 presents a schematic of V2I communication security, emphasizing the interaction among vehicles, RSUs, roadside sensing devices, traffic control facilities, and edge/cloud platforms.

As shown in Figure 6, the key distinction of V2I security lies in the central role of roadside infrastructure. Vehicles not only receive traffic warnings, signal information, congestion data, and coordination instructions from RSUs, but may also upload vehicle status and local sensing information for edge-assisted decision-making. Therefore, the compromise of an RSU or roadside service may have a regional impact by affecting multiple vehicles within the same traffic area. Compared with V2V, V2I security places greater emphasis on RSU authentication, infrastructure trust anchoring, encrypted communication, access control, and secure edge coordination. The verification workflow in Figure 6 also indicates that vehicles should not directly trust infrastructure-originated messages; instead, they should verify RSU credentials, message integrity, freshness, policy consistency, and plausibility before accepting warnings or coordination services.

This scenario is especially relevant in smart work-zone and lane-change coordination applications. Nour et al. demonstrated that V2I-assisted communication can significantly improve safer lane-change support in smart work zones by enabling coordinated interactions among vehicles, RSUs, and roadside sensing devices [42]. From a security perspective, however, such coordination also means that the trustworthiness of infrastructure becomes operationally critical: once the roadside unit is spoofed, misconfigured, or compromised, the impact may extend to multiple vehicles within the local traffic domain. Therefore, V2I security should place particular emphasis on secure RSU identity management, authenticated warning dissemination, integrity protection of uploaded status data, and trusted forwarding between roadside and backend systems.

3.5.4. V2P Communication Security

V2P communication addresses the interaction between vehicles and vulnerable road users such as pedestrians and cyclists, usually through smartphones, wearables, or infrastructure-assisted sensing systems. Compared with V2V and V2I, V2P introduces stronger asymmetry in both device capability and privacy sensitivity. Pedestrian-side devices often have limited battery capacity, lower computational resources, and less stable communication availability, while the information they expose—especially identity, location, and movement trajectory—may be highly privacy-sensitive. Therefore, V2P security must satisfy safety-oriented trust requirements without imposing excessive cryptographic or communication burden on pedestrian terminals. Figure 7 illustrates the security and privacy protection logic of V2P communication by integrating vulnerable road-user interaction scenarios, representative threats, exchanged safety information, verification workflows, and core protection mechanisms.

As shown in Figure 7, V2P communication differs from V2V and V2I scenarios because it involves not only vehicles and infrastructure, but also vulnerable road users such as pedestrians, cyclists, and micromobility users. These users typically rely on smartphones, wearables, or infrastructure-assisted devices to exchange safety-related information with nearby vehicles or roadside units. The exchanged data may include position, speed, heading, crossing intention, and hazard-warning information, which are useful for collision avoidance but may also expose sensitive locations and behavior patterns. Therefore, V2P security must balance two requirements: timely and reliable safety warning delivery, and strict privacy protection for vulnerable road users.

The main risks in V2P communication include pedestrian tracking, device impersonation, delayed warnings, and false alert injections. To address these risks, lightweight authentication, pseudonyms or ephemeral identifiers, encrypted warning transmission, selective disclosure, privacy minimization, and plausibility/freshness verification are required. Compared with vehicle-side devices, pedestrian-side terminals are often more heterogeneous and resource-constrained, so V2P protection mechanisms should avoid excessive computational and communication overhead. The verification workflow in Figure 7 further shows that V2P safety messages should be accepted only after credential validation, freshness checking, contextual plausibility assessment, and safety-response decision-making. In this sense, V2P security is not merely an extension of V2V authentication, but a privacy-sensitive protection problem involving asymmetric devices, vulnerable users, and time-critical safety services.

Relative to other communication modes, V2P is the clearest example that a shared trust foundation does not imply identical security realization. The underlying need for authenticity and integrity remains, but the engineering emphasis shifts toward lightweight protection, privacy-sensitive data exposure control, and architecture selection between direct and infrastructure-assisted interaction.

3.5.5. V2C Communication Security

V2C communication extends vehicular interaction beyond local wireless exchange to cloud-connected platforms and remote service systems. Typical V2C functions include telematics data upload, vehicle status queries, remote diagnostics, fleet management, cloud-assisted analytics, and OTA software updates. Compared with V2V, V2I, and V2P, this communication mode spans longer trust chains and more heterogeneous protocol domains, thereby introducing additional risks related to remote access, backend service exposure, API security, and end-to-end trust continuity. Figure 8 illustrates the security structure of V2C communication, focusing on the extended trust chain among connected vehicles, telematics units, cellular networks, cloud platforms, mobile applications, remote service terminals, and OTA update servers.

As shown in Figure 8, V2C communication differs from local V2X interactions because it extends vehicular trust relationships to remote cloud and service domains. Typical V2C data include telematics records, diagnostic information, location and battery status, remote-control requests, access tokens, certificates, and software update packages. Consequently, V2C security must protect not only message authenticity and confidentiality during transmission, but also service authorization, API security, cloud-side access control, and OTA update integrity. Remote intrusion, malicious update delivery, API hijacking, and telematics data leakage are therefore representative risks in this mode. Effective V2C protection requires mutual authentication, encrypted transport, policy-based access control, secure session management, and strong provenance and integrity verification for OTA and remote-service operations.

One of the most critical V2C security tasks is secure OTA update delivery. Cahyadi et al. proposed a certificateless aggregate signature scheme for VANET environments that highlights the broader value of efficient authentication for large-scale vehicular communications [44]. In the V2C context, this line of thinking is especially relevant because OTA and cloud-originated services require scalable authenticity assurance without creating excessive verification overhead across distributed vehicular nodes. More generally, cloud-initiated operations such as remote unlocking, control-related service requests, or software package delivery must be protected by strong provenance verification, integrity checks, and secure channel mechanisms so that malicious commands, forged updates, or tampered service responses cannot propagate into the vehicle domain.

Accordingly, the distinctive focus of V2C communication security lies in the extension of trust across vehicle, network, cloud, and remote service layers. Unlike V2V, where the main issue is ultra-low-latency peer authentication, or V2I, where infrastructure trust is central, V2C must maintain end-to-end trust continuity across longer and more heterogeneous system paths. Therefore, effective V2C protection should combine mutual authentication, secure transport, cloud-side access governance, and trustworthy update/service management to reduce the attack surface created by deep vehicle–cloud integration.

4. Data and Privacy Protection Policy

The IoV generates massive volumes of heterogeneous data, including vehicle location trajectories, driving speed, sensor observations, in-vehicle interaction records, diagnostic information, and cloud-service data. While these data provide the foundation for cooperative perception, traffic optimization, remote diagnostics, and intelligent transportation services, they also introduce security and privacy risks that vary across architectural layers and data lifecycle stages.

To maintain the lifecycle-oriented logic introduced in the previous sections, this chapter does not treat data protection technologies as isolated mechanisms. Instead, each protection strategy is analyzed according to its primary architectural deployment layer and its corresponding lifecycle stage. In general, secure sensing and data minimization are mainly associated with the sensing layer and the data collection stage; encryption and message authentication are closely related to the network access layer and the data transmission stage; secure storage, access control, blockchain-based audit, and searchable encryption mainly operate at the coordinative computing layer during data storage and sharing; privacy-preserving analytics, such as differential privacy, federated learning, homomorphic encryption, and secure multi-party computation, are primarily applied during data usage and sharing at the vehicle–edge–cloud or application-service level; and secure deletion, verifiable destruction, and retention management are linked to the data disposal stage and lifecycle governance requirements.

This cross-layer and lifecycle-oriented view helps clarify not only what each mechanism does, but also where it is deployed, which data stage it protects, and what engineering trade-offs it introduces in terms of latency, scalability, privacy utility, and compliance.

To make this mapping explicit,

Table 4. Cross-layer and lifecycle mapping of IoV data and privacy protection mechanisms.

Protection Mechanism	Primary Architectural Layer	Main Lifecycle Stage	Protected Data or Asset	Main Security/Privacy Objective	Typical IoV Scenario
Secure sensing and sensor authentication	Sensing layer	Data collection	Sensor readings, vehicle status, environmental perception data	Authenticity, integrity, false-data injection resistance	Camera/LiDAR/radar sensing, onboard diagnostics
Data minimization and local filtering	Sensing layer/application layer	Data collection/data usage	Raw location, identity, behavioral data	Privacy exposure reduction, purpose limitation	Local preprocessing before upload or sharing
Message authentication and encrypted transmission	Network access layer	Data transmission	V2X messages, in-vehicle bus data, vehicle–cloud communication data	Confidentiality, integrity, authenticity, replay resistance	V2V/V2I/V2C communication
Secure storage and access control	Coordinative computing layer	Data storage	Cloud-stored vehicular data, diagnostic logs, user profiles	Confidentiality, authorization, accountability	Edge/cloud data repositories
Differential privacy	Application layer/coordinative computing layer	Data usage and sharing	Statistical traffic data, trajectory aggregates, model updates	Privacy–utility balance, re-identification risk reduction	Traffic statistics, trajectory publishing, AI model training
Federated learning	Vehicle–edge–cloud/coordinative computing layer	Data usage and sharing	Local training data, model gradients or parameters	Local data retention, collaborative intelligence, privacy-preserving analytics	Cooperative perception, driving-behavior modeling, traffic prediction
Homomorphic encryption and SMPC	Coordinative computing layer/cloud service layer	Data usage and sharing	Encrypted data, multi-party computation inputs	Confidential computation, raw-data protection	Secure aggregation, joint traffic analytics
Blockchain-based audit and access management	Coordinative computing layer/governance layer	Data storage/data usage/data disposal	Access records, sharing permissions, deletion proofs	Traceability, tamper resistance, accountability	Data sharing audit, revocation, lifecycle evidence management
Pseudonym management and trajectory obfuscation	Network access layer/application layer	Data transmission/data usage	Location, identity, trajectory data	Unlinkability, location privacy, tracking resistance	V2X broadcasting, location-based services
Secure deletion and verifiable destruction	Coordinative computing layer/governance layer	Data disposal	Archived logs, retained personal data, obsolete vehicle records	Retention control, verifiable erasure, compliance	Used-vehicle transfer, cloud log expiration, accident-data retention

summarizes representative data and privacy protection mechanisms according to their primary architectural layer, lifecycle stage, protected asset, security or privacy objective, and typical IoV deployment scenario.

As shown in Table 4, IoV data protection is inherently cross-layer and lifecycle-dependent. For example, differential privacy and federated learning both support privacy-preserving data usage, but they operate through different deployment logics: differential privacy perturbs released data or model updates to reduce re-identification risks, whereas federated learning keeps raw data local and shares model parameters through vehicle–edge–cloud coordination. Similarly, blockchain-based mechanisms are less suitable for hard real-time communication protection, but they are useful for auditability, access management, revocation records, and deletion-proof management across the storage, usage, and disposal stages. Therefore, the selection of privacy protection mechanisms should be guided by the lifecycle stage and architectural context in which the data are generated, transmitted, stored, used, or destroyed.

4.1. Data Lifecycle Security

While Figure 1 presents the overall cross-layer analytical framework of the review, Figure 9 further focuses on lifecycle-oriented data security controls from the perspective of IoV data governance.

As shown in Figure 9, IoV data governance requires stage-specific controls across the entire data lifecycle. At the data collection stage, classification, minimization, source authentication, integrity checking, and consent or collection policy compliance are essential for reducing unnecessary privacy exposure and false-data risks. During data transmission, end-to-end encryption, mutual authentication, replay protection, availability assurance, and secure routing are required to protect data flows across vehicles, infrastructure, and cloud platforms. At the storage stage, encryption at rest, backup and recovery, access control, key management, storage isolation, and integrity monitoring help prevent unauthorized access and data loss. During data usage, fine-grained authorization, masking, anonymization, privacy-preserving analytics, and usage auditing are needed to ensure that vehicular data are used only for legitimate and authorized purposes. Finally, data disposal requires secure deletion, retention control, de-identification, destruction verification, and audit trails. The governance and security support layer in the figure indicates that these stage-specific controls should be reinforced by standards, identity management, key management, monitoring, incident response, and compliance management.

4.1.1. Data Collection

Vehicular data are primarily generated by various onboard sensors and terminals, including GPS positioning modules, cameras, radar and LiDAR sensors, and onboard diagnostics systems that monitor vehicle operating conditions [45]. Security strategies at this stage should ensure the authenticity and integrity of sensor readings, preventing malicious data tampering and false data injection attacks [46].

Lenard et al. designed an automotive security testbed that integrates a trusted platform module–based root of trust, periodic encryption and authentication key rotation, and safety firewall/intrusion detection system monitoring, thereby establishing a hardware-level chain of trust for in-vehicle sensor data [47]. Miao et al. proposed a density-adaptive real-time framework capable of online detection and localization of compromised sensors, as well as data recovery, which improves perception robustness in autonomous driving scenarios [48]. Sato et al. constructed a mobile target laser system and experimentally demonstrated long-range (110 m) and high-speed (60 km/h) LiDAR spoofing attacks, while also discussing defense strategies such as scan pattern randomization [49].

In addition to integrity and authenticity protection, data generation should adhere to the principle of data minimization. Unnecessary data should be avoided, or collected at reduced precision, to mitigate subsequent privacy risks throughout the data lifecycle [50].

4.1.2. Data Transmission

During the data transmission stage, vehicular data are conveyed through in-vehicle buses or wireless networks to onboard units, neighboring vehicles, or cloud platforms. Throughout transmission, data confidentiality and integrity must be ensured to prevent eavesdropping and manipulation [51]. Internally, in-vehicle networks can adopt domain-based isolation and message authentication mechanisms to mitigate bus injection attacks. Externally, regardless of whether data are transmitted via direct IoV communications or cellular networks, encryption should be applied to protect data flows.

Plappert et al. combined TPM 2.0 and Device Identifier Composition Engine technologies to construct a lightweight trusted boot and attestation mechanism for in-vehicle electronic control units. This approach enables verifiable software identity and traceable execution states during OTA updates, thereby enhancing system recoverability and security compliance [52]. Cultice et al. deployed a post-quantum cryptographic framework based on physical unclonable functions in upgraded CAN-FD buses, enabling hardware-level signature verification for sensor-to-ECU data. This design achieves integrity protection, authentication, and traceability against future quantum threats with minimal bandwidth and storage overhead [53]. Kumar et al. proposed a NextGenV2V protocol in which vehicles negotiate symmetric keys with the assistance of a trusted authority during initial network enrollment. Subsequently, a (2, n) threshold mechanism allows any two authenticated vehicles to collaboratively generate shared session keys for lightweight V2V re-authentication without repeatedly contacting the trusted authority. This scheme ensures that communication secrecy is compromised only when at least two vehicles are simultaneously breached, thereby improving both security and scalability [54].

4.1.3. Data Storage

Vehicular data may be stored either in onboard storage devices or in cloud platforms after being uploaded. In both cases, encrypted storage and access control mechanisms are essential to protect data security. On the vehicle side, local storage media should enable full-disk encryption to prevent data leakage in the event of physical device removal or tampering. In cloud databases, sensitive personal data fields uploaded by vehicles must be encrypted, and strict access control policies should be enforced to ensure that only authorized entities can access such data.

For data that remains unused for extended periods, data desensitization techniques should be considered to further reduce sensitivity. Typical approaches include removing or generalizing personal identifiers and transforming precise location trajectories into coarse-grained or abstracted movement patterns, thereby mitigating privacy risks.

Zuo et al. proposed the BLAC scheme, which leverages blockchain technology and sharded ciphertext storage to achieve lightweight access control and tamper resistance for vehicular data uploaded to the cloud [55]. Rafi, S.M. et al. introduced a three-stage DAC-GCRRNN-FOFMOA framework comprising registration, intrusion detection, and intrusion blocking. In this framework, credentials are first generated for cloud storage access, and then a combination of PMBMF preprocessing and GCRRNN-FOFMOA–based intelligent classification is employed to filter unauthorized access attempts in real time, enabling fine-grained dual-layer access control and immediate intrusion prevention for uploaded data [56]. Wan et al. applied a dual-policy attribute-based searchable encryption scheme before data are uploaded to the cloud, supporting keyword updates and bidirectional fine-grained access control. This approach simultaneously preserves data confidentiality and searchability in vehicular social networks [57].

4.1.4. Data Usage

The data usage stage refers to scenarios in which vehicular data are processed for analytics, shared with third parties, or presented to end users. The primary security objective at this stage is to ensure that data usage strictly complies with authorized purposes while preventing secondary leakage or misuse. In addition to adhering to the principle of minimum necessary use, data security goals can be achieved through mechanisms such as verifiable aggregation, sandboxed privacy frameworks, fine-grained attribute-based encryption with signcryption and revocable sharing, and blockchain-enabled privacy authentication.

Zhou et al. employed homomorphic verifiable aggregation combined with zero-knowledge proofs, allowing roadside cloud servers to obtain only noise-added aggregated results without reconstructing individual vehicle plaintext data, thereby enabling IoV statistical analysis that is “usable yet invisible” [58]. Pesé et al. proposed the PRICAR framework, which enforces the principles of minimization, anonymization, and desensitization before third-party applications access vehicular data, and executes external code within a neutral sandbox to prevent partners from copying or redistributing raw in-vehicle data [59]. Using an end-to-end attribute-based encryption (E2E-ABE) protocol, Fan et al. combined reputation-based incentives with mutual authentication between vehicles and roadside units to secure high-definition map data sharing. Their scheme leverages Merkle hash trees with anonymous certificates to block malicious entities while maintaining high efficiency [60].

Liu et al. designed a traffic data sharing scheme that integrates signcryption with an editable blockchain, where only data that are signcrypted by RSU proxies and comply with on-chain revocation rules can be accessed by third parties, effectively preventing unauthorized redistribution [61]. Huang et al. proposed a multi-shard blockchain framework combined with zero-knowledge proofs to support anonymous yet auditable data sharing in cooperative vehicular analytics, ensuring that only authorized vehicles can decrypt shared data while regulators retain accountability capabilities [62]. Shang and Deng introduced a blockchain-driven privacy-preserving authentication mechanism in which only anonymized and credential-verified IoV data digests are exposed to the cloud, with access fingerprints recorded on-chain to mitigate secondary leakage by cloud service providers or third parties [63].

4.1.5. Data Disposal

According to data governance policies, vehicular data that have reached their retention limits or are no longer required should be securely archived or destroyed. Archived data may undergo further desensitization before being stored offline, with retrieval strictly limited to exceptional and authorized cases. Driven by regulatory requirements and supported by technical mechanisms, IoV ecosystems have gradually established a closed-loop process characterized by auditable archiving and verifiable destruction. For example, New Jersey’s A4723 Act mandates that in-vehicle storage media be rendered unrecoverable in accordance with NIST SP 800-88 prior to used-vehicle transfer [64]. In industry practice, the Privacy4Cars white paper proposes a VIN-indexed “deletion request–execution–proof” workflow to assist dealers and rental companies in enforcing personal data erasure obligations [65].

Addressing long-term cloud retention risks, van der Kouwe and Verdult demonstrated through the “Grand Theft API” study that vehicle logs could remain callable over extended periods, advocating mandatory retention limits and the enforcement of both physical and logical destruction mechanisms [66]. Zhou et al. proposed a ciphertext-policy attribute-based encryption secure and verifiable deletion model, binding expiration attributes to individual vehicular logs and generating chained deletion proofs to ensure enforceable data erasure [67]. At the infrastructure level, cloud service providers have released operational guidelines; for instance, Google Cloud 2023 white paper details its multi-stage deletion pipelines and hardware decommissioning processes, providing standardized references for automakers and fleet operators [68].

From a research perspective, a survey by Masood et al. highlights that synchronized erasure across replicated data in vehicle–edge–cloud architectures remains challenging, recommending verifiable overwrite counters, while identifying blockchain technologies as promising tools for “read-only sealing with periodic destruction” [11]. Cebe et al. integrated vehicular public key infrastructure with blockchain within a Blockchain-Forensics framework, fragmenting accident-related vehicular data into an immutable ledger to enable low-overhead, traceable, and privacy-aware read-only archiving for post-incident forensics [69]. Similarly, the Accident Forensics-BC system archives driving recorder data into a cold-chain storage under V2X environments and triggers irreversible destruction via off-chain cryptographic key shredding upon retention expiry [70]. Collectively, these efforts establish a compliant, auditable, and technically viable security baseline for IoV data archiving and destruction.

Data lifecycle security requires comprehensive protection measures to be deployed across all stages of data handling. By jointly integrating technical and managerial controls, a closed-loop framework can be established in which data generation is protected, data transmission is encrypted, data storage is isolated, data usage is controlled, and data destruction is verifiable. Only through such an end-to-end approach can the diverse and evolving security threats present in complex IoV environments be effectively mitigated, thereby ensuring the confidentiality, integrity, and availability of vehicular data, while safeguarding user privacy and driving safety.

Within the above mapping, data sharing mainly occurs at the coordinative computing and application layers and corresponds primarily to the data usage and sharing stage of the lifecycle. Therefore, the following discussion focuses on privacy-preserving mechanisms that enable data utility while reducing the exposure of raw vehicles, trajectory, and behavioral information.

4.2. Data Sharing Privacy Protection Strategy

In the IoV ecosystem, the value of vehicular data lies fundamentally in data sharing. By uploading locally sensed information to cloud platforms or exchanging data with other vehicles, IoV systems can enable traffic coordination optimization, cooperative perception, and training of autonomous driving models. However, uncontrolled data sharing poses severe threats to user privacy. To address this challenge, both academia and industry have proposed a range of privacy-preserving techniques for data sharing, including differential privacy, federated learning, blockchain-based mechanisms, homomorphic encryption and secure multi-party computation, as well as fine-grained access control strategies. This section focuses on analyzing the operational mechanisms and challenges of these techniques in IoV data sharing scenarios and provides a comparative evaluation based on recent studies.

4.2.1. Differential Privacy

Differential privacy is a formal privacy notion introduced by Dwork in 2006 to address privacy leakage in statistical databases. Its objective is to ensure that the outcome of a data analysis is insensitive to the inclusion or exclusion of any single record in the dataset, such that whether an individual’s data is present has only a negligible impact on the analysis result [71].

In recent years, differential privacy has increasingly emerged as a mainstream technical approach for mitigating the tension between data utility and privacy leakage in the IoV. Iftikhar et al. developed a local differential privacy (Local-DP)–based sensing and reporting framework, which improved the de-identification success rate by 38% in multi-city simulations, demonstrating that vehicles can upload data without relying on trusted roadside units while maintaining controllable query errors [72].

For location and trajectory data, Ma et al. combined Hilbert curve mapping with an ϵ-DP publishing mechanism, achieving cloud-side query errors within 9.6 m while still satisfying 1-DP constraints [73]. Arif et al. proposed a DP-based generalization algorithm that reduced re-identification rates to 2.1% on a real-world taxi trajectory dataset [74]. In heterogeneous and highly mobile environments, Kim et al. empirically investigated the impact of high vehicle mobility on the convergence of DP-enhanced federated learning (DP-FL) and proposed a dynamic noise injection strategy, limiting performance degradation to less than 10% [75]. Tian et al. further combined personalized federated learning with correlated differential privacy protocols to simultaneously preserve individual model accuracy and group-level privacy in autonomous driving applications [76].

Overall, differential privacy is well suited for data sharing scenarios that prioritize privacy over accuracy, such as statistical data release and global AI model training. However, determining appropriate noise levels that balance privacy protection with traffic efficiency and safety remains an open challenge that requires careful exploration in IoV-specific contexts.

4.2.2. Federated Learning

Federated learning is a distributed machine learning framework based on the principle that data remains local, and it has been increasingly regarded as a privacy-friendly data sharing solution for the IoV in recent years. A key advantage of federated learning lies in the absence of a centralized repository that aggregates all vehicular data, which makes it difficult for adversaries to obtain large-scale private information in a single attack and thereby reduces the risk of centralized data leakage. Moreover, since most computation is performed on the vehicle side, federated learning also alleviates network bandwidth pressure. Consequently, federated learning has been widely viewed as a core privacy-enhancing paradigm for realizing “local data retention and global model sharing” in the IoV environments.

Batool et al. proposed an LDP-FL framework in which only locally perturbed gradients are uploaded. In a scenario involving 50 vehicles, this approach reduced the model inference privacy leakage rate to 0.9% [77]. Sanghyun Byun et al. deeply integrated the vehicular SCMS pseudonym certificate system with secure aggregation protocols for federated learning, enabling the server to reliably verify and aggregate vehicular model updates while preserving identity unlinkability. In real-world vehicle-to-cloud experiments conducted in Colorado over LTE and 5G networks, the median delays for server registration and verification were only 4.83 ms and 4.94 ms, respectively, and the end-to-end latency under 5G was improved by approximately 14.5% on average compared with LTE. These results demonstrate the advantages of the proposed approach in terms of both real-time performance and privacy protection [78].

4.2.3. Blockchain

As a distributed ledger technology, blockchain provides a novel trust foundation for data sharing in the IoV through decentralized consensus mechanisms and cryptographically chained storage [79]. In general, there are two main approaches to applying blockchain in IoV data sharing. The first leverages the immutability and traceability of blockchain to record the entire lifecycle of data generation, access, and sharing, thereby enabling transparent auditing of data usage and clear accountability. The second treats blockchain as a decentralized data exchange platform, replacing architectures in which data are centrally stored and distributed by cloud platforms with a model in which multiple nodes maintain data indices or access permissions.

Blockchain introduces a new paradigm for data sharing and is well suited to serve as a trust intermediary when combined with other privacy-preserving technologies. Recent studies have further integrated blockchain with federated learning by constructing on-chain mechanisms for model parameter sharing and verification, enabling federated learning without centralized coordination [80]. To illustrate how blockchain can support privacy-preserving collaborative learning in IoV, Figure 10 presents an integration framework of federated learning and blockchain.

As shown in Figure 10, vehicles and RSU/edge nodes first perform local model training using locally stored sensors, telematics, driving-behavior, and traffic-context data. Instead of uploading raw vehicular data, participants share only signed or en-crypted model updates. The blockchain coordination layer then provides decentralized registration, identity verification, update validation, immutable logging, incentive or reputation management, and access control. After model updates are verified, the edge/cloud aggregator performs global aggregation and redistributes the updated model to vehicles and RSUs. This framework highlights the complementary roles of federated learning and blockchain: federated learning reduces centralized raw-data exposure, whereas blockchain enhances traceability, tamper resistance, participant accountability, and trustworthy coordination. However, the figure also indicates that such integration may introduce communication overhead, consensus latency, poisoning risks, non-IID data challenges, and scalability constraints, which should be carefully considered in practical IoV deployments.

Some studies have further employed smart contracts to dynamically manage vehicles’ access authorization to data, thereby enhancing the automated enforcement and flexibility of privacy policies [81]. Overall, blockchain technologies hold significant potential for privacy protection in IoV data sharing; however, architectural optimization and careful trade-offs are required to address the inherent tension between system performance and privacy preservation.

4.2.4. Homomorphic Encryption and Secure Multi-Party Computation

Homomorphic encryption and secure multi-party computation (SMPC) aim to enable joint data computation and analysis without revealing raw data and are therefore regarded as cryptographic enablers for privacy-preserving data sharing in IoV [82]. Homomorphic encryption refers to an encryption scheme that allows specific computations to be performed directly on ciphertexts, such that the decrypted result is equivalent to the outcome of operations performed on plaintexts.

SMPC, in contrast, splits original data into multiple random shares distributed among participating parties, which collaboratively compute the desired function through multiple rounds of interaction, while preventing any single party from reconstructing the original data.

The practical challenges of both approaches mainly stem from their computational and communication overhead. As a result, more pragmatic solutions typically adopt task-specific lightweight secure computation protocols, or combine these techniques with differential privacy, blockchain, and other complementary mechanisms to balance privacy protection and system efficiency according to application requirements.

4.2.5. Access Control Strategies

Access control refers to determining who can access which data and under what conditions through policy definitions and authentication mechanisms [83]. In IoV scenarios, vehicular data can be encrypted and stored in cloud platforms according to their privacy sensitivity levels, such that only users possessing specific attribute-based credentials are able to decrypt and access the data.

Access control also faces challenges in policy formulation and management. Given the diversity of vehicular data types, comprehensive policy rules must be defined, and these policies need to be updated in a timely manner to accommodate changes in regulations and user preferences.

The applicability of privacy-preserving mechanisms in IoV data sharing scenarios is strongly influenced by deployment layer, lifecycle stage, latency requirements, computational capability, communication overhead, and privacy–utility trade-offs. Lightweight techniques such as differential privacy are generally suitable for large-scale statistical release and model-update perturbation, whereas cryptographic approaches such as homomorphic encryption and secure multi-party computation provide stronger confidentiality guarantees but usually introduce higher computational and communication costs. Federated learning reduces centralized raw-data exposure through local training and model sharing, while blockchain-based mechanisms are more suitable for auditability, access control, and accountability than for latency-critical protection.

Based on these considerations,

Table 5. Semi-quantitative and lifecycle-oriented comparison of typical privacy-preserving data sharing mechanisms in IoV.

Technique	Main Architectural Layer	Main Lifecycle Stage	Representative IoV Use Cases	Representative Reported Evidence of Performance Tendency	Real-Time Suitability	Main Limitations
Differential privacy	Application layer/coordinative computing layer	Data usage and sharing	Traffic statistics, trajectory publishing, model-update perturbation	Usually introduces low computational overhead because privacy protection is mainly achieved through noise injection; the main measurable cost appears as accuracy or utility loss controlled by the privacy budget ε rather than cryptographic latency [84]	High for large-scale statistical analytics; medium for safety-critical tasks requiring high precision	Privacy–utility trade-off; inappropriate noise calibration may reduce traffic prediction or safety-service accuracy
Federated learning	Vehicle–edge–cloud/coordinative computing layer	Data usage and sharing	Cooperative perception, driving-behavior modeling, cyber-threat detection, traffic prediction	Avoids uploading raw data but introduces communication overhead through iterative model updates; reported IoV-oriented FL/DP schemes show that privacy can be improved while maintaining acceptable learning performance, but communication rounds and model size dominate total latency	Medium to high when aggregation intervals are tolerable; low for hard real-time safety messages	Non-IID vehicle data, poisoning attacks, communication cost, unstable vehicle participation
Homomorphic encryption	Coordinative computing layer/cloud service layer	Data usage and sharing	Encrypted aggregation, privacy-preserving queries, secure trajectory or mobility analytics	Provides strong confidentiality during computation, but ciphertext expansion and cryptographic operations usually lead to high computation and communication overhead; recent automotive-domain surveys identify HE as promising but still constrained by performance and deployment complexity	Low for hard real-time V2X; medium for offline or edge/cloud-supported analytics	High computation cost, ciphertext expansion, key management, limited operation types depending on the scheme
Secure multi-party computation	Edge/cloud collaborative computing layer	Data usage and sharing	Joint traffic analytics, collaborative risk assessment, secure aggregation	Provides strong raw-data protection through interactive computation; automotive-domain surveys note its applicability to privacy-sensitive automotive use cases, but multiple interaction rounds and communication complexity limit scalability in highly dynamic IoV environments	Low to medium; more suitable for small-scale or asynchronous collaborative analytics	Interaction overhead, participant availability, scalability under mobility
Blockchain-based privacy and audit mechanisms	Coordinative computing layer/governance layer	Data storage, usage and sharing, disposal evidence	Access control, data-sharing audit, revocation, contribution evaluation, deletion-proof management	Not ideal for hard real-time protection, but useful for traceability and accountability; an IoV blockchain-based data-sharing scheme reported resilience against 30% poisoning attacks and approximately 26% lower experimental cost than comparable methods [85]	Medium for asynchronous audit and access management; low for millisecond-level safety messaging	Consensus overhead, storage growth, throughput bottlenecks, privacy leakage from on-chain metadata
Hybrid lightweight cryptographic aggregation	Coordinative computing layer/edge layer	Data usage and sharing	Verifiable aggregation of vehicular perception data, multi-dimensional statistics	Recent IoV verifiable aggregation work using homomorphic MAC and secret sharing reported about 74.5 ms computation on the edge-node side and about 3.8 ms on the data-requester side when processing 3000 RSUs and 500-dimensional vectors, indicating that carefully designed hybrid schemes can be more practical than heavyweight cryptographic approaches [58]	Medium; potentially suitable for edge-assisted near-real-time analytics	Function-specific design, limited generality, complexity of security proof and system integration

compares representative privacy-preserving data sharing mechanisms from a lifecycle-oriented and engineering-oriented perspective.

As shown in Table 5, the practical applicability of privacy-preserving mechanisms in IoV depends not only on their theoretical privacy strength, but also on their deployment layer, lifecycle stage, and measurable performance cost. Differential privacy is generally more suitable for large-scale statistical release and model-update perturbation because its additional computational cost is relatively low, although the resulting utility loss depends strongly on the privacy budget. Federated learning reduces centralized raw-data exposure, but the communication cost of iterative model aggregation makes it more appropriate for periodic or edge-assisted analytics than for hard real-time safety messaging. Homomorphic encryption and secure multi-party computation provide stronger confidentiality guarantees during computation, but they usually introduce higher computation and communication overhead and are therefore more suitable for offline, cloud-assisted, or limited-scope analytics. Blockchain-based mechanisms are more valuable for auditability, access control, accountability, and lifecycle evidence management than for latency-critical communication protection.

Therefore, Table 5 does not imply that one privacy-preserving technique is universally superior to the others. Instead, the choice of mechanism should be guided by the target lifecycle stage, data sensitivity, latency budget, deployment scale, and compliance requirements. In practical IoV systems, hybrid designs are often more feasible. For example, differential privacy or federated learning may be used for large-scale model training, lightweight cryptographic aggregation may be applied at the edge for verifiable statistics, and blockchain may provide audit trails for access control, revocation, and data disposal evidence. The comparison also suggests that quantitative performance evaluation in IoV privacy protection should not rely on a single metric. Computation time, communication overhead, model accuracy loss, ciphertext expansion, consensus delay, and privacy budget should be jointly reported according to the specific lifecycle stage and deployment scenario.

4.3. Location and Privacy Model and Anonymization

Vehicle location trajectories and driving behavior data constitute some of the most sensitive forms of personal information in the IoV and protecting location–behavior privacy is therefore a critical concern. Commonly used location anonymization models and techniques include pseudonymization, trajectory obfuscation, k-anonymity, mix-zone mechanisms, dummy location generation, and path confusion. These methods aim to reduce the linkability of vehicle identities, trajectories, and service requests while maintaining sufficient data utility for safety and mobility services. From the lifecycle-oriented perspective adopted in this review, location anonymization mainly operates across the data collection, transmission, and usage stages, and it requires coordination among the sensing layer, network access layer, coordinative computing layer, and application layer.

4.3.1. Pseudonym-Based Unlinkability

Pseudonyms and Frequent Changes: In V2X communications, vehicles are required to periodically broadcast their status information for reception by neighboring vehicles and roadside units. These messages are typically signed using vehicular digital certificates. However, if a vehicle relies on a long-term identifier, adversaries can track a specific vehicle by correlating spatiotemporally continuous messages. To mitigate this risk, the IEEE 1609.2-2022 [86] recommends that vehicles use a series of short-term certificates, referred to as pseudonyms, instead of real identity identifiers, and switch them periodically [87]. Ideally, messages signed under different pseudonyms cannot be directly linked to the same vehicle, thereby protecting location privacy.

Nevertheless, pseudonym changes alone are insufficient to fully prevent tracking. If pseudonym change strategies are improperly designed, adversaries may still correlate old and new identities by exploiting the continuity of vehicle movement patterns [88]. To enhance vehicular location anonymity, researchers have proposed various strategies, including synchronized pseudonym changes, silent zones or silent periods, and diversified pseudonym switching mechanisms.

4.3.2. Trajectory Obfuscation and k-Anonymity

Adversaries may also identify vehicles by analyzing continuous movement trajectories. Therefore, it is necessary to obfuscate and anonymize vehicular trajectory data. One common approach is to reduce trajectory precision. A classical method is k-anonymity-based region cloaking, in which a vehicle’s exact location is represented by a region that contains at least k vehicles, making it impossible to distinguish a single vehicle within that region [89].

In addition, semantic clustering-based anonymization techniques have been proposed, whereby vehicles are grouped according to destination similarity or behavioral patterns. Trajectories within the same group are then generalized using a unified representation, preventing vehicles with anomalous or unique movement patterns from being singled out and identified.

4.3.3. Path Confusion and Dummy Information Injection

Path confusion refers to deliberately perturbing the reported driving routes of vehicles, making it difficult for external observers to accurately reconstruct the true trajectories [90]. A simple approach is to introduce random noise offsets along the actual path, resulting in slightly distorted trajectories that no longer precisely align with real road networks [91]. More advanced methods include generating fake trajectory sets and group-based path confusion techniques [92].

In addition, anonymization can be applied to behavioral data through controlled perturbation. For example, when publishing driving behavior statistics, interval generalization or noise injection can be employed to avoid precise attribution to individual drivers [93]. These processing techniques protect driver privacy from direct identification without significantly degrading the utility of aggregated analyses.

Protecting location and behavior privacy requires achieving a balance between system functionality and privacy preservation. This balance necessitates coordinated efforts across technical, managerial, and legal dimensions. Through the careful design of anonymization models and the strict enforcement of data governance policies, vehicle owners’ movement patterns and driving habits can be effectively safeguarded against misuse or exposure, thereby maintaining public trust in smart transportation systems.

5. Active Defense: Intrusion Detection and Response

Active defense refers to protecting IoV systems by continuously detecting malicious behaviors, evaluating trustworthiness, and taking appropriate response actions during system operation. From a lifecycle-oriented perspective, active defense is mainly associated with the data transmission, data usage, and operational monitoring stages, because attacks are often identified through communication messages, sensor observations, vehicle behavior records, RSU events, cloud alerts, OTA logs, and service-access traces. From an architectural perspective, active defense spans the network access layer, coordinative computing layer, and application layer, and in some cases also extends to the sensing layer when sensor spoofing or false-data injection needs to be detected.

Accordingly, intrusion detection, misbehavior detection, collaborative trust management, LLM-assisted alert analysis, and dynamic response mechanisms should not be regarded as isolated security functions. Rather, they form an operational security loop across the IoV lifecycle: suspicious data or behaviors are observed at the sensing and network access layers, aggregated and correlated at edge/cloud or coordinative computing layers, evaluated through IDS or trust-management mechanisms, and finally translated into mitigation actions such as message filtering, trust-score adjustment, certificate revocation, access restriction, software isolation, or incident reporting. This section therefore analyzes active defense mechanisms according to their deployment layer, lifecycle stage, detection evidence, and response function.

From a cross-layer and lifecycle-oriented perspective, active defense in IoV can be understood as an operational security loop across sensing, communication, edge/cloud coordination, and application services. Different mechanisms contribute to different stages of this loop: some detect abnormal messages or behaviors during data transmission, some evaluate trustworthiness during data usage and service interaction, and others support incident analysis, mitigation, and governance-oriented response. To clarify these relationships,

Table 6. Cross-layer and lifecycle mapping of active defense mechanisms in IoV.

Active Defense Mechanism	Primary Architectural Layer	Main Lifecycle/Operation Stage	Detection Evidence	Main Function	Typical Response
Rule-based misbehavior detection	Network access layer/sensing layer	Data transmission/operational monitoring	Message format, protocol rules, physical plausibility	Fast detection of known attacks or rule violations	Alarm, message filtering, warning suppression
Statistical anomaly detection	Network access layer/coordinative computing layer	Data transmission/data usage	Traffic patterns, mobility behavior, sensor consistency	Detection of deviations from normal behavior	Anomaly flagging, risk scoring, local mitigation
Machine learning-based IDS	Coordinative computing layer/application layer	Data usage/operational monitoring	CAN traces, V2X messages, cloud logs, vehicle behavior data	Pattern learning and complex attack detection	Classification, alert generation, adaptive filtering
Collaborative trust and reputation management	Network access layer/coordinative computing layer	Data transmission/data usage	Direct observations, neighbor recommendations, misbehavior reports	Dynamic trust evaluation and insider threat mitigation	Trust-score update, message weighting, revocation recommendation
LLM-assisted security analytics	Coordinative computing layer/cloud service layer	Data usage/incident analysis	Security logs, RSU events, OTA records, IDS alerts	Alert correlation, incident summarization, analyst support	Human-in-the-loop triage, evidence-grounded reporting
Dynamic intrusion response	Coordinative computing layer/application layer	Operational response/lifecycle governance	IDS outputs, trust values, access events, attack severity	Attack containment and resilience enhancement	Isolation, access restriction, CRL update, OTA rollback, incident reporting

summarizes representative active defense mechanisms according to their primary architectural layer, lifecycle or operational stage, detection evidence, main security function, and typical response action.

Table 6 shows that active defense mechanisms are primarily deployed after data has been generated and communicated, but before malicious effects propagate into safety-critical services or long-term system states. Rule-based and statistical methods are more suitable for time-sensitive filtering at the sensing or network access layer, whereas machine learning-based IDSs, collaborative trust management, and LLM-assisted analytics are more appropriate for edge/cloud-supported correlation, decision support, and governance-oriented response. This layered deployment logic also explains why active defense should be coordinated with the lifecycle protection mechanisms discussed in Section 4: privacy-preserving data processing reduces unnecessary exposure, while intrusion detection and response mechanisms ensure that abnormal behaviors can be discovered, traced, and mitigated during operation.

5.1. Malicious Behavior Detection Technology

Misbehavior detection aims to identify abnormal or malicious behaviors of vehicular nodes within the network. When attackers bypass passive defense mechanisms such as encryption and authentication, misbehavior detection systems can analyze behavioral characteristics to recognize such threats, thereby preventing erroneous information from jeopardizing traffic safety. According to their underlying implementation principles, misbehavior detection techniques in IoV can be categorized into rule-based, statistical, and machine learning–based approaches.

Figure 11 compares the three major categories of misbehavior detection methods from the perspectives of input data, core detection logic, typical outputs, deployment layers, lifecycle stages, and main limitations.

5.1.1. Rule-Based Malicious Behavior Detection

Rule-based intrusion detection relies on a predefined rule set to identify known malicious patterns. The system matches received messages and observed behaviors against security policies or attack signatures stored in a knowledge base. Once an attack indicator that satisfies a predefined rule is detected, an alarm is triggered immediately.

One application of rule-based methods in IoV is specification-based detection, which defines rules according to communication protocols and normal physical behaviors of vehicles. Although this approach still relies on manually crafted rules or policies, the rules are derived from strict specifications of normal behavior patterns, enabling the detection of certain novel attacks that do not yet appear in signature databases [94].

5.1.2. Statistical Malicious Behavior Detection

Statistical methods identify anomalies by exploiting statistical characteristics of vehicular behaviors and network traffic and are therefore also referred to as anomaly detection approaches. The basic idea is to construct a statistical model or baseline of normal behavior during the training phase. In the detection phase, real-time observations are compared against the normal model, and deviations are evaluated to determine whether they exceed predefined thresholds, thereby indicating the occurrence of anomalies. Common statistical detection techniques include threshold-based detection, probabilistic model–based detection, and clustering analysis [95].

A key advantage of statistical methods lies in their ability to detect previously unknown types of attacks. However, their main challenge is the accurate modeling of normal behavior. In complex and highly dynamic traffic environments, normal behavior patterns may evolve over time, which can lead to increased false positives.

In IoV systems, common examples of statistical anomaly detection include plausibility checks and consistency checks. The former focuses on data from individual vehicles, while the latter examines multisource data or information reported by multiple vehicles.

5.1.3. Machine Learning-Based Malicious Behavior Detection

Machine learning-based intrusion detection systems (IDSs) train models on large volumes of normal and attack samples to automatically learn complex patterns for distinguishing normal behaviors from anomalous ones. According to different learning paradigms, these methods can be further classified into supervised and unsupervised approaches [96]. Supervised learning relies on pre-labeled attack samples for training, with representative algorithms including support vector machines, random forests, extreme gradient boosting trees, and deep neural networks. Unsupervised learning methods are applied in the absence of labeled data and typically include clustering-based approaches and autoencoders, which are used to discover previously unknown attack patterns.

The main advantages of machine learning-based methods lie in their high detection accuracy and strong capability to model complex behaviors. When applied to large-scale datasets, machine learning models can capture subtle feature correlations that are difficult to describe using manually crafted rules. However, these methods also suffer from several limitations, including strong dependence on training data quality, limited model interpretability, vulnerability to adversarial examples, and computational constraints that may prevent the deployment of large or deep models on resource-limited platforms.

In practical systems, hybrid detection architectures are often constructed. To balance real-time performance and detection accuracy, recent studies commonly adopt a two-layer architecture combining lightweight rule-based filtering with deep learning–based detection. For example, the HybridSecNet framework proposed by Chougule et al. first employs simple trigger-based rules to filter and reduce 82% of the traffic volume and then applies an LSTM–CNN model for sequential classification [97]. Similar design philosophies have also been validated in the LightGBM–MobileNetV2 framework and the Cross-Check system, both of which significantly reduce computational overhead on the vehicle side while maintaining detection rates exceeding 98% [98,99].

Misbehavior detection is a key component of IoV security protection. Its performance is typically evaluated using metrics such as detection rate, false positive rate, false negative rate, detection latency, and resource overhead. The detection rate and false positive rate can be defined as Equations (1) and (2):

$$DR={\displaystyle \frac{TP}{TP+FN}}$$

(1)

$$FAR={\displaystyle \frac{FP}{FP+TN}}$$

(2)

Here, $TP$ and $FP$ denote the number of true attacks correctly detected and the number of normal behaviors incorrectly reported as attacks, respectively, while FN and TN represent the number of undetected attacks and the number of normal behaviors correctly ignored. A better balance among these metrics indicates superior performance of the detection system.

5.1.4. LLM-Assisted Security Analytics in IoV

In the layer–lifecycle mapping adopted in this review, LLM-assisted security analytics mainly operates at the coordinative computing and cloud-service layers and corresponds to the data usage, operational monitoring, and incident-analysis stages, rather than the hard real-time data transmission stage. Large language models (LLMs) can serve as an auxiliary intelligence layer for IoV security operations, particularly for semantic analysis of heterogeneous security evidence (e.g., in-vehicle logs, V2X traces, RSU events, cloud alerts, and OTA records). Unlike cryptographic authentication or packet-level detection, LLMs are more suitable for alert correlation, incident summarization, knowledge retrieval, and analyst-facing explanation. A practical deployment model is a hybrid architecture: time-critical protection remains on vehicles/RSUs, while LLM-based reasoning is performed at edge/cloud tiers for triage and decision support. To improve reliability, LLM outputs should be grounded in trusted knowledge bases (e.g., via RAG) and treated as advisory rather than authoritative decisions.

However, LLM-assisted defense introduces risks including hallucinated conclusions, prompt injection, privacy leakage in log processing, and unstable inference latency. Therefore, LLM outputs should be constrained by evidence traceability, access control, audit logging, and human-in-the-loop validation. At present, LLMs are more suitable for security support than hard real-time vehicular control, and future work should evaluate their effectiveness under IoV-specific constraints such as latency, robustness, and compliance integration.

To provide a clearer and more structured view of the practical role of LLMs in IoV proactive defense,

Table 7. LLM Capability–Risk–IoV Adaptation.

Capability	Main Value	Key Risk	IoV Adaptation
Alert/log correlation	Multi-source semantic triage	Hallucinated links	Use after rule-based pre-filtering; require evidence traceability
Knowledge retrieval & triage support	Faster mapping to threats/mitigations	Unsupported or outdated advice	Use RAG with curated IoV security sources
Explainable reporting	Better analyst/auditor communication	Oversimplification	Template-guided outputs + human review
Vehicle-side direct use	Potential local intelligence	Latency/compute/certification limits	Prefer edge/cloud; avoid hard real-time control

summarizes the main LLM-enabled security support functions and compares their advantages, potential risks, and adaptation strategies under vehicular system constraints. This comparison is intended to complement the above discussion by highlighting both the opportunities and the deployment boundaries of LLM-assisted defense in safety-critical IoV environments.

As summarized in Table 7, the main contribution of LLMs in IoV security lies in enhancing semantic analysis, cross-source alert correlation, and analyst-oriented decision support, rather than replacing deterministic and real-time protection mechanisms. Accordingly, their integration should follow a hybrid and evidence-grounded design, with policy constraints, auditability, and human-in-the-loop validation to ensure reliability and safety.

5.2. Collaborative Trust and Reputation Management

In open IoV environments, relying solely on observations from individual intrusion detection nodes is often insufficient to timely and accurately identify all threats. Introducing collaborative trust and reputation management mechanisms—enabling vehicles to share security-related information with each other and with cloud entities and to evaluate mutual trustworthiness—has become an important strategy for enhancing the effectiveness of misbehavior detection [100]. Trust management assigns dynamic trust values or reputation scores to vehicles or messages to reflect the credibility of their historical behaviors, thereby supporting security-related decision-making. A hybrid trust/reputation management system is illustrated in Figure 12.

When vehicle node A evaluates a target node B, the A module first generates a raw direct observation score $S_{A\to B}\left(t\right)$ for the current interaction based on observed behavioral evidence. The B module then aggregates recommendations from neighboring vehicles or roadside units (RSUs) and produces an indirect trust value $T_{ind}^{A\to B}(t)$ by weighing these recommendations according to the reputations of their sources.

These two values, together with the previous round’s composite trust value $T^{A\to B}(t)$, are fed into the C module, where temporal decay and fusion are applied to derive a new composite trust value $T^{A\to B}(t+1)$. The updated composite trust is then provided to the F module to support real-time decision-making by combining thresholding with IDS outputs, while violation evidence is forwarded to the E module for long-term reputation accumulation and reward–penalty enforcement. The aggregated evidence and revocation recommendations are periodically reported to the Misbehavior Authority (MA) to trigger certificate revocation procedures, such as Certificate Revocation Lists (CRLs) or Delta CRLs. Meanwhile, the D module is responsible for disseminating local updates and integrating external evaluations, applying weighting schemes or evidence-theoretic methods to attenuate the impact of recommendation manipulation.

To balance response speed and resistance to manipulation, either a double-step (D–S) update or a single-stage update can be adopted.

D-S update: direct observations are first smoothed using exponential smoothing, and then combined with weight recommendations, as shown in Equations (3) and (4).

$$T_{dir}^{A\to B}\left(t\right)=\lambda T_{dir}^{A\to B}\left(t-1\right)+(1-\lambda )S_{A\to B}\left(t\right)$$

(3)

$$T^{A\to B}\left(t+1\right)=\alpha T_{dir}^{A\to B}\left(t\right)+\left(1-\alpha \right)T_{ind}^{A\to B}\left(t\right),\alpha >0.5$$

(4)

The single-step update is shown in Equation (5).

$$T^{A\to B}\left(t+1\right)=\gamma T^{A\to B}\left(t\right)+\alpha S_{A\to B}\left(t\right)+\beta T_{ind}^{A\to B}\left(t\right),\gamma +\alpha +\beta =1,\alpha >\beta$$

(5)

In the above trust update equations, λ denotes the temporal decay factor that controls the influence of historical direct trust observations, enabling a balance between trust stability and responsiveness to recent behavior changes. The parameter α represents the weight of direct trust derived from first-hand observations and is typically set larger than 0.5 to ensure robustness against recommendation manipulation attacks. The parameter β determines the contribution of indirect trust aggregated from neighboring vehicles or infrastructure, providing complementary information when direct interactions are limited, while preventing excessive influence from potentially malicious recommendations. The parameter γ represents the weight assigned to the previous composite trust value in the single-stage update model and is used to smooth trust evolution over time. Together, λ, α, β, and γ allow flexible trust adaptation under highly dynamic IoV conditions by balancing historical stability, direct observations, indirect recommendations, and recent behavioral evidence.

When D–S evidence theory is adopted, direct observations and recommendations are first transformed into Basic Probability Assignments (BPAs) and combined using Dempster’s rule, and the result is then fused with historical trust using a discounting factor. The decision executor enforces pass, rate-limiting, or isolation actions based on composite trust thresholds in conjunction with IDS outputs, while gray-zone cases may trigger additional probing to reduce misclassification. A lower bound imposed on direct trust can further mitigate recommendation manipulation.

5.3. Dynamic Intrusion Response and Mitigation

When an intrusion detection system identifies anomalies or attacks, how to promptly respond and mitigate their impact constitutes the final line of defense in active protection. In IoV environments, dynamic intrusion response mechanisms encompass various mitigation strategies implemented both within vehicles and at the network level. Vehicular intrusion response can be regarded as an execution module following IDS, with the objective of minimizing the damage caused by attacks while preserving driving safety and maintaining system functionality continuity as much as possible [101].

According to the degree of automation and the scope of response execution, intrusion response mechanisms can be classified into local response and collaborative response. Local response is independently carried out by a vehicle’s onboard security modules, whereas collaborative response involves cooperation among multiple vehicles or between vehicles and the cloud [102]. Collaborative response requires dedicated communication protocols to exchange intrusion intelligence and response commands.

In recent years, in-vehicle intrusion detection has evolved from mere detection toward autonomous response. Saini and Islam further pushed response logic down to the hardware layer by implementing a reconfigurable CAN protocol on FPGA. Their MGEESM module targets multiple types of frame errors and achieves detection within a minimum of 3.28 ms, while the BOAD111 module detects bus-off attacks under multi-node threat models with a minimum latency of 3.247 ms and a fixed recovery latency of only 0.704–1.408 ms, along with reported power and energy overheads [103]. Hamad et al. proposed the REACT system, which integrates risk assessment, candidate mitigation evaluation, and multi-algorithm response selection into an onboard embedded platform. For two representative attack message spoofing and flooding, the system completes response decision-making within 30 ms, with very low memory consumption, demonstrating the feasibility of real-time in-vehicle mitigation [104].

To accommodate highly dynamic V2X traffic, Kurunathan et al. combined advantage actor–critic (A2C) reinforcement learning with LSTM-based sequence modeling, introducing a four-level action space comprising allow flag, monitor, and block. Experimental results show that the model converges over time while maintaining high detection accuracy and sensitivity, enabling online adaptive policy updates without manual intervention [105]. At the vehicle–cloud collaborative level, Andreica et al. developed a three-layer framework consisting of an in-vehicle Android head unit, a cloud-based IDS, and a blockchain layer. Local instances perform preliminary screening, while the cloud applies transfer learning to jointly model CAN logs from three identical vehicles, achieving per-frame inference times ranging from 0.62 to 171.89 µs. All alerts and ISO/SAE 21434 risk assessment results are recorded on the blockchain, with measured upload latencies of approximately 106 ms over 4G networks, providing transparent and traceable event reporting without sacrificing real-time performance [106].

Collectively, these studies outline three evolutionary paths for intrusion response in IoV systems: (1) shortening the detection–mitigation loop through fast decision-making or hardware-level remediation on the vehicle side; (2) enabling adaptive strategy updates for unknown attacks via deep reinforcement learning; and (3) leveraging cloud computing and blockchain technologies to support cross-vehicle collaborative detection and compliance-oriented reporting. From different perspectives, these approaches validate the critical role of dynamic mitigation mechanisms in enhancing the security resilience of intelligent connected vehicles.

6. Standards, Regulatory Realization, and Design Implications for IoV Security and Privacy

With the rapid deployment of intelligent connected vehicles, cybersecurity and privacy protection have gradually evolved from isolated technical concerns into mandatory governance requirements throughout the vehicle lifecycle. Recent international and national regulations, including UNECE WP.29 R155 [107], UNECE WP.29 R156, [108] ISO/SAE 21434 [109], and the Chinese standards GB 44495 [110] and GB 44496 [111], have established a more explicit compliance framework for vehicle cybersecurity management, software update security, and risk control. However, for IoV systems, regulatory compliance cannot be achieved merely by understanding the text of standards. A more critical issue is how to translate these regulatory expectations into deployable engineering mechanisms across vehicle design, development, operation, maintenance, and supply-chain collaboration. Therefore, this section distinguishes between regulatory requirements and technical realization pathways, so as to better reflect the lifecycle-oriented governance logic of IoV security and privacy.

6.1. Regulatory Requirements and Standardization Basis

6.1.1. UNECE WP.29 R155/R156

UNECE WP.29 has become one of the most influential regulatory frameworks for automotive cybersecurity and software update governance. Among them, R155 requires manufacturers to establish and maintain a Cybersecurity Management System (CSMS), covering risk identification, threat mitigation, monitoring incident response, and organizational accountability throughout the vehicle lifecycle [107]. Its focus is not limited to in-vehicle components, but extends to external interfaces, backend services, supply-chain dependencies, and post-deployment operations. In essence, R155 emphasizes that cybersecurity should be managed as a systematic and auditable process rather than as a one-time technical add-on.

In parallel, R156 introduces requirements for Software Update Management Systems (SUMS) and stresses that software updates, especially OTA updates, must be secure, traceable, and verifiable [108]. This means that manufacturers need to ensure update authenticity, integrity, version control, rollback safety, and post-update validation. For IoV systems, where software-defined functionality is increasingly important, R156 highlights that software updates are not merely maintenance activities, but security-critical lifecycle events directly related to safety and compliance.

6.1.2. ISO/SAE 21434

Compared with UNECE regulations, ISO/SAE 21434 provides a more engineering-oriented framework for implementing automotive cybersecurity. It defines cybersecurity activities across concept, product development, production, operation, maintenance, and decommissioning stages, and emphasizes the integration of cybersecurity into engineering processes [109]. A key contribution of this standard is the introduction of structured practices such as Threat Analysis and Risk Assessment (TARA), cybersecurity goals, claims and assumptions, verification and validation, and post-production monitoring.

For IoV systems, ISO/SAE 21434 is particularly important because it provides a process-oriented bridge between abstract security requirements and concrete development tasks. It helps manufacturers and suppliers embed cybersecurity considerations into architecture design, interface analysis, component interaction, and lifecycle traceability, thereby reducing the gap between regulatory compliance and technical implementation.

6.1.3. Chinese Standards GB 44495 and GB 44496

In China, GB 44495 and GB 44496 further strengthen the governance requirements for automotive cybersecurity and software updates in the context of intelligent and connected vehicles These standards reflect the growing emphasis on data security, platform responsibility, secure update capability, and traceable operation management in the domestic regulatory environment. Compared with purely technical guidelines, they also highlight organizational governance, responsibility assignment, and evidence preservation, which are essential for regulatory inspection and industrial deployment.

Taken together, these standards and regulations indicate a common trend: IoV cybersecurity is no longer evaluated only by whether a specific mechanism is deployed, but by whether manufacturers can demonstrate continuous, auditable, lifecycle-oriented security governance capability.

6.2. Compliance-Oriented Technical Realization Pathways

While regulations and standards define what should be achieved, engineering practice must answer how these requirements can be operationalized in real IoV systems. From this perspective, regulatory compliance should be mapped to concrete technical realization pathways spanning risk assessment, software and asset management, cryptographic protection, evidence retention, incident response, and supply-chain coordination.

6.2.1. TARA-Driven Security Design

A foundational realization pathway is to integrate Threat Analysis and TARA into the early stages of system design. Instead of treating cybersecurity as a post hoc check, TARA enables developers to identify assets, threat scenarios, attack paths, and impact severity at the concept and architecture levels. For IoV systems, this is especially important because risks may emerge not only from in-vehicle components, but also from V2X interfaces, cloud platforms, mobile applications, OTA channels, and third-party service dependencies. By linking risks to security goals and mitigation claims, TARA provides a structured basis for aligning technical controls with regulatory expectations.

6.2.2. Software Update Security and Traceability Mechanisms

Given the increasing software complexity of intelligent vehicles, secure compliance also depends on transparent software composition and update governance. A practical realization pathway is to establish Software Bill of Materials (SBOM)-oriented asset visibility and combine it with secure update mechanisms. This helps identify software dependencies, vulnerable components, and version relationships, thereby improving vulnerability management and patch traceability. In the context of OTA updates, technical controls should include update package signing, integrity verification, secure distribution, version control, rollback protection, and post-update validation. These mechanisms translate the regulatory requirements of software update security into auditable engineering practices.

6.2.3. Key Management and Trusted Execution

Cryptographic security in IoV systems depends not only on algorithms themselves, but also on robust key management and trusted execution environments. In practice, this requires secure key generation, storage, distribution, renewal, revocation, and compromise recovery. Hardware-supported trust anchors, such as HSMs, secure elements, or trusted execution mechanisms, can enhance resistance to tampering and credential theft. For V2X, OTA, and cloud-connected functions, lifecycle-based key governance is essential to ensure authentication, confidentiality, and secure service continuity. Thus, key management serves as a central engineering mechanism connecting regulatory requirements with actual system trustworthiness.

6.2.4. OTA Evidence Chains, Logging, and Auditability

Another important realization pathway is the establishment of evidence-oriented logging and audit mechanisms. Regulatory compliance increasingly depends on whether manufacturers can prove that cybersecurity and software update activities were performed as claimed. Therefore, IoV systems should support secure logging of update actions, configuration changes, anomaly events, access behaviors, and incident handling records. For OTA scenarios in particular, an auditable evidence chain should include update source authentication, version history, deployment records, execution status, and rollback traces. Such evidence not only supports internal governance but also strengthens external auditability and post-incident forensics.

6.2.5. Incident Response and Post-Production Monitoring

Lifecycle governance also requires the ability to detect, analyze, and respond to cybersecurity incidents after vehicles have been deployed. Therefore, incident response should be treated as a continuous operational capability rather than an isolated emergency process. This includes anomaly monitoring, attack confirmation, severity assessment, containment, recovery, vulnerability remediation, and feedback into subsequent risk analysis. For large-scale IoV ecosystems, incident response should further support cross-domain coordination among vehicles, RSUs, cloud platforms, and backend service providers. In this sense, post-production cybersecurity monitoring is a direct engineering embodiment of the lifecycle governance required by current regulations.

6.2.6. Supply-Chain Collaboration and Compliance Integration

Finally, because IoV systems involve OEMs, Tier-1/Tier-2 suppliers, software vendors, cloud providers, and service operators, compliance cannot be achieved by a single actor in isolation. A feasible realization pathway is to establish supply-chain collaborative cybersecurity mechanisms, including responsibility allocation, interface security requirements, vulnerability disclosure workflows, evidence-sharing procedures, and coordinated update/response processes. In addition, regulatory requirements should be integrated into development tool chains and management workflows, so that compliance evidence can be generated and maintained continuously rather than reconstructed passively during audits. This is particularly important for cross-platform and cross-regional deployment scenarios.

6.3. Closed-Loop Mapping from Regulatory Objectives to Technical Mechanisms and Implementation Evidence

Although existing regulations and standards provide increasingly explicit cybersecurity requirements for intelligent connected vehicles and IoV ecosystems, practical deployment still depends on whether such requirements can be translated into concrete technical mechanisms and verifiable implementation evidence. Therefore, beyond separately discussing regulatory provisions and technical pathways, a closed-loop mapping is needed to connect regulatory requirements, engineering controls, and implementation evidence within a unified governance framework.

From a regulatory perspective, standards and regulations such as UNECE R155, UNECE R156, and ISO/SAE 21434 emphasize several recurring requirements, including cybersecurity risk assessment, secure software update management, traceable incident monitoring, vulnerability handling, and lifecycle-oriented security governance. However, these documents typically define what should be achieved rather than fully specifying how such objectives should be implemented in heterogeneous IoV environments. As a result, technical realization requires a structured translation from compliance objectives into deployable mechanisms.

At the engineering level, these requirements can be mapped to several core mechanism groups. First, risk assessment and security analysis requirements can be operationalized through TARA, attack surface identification, asset classification, and trust-boundary modeling. Second, secure communication and identity management requirements can be realized through PKI-based authentication, certificate lifecycle management, pseudonym schemes, secure key distribution, and access control mechanisms. Third, software update and system integrity requirements can be supported by secure OTA architecture, code signing, integrity verification, SBOM-based software traceability, and rollback protection. Fourth, continuous monitoring and incident response requirements can be implemented using intrusion detection systems, anomaly detection models, security logging, edge-assisted event correlation, and coordinated vulnerability management workflows. Fifth, privacy and data governance requirements can be translated into technical protection such as differential privacy, federated learning, homomorphic encryption, secure multiparty computation, secure data deletion, and auditable data access control.

More importantly, effective governance requires that these mechanisms be associated with observable and reviewable forms of evidence. In this sense, implementation evidence serves as the closing element of the compliance loop. For example, TARA documentation, attack trees, and risk treatment records provide evidence that cybersecurity risk assessment has been comparatively conducted. Certificate issuance logs, key rotation records, and authentication success/failure traces provide evidence of identity and communication security management. Secure OTA deployment records, signature verification results, SBOM artifacts, and update rollback logs provide evidence for software update compliance and software supply-chain integrity. Similarly, incident logs, IDS alert reports, security monitoring dashboards, and vulnerability remediation records can demonstrate the effectiveness of continuous monitoring and incident response. For privacy governance, evidence may include data classification records, privacy budget settings, access audit logs, secure erasure records, and documentation of privacy-preserving model training processes.

This requirement–mechanism–evidence mapping highlights that IoV cybersecurity should not be understood as a collection of isolated technical tools, but rather as a lifecycle-oriented governance process in which compliance objectives are continuously translated into engineering controls and then validated through operational evidence. Such a closed-loop perspective is particularly important for intelligent connected vehicles, where security, privacy, software maintainability, and regulatory accountability must be jointly satisfied across vehicles, roadside infrastructure, edge platforms, and cloud services. Therefore, the practical value of IoV cybersecurity architecture depends not only on its defensive capability, but also on whether it can support traceability, auditability, and continuous compliance throughout the system lifecycle.

To better connect regulatory expectations with engineering practice, this review further establishes a closed-loop mapping from regulatory objectives to representative technical mechanisms and representative implementation evidence/artifacts. Since current automotive cybersecurity standards and regulations generally define what should be achieved rather than prescribing a single implementation route, the mapping in

Table 8. Closed-loop mapping from regulatory objectives to representative technical mechanisms and implementation evidence/artifacts in IoV cybersecurity governance.

Regulatory Objective	Representative Standards/Regulations	Representative Technical Mechanisms	Representative Implementation Evidence/Artifacts
Cybersecurity risk assessment and treatment	ISO/SAE 21434; UNECE R155	TARA, asset identification, attack surface analysis, trust-boundary modeling, risk treatment planning	TARA reports, risk treatment records, attack trees, cybersecurity case documents, security design records
Secure identity and communication management	ISO/SAE 21434; UNECE R155	PKI, certificate lifecycle management, pseudonym schemes, key management, secure authentication, access control	Certificate issuance/renewal logs, key rotation records, authentication logs, credential management records
Secure software update and software integrity assurance	UNECE R156; ISO/SAE 21434	Secure OTA architecture, code signing, integrity verification, rollback protection, software traceability mechanisms	OTA update logs, signature verification records, rollback audit trails, software inventory/traceability artifacts
Continuous monitoring and incident response	UNECE R155; ISO/SAE 21434; NHTSA cybersecurity best practices	Intrusion detection systems, anomaly detection, security logging, event correlation, vulnerability management workflows, post-deployment monitoring	IDS alerts, incident reports, monitoring dashboards, vulnerability remediation records, security event logs
Privacy-aware data governance	Applicable data protection requirements; cybersecurity-related engineering practices	Differential privacy, federated learning, homomorphic encryption, secure multiparty computation, access auditing, secure deletion	Access audit trails, privacy parameter records, secure erasure records, model-training governance logs, data handling records
Lifecycle cybersecurity governance	UNECE R155/R156; ISO/SAE 21434	Cross-layer coordination, secure development processes, software maintenance workflows, post-production security activities, compliance workflow integration	Process documentation, audit records, configuration baselines, review reports, change-management records

Note: Table 8 presents a representative closed-loop mapping rather than a one-to-one mandatory correspondence. The standards and regulations listed in the second column primarily define regulatory or engineering objectives, while the third and fourth columns summarize feasible technical realization paths and auditable evidence/artifacts commonly associated with those objectives in IoV cybersecurity practice. UNECE R155 emphasizes cybersecurity management systems and risk management, UNECE R156 focuses on software update management systems, and ISO/SAE 21434 provides a process-oriented framework for automotive cybersecurity engineering.

is intended to summarize feasible engineering realizations and auditable evidence forms in IoV security governance.

As shown in Table 8, IoV cybersecurity compliance should not be understood as the deployment of isolated security functions alone. Instead, effective governance requires a closed-loop realization process in which regulatory objectives are translated into deployable technical mechanisms and are further supported by traceable implementation evidence. This mapping also indicates that the maturity of an IoV cybersecurity architecture should be evaluated not only by its defensive functionality, but also by its auditability, traceability, and lifecycle maintainability across vehicles, roadside infrastructure, edge platforms, and cloud services.

Overall, the value of current standards and regulations lies not only in defining cybersecurity obligations, but in driving the transition from fragmented technical protection to lifecycle-oriented governance. For IoV systems, the key challenge is no longer simply whether a certain security mechanism is present, but whether the entire system can support risk-based design, secure update operation, trusted credential management, evidence preservation, incident response, and supply-chain coordination in an auditable and sustainable manner. Therefore, the combined perspective of regulatory requirements + technical realization pathways provides a more suitable analytical framework for understanding how security and privacy governance can be effectively implemented in real-world IoV ecosystems.

6.4. Design Implications for IoV Security and Privacy

While the preceding sections review security mechanisms and privacy-preserving approaches across architectural layers and data lifecycle stages, several cross-cutting design patterns can be identified. Synthesizing insights from the surveyed literature reveal that effective IoV security architectures should follow a set of integrated principles that balance real-time performance, privacy protection, and regulatory compliance.

6.4.1. Lifecycle-Oriented Security Architecture

Many existing solutions focus on isolated mechanisms such as authentication schemes, blockchain-based identity management, or intrusion detection systems. However, IoV security challenges often emerge from interactions across different stages of the data lifecycle. For example, privacy leakage may originate during data generation (e.g., vehicle sensor data), propagate through communication channels, and eventually accumulate in cloud platforms where large-scale analytics are performed.

Therefore, security mechanisms should be designed to cover the entire lifecycle of vehicular data, including generation, transmission, storage, processing, and deletion—rather than addressing individual stages independently. A lifecycle-oriented approach enables the identification of potential vulnerability propagation paths and facilitates the coordinated deployment of protection mechanisms.

6.4.2. Cross-Layer Coordination for System Robustness

IoV systems operate through tightly coupled layers, including perception devices, communication networks, platform infrastructures, and application services. Security mechanisms deployed at one layer often influence the effectiveness of protections at other layers. For instance, certificate management strategies in V2X communication directly affect trust establishment in higher-level service platforms, while edge computing security mechanisms influence the integrity of real-time traffic applications.

Consequently, security design should adopt a cross-layer coordination strategy. Instead of implementing isolated protection mechanisms, integrated security frameworks should enable information sharing between layers, allowing threat intelligence, authentication status, and trust evaluation results to be propagated across the system architecture.

6.4.3. Hybrid Privacy Protection Strategies

No single privacy-preserving technology can fully address the diverse privacy risks present in IoV environments. Cryptographic techniques such as homomorphic encryption and secure multiparty computation provide strong confidentiality guarantees but may introduce significant computational overhead. Conversely, approaches such as federated learning reduce raw data sharing but require robust trust management mechanisms.

A hybrid strategy combining multiple privacy-enhancing technologies is therefore more practical. For example, pseudonym-based identity protection can mitigate location tracking risks, while federated learning enables collaborative analytics without centralized data aggregation. When combined with differential privacy or secure aggregation, such hybrid solutions can significantly enhance privacy protection while maintaining acceptable system performance.

6.4.4. Real-Time Constraints and Lightweight Security Design

Unlike traditional IT systems, IoV environments operate under strict latency and reliability constraints. Safety-critical applications such as cooperative collision avoidance or autonomous driving assistance require millisecond-level response times. Security mechanisms that introduce excessive communication or computational overhead may therefore degrade system performance and compromise safety.

As a result, the design of IoV security mechanisms should prioritize lightweight cryptographic protocols, efficient authentication procedures, and edge-assisted processing. The deployment of security functions at edge nodes can reduce communication latency and support near-real-time threat detection.

6.4.5. Regulatory Integration as a Design Requirement

Recent regulatory developments, including cybersecurity regulations and automotive standards, increasingly require systematic security management throughout the vehicle lifecycle. These frameworks emphasize risk assessment, secure software update mechanisms, and continuous monitoring of cybersecurity events.

Consequently, security solutions proposed in the research literature should not only demonstrate technical feasibility but also consider their compatibility with regulatory requirements and industrial cybersecurity processes. Bridging the gap between academic security mechanisms and compliance-oriented engineering practices is essential for the practical deployment of IoV security technologies.

6.4.6. Toward a Holistic IoV Security Governance Framework

Combining the above observations suggests that future IoV security architectures should move toward holistic governance frameworks that integrate lifecycle protection, cross-layer coordination, privacy-enhancing technologies, and compliance-driven processes. Such frameworks can support secure data circulation across vehicles, roadside infrastructure, edge platforms, and cloud services while ensuring that privacy protection and regulatory requirements are consistently satisfied.

6.5. Implementation Tensions and Alignment Challenges Between UNECE R155 and ISO/SAE 21434

Although UNECE R155 and ISO/SAE 21434 share the common objective of improving automotive cybersecurity across the vehicle lifecycle, they differ in regulatory nature, implementation granularity, evidence requirements, and engineering focus. UNECE R155 is a type-approval-oriented regulation that requires manufacturers to establish and maintain a Cyber Security Management System (CSMS), whereas ISO/SAE 21434 is an engineering standard that specifies cybersecurity risk management activities for road-vehicle electrical and electronic (E/E) systems across the lifecycle. Therefore, ISO/SAE 21434 can provide an important engineering basis for fulfilling R155-related cybersecurity expectations, but it does not automatically resolve all regulatory approval, evidence management, and lifecycle governance challenges. The following subsections discuss the major implementation tensions that manufacturers may encounter when attempting to align these two frameworks in IoV development and operation.

6.5.1. Regulatory Compliance Versus Engineering Process Evidence

The first implementation tension lies in the difference between regulatory proof and engineering process evidence. UNECE R155 requires manufacturers to demonstrate to approval authorities or technical services that cybersecurity risks are properly managed at both the organizational and vehicle-type levels. ISO/SAE 21434, in contrast, produces engineering work products such as item definitions, cybersecurity goals, TARA results, cybersecurity concepts, verification evidence, and post-development monitoring records.

In practice, manufacturers must translate engineering artifacts into audit-ready compliance evidence. This requires a traceable evidence chain linking organizational CSMS processes, vehicle-type cybersecurity claims, system-level risk assessment, component-level engineering decisions, verification results, and post-production monitoring activities. If this traceability is incomplete, manufacturers may have technically implemented cybersecurity measures but still face difficulty demonstrating regulatory compliance. Therefore, a key implementation challenge is not only whether cybersecurity engineering activities are performed, but whether they can be consistently mapped to regulatory expectations and maintained as verifiable evidence.

6.5.2. Lifecycle Synchronization and Post-Production Cybersecurity Management

The second tension concerns lifecycle synchronization. UNECE R155 emphasizes cybersecurity management throughout development, production, and post-production phases, while ISO/SAE 21434 structures cybersecurity engineering activities across concept, product development, production, operation, maintenance, and decommissioning. These lifecycle views are broadly compatible, but their implementation boundaries are not identical.

For example, a vulnerability discovered after vehicle launch may trigger incident monitoring, risk reassessment, software remediation, customer communication, and possibly OTA deployment. This operational loop must be reflected both in the manufacturer’s CSMS evidence for UNECE R155 and in the cybersecurity engineering lifecycle records required by ISO/SAE 21434. If these evidence systems are maintained separately, inconsistencies may arise between risk assessment results, mitigation decisions, software update records, and compliance documentation. For IoV systems, this synchronization is particularly important because cybersecurity risks may emerge not only from in-vehicle E/E systems, but also from V2X communication, mobile applications, cloud platforms, remote diagnostics, and data-sharing services.

6.5.3. OTA Update Governance and Coordination with UNECE R156

The third tension is related to the interface between cybersecurity regulation and software update governance. In practice, UNECE R155 is often implemented together with UNECE R156, which focuses on software updates and Software Update Management Systems (SUMS). As connected vehicles increasingly rely on OTA updates, cybersecurity risk management, software update approval, update traceability, and post-update validation become tightly coupled.

However, ISO/SAE 21434 focuses on cybersecurity engineering, whereas UNECE R156 emphasizes controlled software update processes. Manufacturers therefore need to coordinate CSMS, SUMS, OTA security verification, software version traceability, and post-update risk reassessment within a unified lifecycle governance framework. Otherwise, an OTA update may be technically valid from a software management perspective but insufficiently connected to cybersecurity risk reassessment and vehicle-type compliance evidence. This challenge becomes more prominent in software-defined vehicles, where new functions, bug fixes, security patches, and cloud-connected services may be continuously introduced through aftermarket release.

6.5.4. Supply-Chain Cybersecurity Evidence and Responsibility Allocation

The fourth tension concerns supply-chain coordination. Modern IoV systems involve multiple suppliers providing ECUs, sensors, communication modules, cloud interfaces, mobile applications, software components, and cybersecurity functions. UNECE R155 places responsibility on the vehicle manufacturer to demonstrate cybersecurity management for the vehicle type, while ISO/SAE 21434 requires distributed cybersecurity activities and cybersecurity interface agreements among organizations involved in development.

In practice, OEMs must obtain sufficient cybersecurity evidence from suppliers, align TARA assumptions across system and component levels, manage vulnerability information, and ensure that supplier-provided updates or patches remain consistent with vehicle-type approval and post-production monitoring requirements. This becomes particularly difficult when suppliers use different cybersecurity processes, evidence formats, risk scales, tool chains, or vulnerability disclosure timelines. Therefore, cybersecurity interface agreements, shared evidence templates, supplier TARA alignment, and coordinated vulnerability disclosure mechanisms are essential for reducing inconsistencies across the IoV supply chain.

6.5.5. Continuous Risk Reassessment for Software-Defined Vehicles

The fifth tension is caused by the mismatch between regulatory stability and the continuous evolution of software-defined vehicles. Vehicle-type approval and regulatory documentation are relatively stable, whereas modern vehicles increasingly evolve through OTA updates, feature activation, data-driven services, cloud-connected functions, and third-party software interfaces. A cybersecurity risk assessment that was valid at the time of type approval may become incomplete after new software functions, service interfaces, communication channels, or data flows are introduced.

Manufacturers therefore need dynamic risk reassessment mechanisms and configuration-aware compliance evidence to ensure that cybersecurity controls remain valid after software updates and service changes. For IoV systems, this challenge is particularly significant because security and privacy risks are not confined to in-vehicle components, but extend across V2X communication, edge/cloud services, mobile applications, OTA platforms, and data lifecycle governance. Continuous risk reassessment should therefore relate to vulnerability monitoring, incident response, software configuration management, and lifecycle evidence management.

To further clarify these engineering challenges,

Table 9. Implementation tensions between UNECE R155/R156, and ISO/SAE 21434.

Implementation Issue	UNECE R155/R156 Emphasis	ISO/SAE 21434 Emphasis	Potential Engineering Obstacle	Suggested Alignment Strategy
Regulatory proof vs. engineering evidence	R155 requires CSMS evidence and vehicle-type approval support	ISO/SAE 21434 generates engineering work products and risk-management evidence	Engineering documents may not directly satisfy approval-authority evidence expectations	Build traceability from CSMS processes to TARA, cybersecurity goals, controls, verification, and monitoring records
Lifecycle synchronization	R155 covers development, production, and post-production cybersecurity management; R156 covers software update governance	ISO/SAE 21434 covers concept, development, production, operation, maintenance, and decommissioning	Risk records, software update records, and incident monitoring may be maintained in separate systems	Establish a unified lifecycle evidence repository and change-impact analysis process
OTA and software update control	R156 requires controlled and traceable software updates through SUMS	ISO/SAE 21434 requires cybersecurity engineering and risk treatment for E/E systems	OTA changes may introduce new cybersecurity risks after vehicle type approval	Link OTA approval, software version management, cybersecurity validation, and post-update risk reassessment
Supply-chain coordination	OEM must demonstrate cybersecurity management for the vehicle type	Distributed cybersecurity activities and interface agreements are required across organizations	Supplier evidence may be incomplete, inconsistent, delayed, or incompatible with OEM risk assumptions	Use cybersecurity interface agreements, common evidence templates, supplier TARA alignment, and vulnerability disclosure workflows
Continuous monitoring and incident response	R155 requires post-production monitoring and response capability	ISO/SAE 21434 includes operation and maintenance-related cybersecurity activities	Field vulnerabilities may not be rapidly connected to engineering risk records and mitigation decisions	Integrate SOC monitoring, vulnerability management, incident response, and engineering change management
Software-defined vehicle evolution	Regulatory approval tends to be vehicle-type and configuration based	ISO/SAE 21434 supports lifecycle engineering but requires continuous updates of work products	New services, APIs, or OTA-enabled functions may change the approved cybersecurity risk profile	Apply configuration-aware risk assessment and maintain updated compliance evidence for software/service changes

summarizes the major implementation tensions that may arise when manufacturers attempt to align UNECE R155/R156 with ISO/SAE 21434 in IoV development and operation.

As shown in Table 9, the main difficulty does not lie in conceptual incompatibility between these standards and regulations, but in the operational alignment of evidence, processes, lifecycle events, and responsibilities. Therefore, a practical compliance strategy should move from document-based mapping toward evidence-based lifecycle governance, in which cybersecurity risks, engineering controls, software updates, supplier interfaces, and post-production incidents are continuously linked.

7. Challenges and Future Research Directions

7.1. Limitations of the Current Strategies

Current IoV security and privacy protection strategies still exhibit several limitations in smart transportation applications. First, performance bottlenecks remain significant, as many security mechanisms are difficult to execute in real time under high vehicle mobility, leading to increased latency that fails to meet the stringent delay requirements of traffic systems. Second, the scope of applicability is limited: many existing solutions are designed for specific scenarios or attack models and lack sufficient generalization capability, resulting in poor adaptability to different vehicular communication architectures or emerging services. Third, validation and testing are insufficient. IoV security solutions are often evaluated only in simulation environments or small-scale experiments, with a lack of large-scale real-world traffic testing, which raises concerns about their practical effectiveness and robustness. Fourth, data and algorithmic bias persist. Many intrusion detection and privacy protection algorithms rely on historical training data, yet vehicular data sources are often imbalanced and sparse, making models susceptible to training bias and limiting their ability to generalize to unknown threats. In addition, current solutions lack global coordination: manufacturers and stakeholders tend to operate in silos, with non-unified standards, which hinders efficient cross-platform identity authentication, key management, and certificate revocation.

These limitations contribute to persistent security risks. For example, the V2X Security Credential Management System proposed by the U.S. Department of Transportation has revealed multiple practical constraints, including the heavy management burden caused by frequent certificate rotation and the transient and unstable nature of vehicle-to-infrastructure communication links [112]. As a result, adversaries can still exploit vulnerabilities to conduct identity spoofing and message tampering attacks, and existing security strategies struggle to provide comprehensive protection for future smart transportation systems.

7.2. Key Technology Challenges

In smart transportation scenarios, IoV security faces several core technical challenges.

Real-Time Security Protection Versus Performance Trade-Off: High mobility and ultra-low-latency V2X links conflict with computation-intensive mechanisms (e.g., strong encryption and fine-grained authentication/verification). Embedding effective protection into millisecond-level message exchanges without violating timing constraints remains a primary challenge.

Large-Scale Dynamic Trust Management: IoV involves massive, heterogeneous participants with frequent join/leave events and rapidly changing neighborhoods. Designing distributed trust management that remains robust to malicious nodes, noisy observations, and erroneous data under such dynamics is highly challenging.

Privacy Protection Versus Data Sharing: Cooperative driving and traffic services depend on sharing sensitive data (e.g., location, identity-linked metadata, and perception-related information), which inherently conflicts with privacy. Striking a practical balance between privacy preservation and data utility, especially under real-time requirements, remains a fundamental challenge.

Heterogeneous Networks and Standard Compatibility: Real deployments integrate DSRC, C-V2X, and 5G, together with multi-vendor platforms. Divergent security stacks across subnetworks hinder interoperability, and achieving consistent authentication/encryption and secure cross-domain cooperation among heterogeneous vehicles and infrastructure requires overcoming protocol compatibility and standard unification barriers.

Quantum Computing Threats: Long-lifecycle IoV devices are exposed to post-quantum risks as widely used public-key primitives may be undermined by future quantum computers. However, post-quantum schemes often incur larger keys/signatures and higher computational overhead, making lightweight integration and a staged migration path (without disrupting real-time V2X services) a forward-looking challenge.

Attack Detection and Fault Tolerance: IoV is a safety-critical cyber–physical system subject to both cyber-layer and physical-layer attacks. Intrusion detection must be accurate and timely under vehicle/edge resource constraints, while fault tolerance and safe degradation under attacks are essential to maintaining driving safety [113]; meanwhile, LLM-assisted alert/log triage and response orchestration across vehicle–edge–cloud pipelines still require careful validation under strict latency and reliability constraints.

7.3. Opportunities Presented by Emerging Technologies

In response to the challenges, the integration of emerging technologies offers new opportunities for enhancing security and privacy protection in IoV. Several technological trends are expected to play a key role in the future.

Blockchain Technologies: The decentralized and tamper-resistant properties of blockchain align well with the requirements of distributed trust management in IoV systems [114].

Blockchain can be leveraged to construct decentralized identity authentication and reputation mechanisms, in which vehicles verify the authenticity of messages through consensus algorithms, thereby eliminating reliance on a single trusted authority. For example, some studies have applied blockchain to vehicular identity authentication and privacy protection, significantly improving system security, data integrity, and trustworthiness. In addition, blockchain can be combined with smart contracts to enable automated security management functions, such as the automatic revocation of certificates for misbehaving vehicles, thereby enhancing the level of security automation.

Post-Quantum Cryptography (PQC): In response to the threat posed by quantum computing, next-generation quantum-resistant cryptographic algorithms are gradually being standardized. PQC schemes are designed to withstand quantum-enabled attacks, but they typically incur higher computational overhead and larger key and signature sizes. A practical transitional strategy is to adopt hybrid cryptographic schemes that combine conventional elliptic curve cryptography with PQC, enabling dual-signature verification during the migration period. With continued improvements in hardware performance and cryptographic algorithm optimization, PQC is expected to progressively replace existing public-key algorithms and provide long-term security guarantees for IoV systems [115].

Zero-Trust Architecture: The zero-trust security model emphasizes unconditional distrust and continuous verification, making it particularly suitable for open and dynamic networks such as the Internet of Vehicles. A zero-trust architecture requires authentication and authorization for every vehicle, device, and data interaction, without assuming any internal entity to be inherently trusted. Deploying zero trust in IoV systems can minimize trust boundaries through fine-grained access control and dynamic policy enforcement, thereby preventing lateral movement after an initial compromise. Emerging zero-trust solutions for in-vehicle networks—such as fine-grained verification mechanisms for in-vehicle buses—have begun to appear [12]. Looking forward, zero trust is expected to be integrated with software-defined vehicle technologies to enable globally orchestrated security policies, allowing on-demand isolation of compromised vehicles and restriction of suspicious communications while maintaining system flexibility.

Edge–Cloud Collaborative Computing: Architectures that integrate edge computing with cloud computing can fully exploit the computational resources of onboard units and roadside units to process security tasks locally, while leveraging the cloud’s strong centralized analytics capabilities. Under this edge–cloud collaborative paradigm, vehicles or edge nodes can perform low-latency tasks such as intrusion detection and emergency control in real time, whereas the cloud handles high-complexity tasks including global threat intelligence analysis and model training and updates. Edge nodes can also cache blockchain data or certificate status information to improve the timeliness and availability of trust management in IoV systems. Through edge–cloud collaboration, systems can enforce local isolation and protection when attacks occur, while simultaneously coordinating defenses across regions via the cloud, forming a network-wide collaborative security defense framework [116].

Overall, these emerging technologies provide new opportunities for enhancing IoV security. Future research should further explore their integrated application in vehicular environments and address practical challenges related to performance and cost, ultimately enabling smart transportation architectures that are secure by design and trustworthy by default.

7.4. Industry-Policy-Academia Synergy Outlook

Ensuring security and privacy in IoV for the era of smart transportation requires close collaboration among industry, policy and regulatory bodies, and academia. Each stakeholder should leverage its respective strengths to build a triple-helix collaborative innovation ecosystem.

Industry: Automotive manufacturers, communication providers, and networking companies should proactively adopt state-of-the-art security technologies and standards, integrating security and privacy protection throughout the entire vehicle lifecycle. For example, during the vehicle development phase, manufacturers should follow ISO/SAE 21434 to implement security architecture design; during mass production, they should deploy verified cryptographic modules and trusted execution environments; and for vehicles already in service, timely and secure OTA update mechanisms should be established. Industry players should also collaborate with cybersecurity vendors to build IoV threat intelligence sharing platforms, enabling real-time exchange of vulnerability and attack information to form alliance-based defenses. Furthermore, industry consortia should work toward unified interfaces and protocol standards to improve interoperability across vehicles and security systems from different manufacturers.

Policy and Regulatory Bodies: Governments and standardization organizations play a critical role in fostering a secure environment [117]. First, legal and regulatory frameworks should be strengthened to clearly define red lines for IoV data security and privacy protection, such as establishing data classification and graded protection schemes and specifying penalties for non-compliance. Second, regulators should take the lead in developing IoV security standards and certification systems to raise baseline security requirements. Governments should also invest in open testing and pilot platforms that emulate real-world traffic environments, enabling enterprises and research institutions to evaluate emerging security technologies. Through policy guidance and financial support, regulators can accelerate the translation of research outcomes into practical deployments.

Academia: Universities and research institutions should target frontier challenges in IoV security and conduct in-depth research to provide innovation momentum for industry. Academia can contribute systematic threat models and formal verification methods to identify weaknesses in existing systems; develop lightweight and efficient cryptographic algorithms, protocols, and detection techniques suitable for resource-constrained vehicular environments; and propose novel security architecture concepts to guide the development of next-generation IoV security systems. In addition, academic institutions should strengthen collaboration with industry by participating in standardization efforts and open-source security projects, embedding theoretical advances into real-world systems. Training interdisciplinary cybersecurity professionals is also essential to meet the growing demand for IoV security engineers.

Through close industry–policy–academia collaboration, a unified security force can be formed: industry provides application scenarios and data support to drive productization of research achievement; policy bodies offer direction and safeguards to regulate healthy industry development; and academics deliver innovative ideas and technical breakthroughs to tackle core challenges. Such coordinated efforts will accelerate the establishment of a robust and sustainable IoV security ecosystem.

8. Conclusions

This paper presented a PRISMA 2020-informed systematic review of security and privacy protection in the IoV. By integrating the four-layer IoV architecture with a five-stage data lifecycle, the review established a cross-layer and lifecycle-oriented analytical framework for examining threat surfaces, communication security requirements, identity authentication, trust management, privacy-preserving data sharing, active defense mechanisms, AI-assisted security analytics, and standards-oriented implementation issues. This integrated perspective helps move the discussion beyond isolated technical mechanisms and provides a more systematic understanding of how IoV data are generated, transmitted, stored, used, shared, and eventually disposed of across heterogeneous vehicle–edge–cloud environments.

The review indicates that IoV security and privacy risks are inherently cross-layer, lifecycle-dependent, and cyber–physical in nature. Threats such as spoofing, replay attacks, Sybil attacks, data tampering, denial of service, malware injection, and information disclosure affect different assets and security objectives, including authenticity, integrity, availability, confidentiality, freshness, privacy, and accountability. Therefore, no single protection mechanism can provide comprehensive security for IoV systems. PKI-based authentication can support message authenticity and integrity, but it cannot independently address insider misbehavior, denial-of-service risks, trajectory privacy leakage, or lifecycle data governance. Similarly, encryption protects data confidentiality, but it does not guarantee data freshness, behavioral trustworthiness, secure deletion, or compliant data usage. Effective IoV protection therefore requires coordinated defense-in-depth across architectural layers and lifecycle stages.

From the perspective of communication security, V2X interactions share common trust foundations but differ significantly in operational constraints and threat exposure. V2V communication requires low-latency authentication, replay protection, and misbehavior detection for high-frequency safety messages; V2I communication depends on infrastructure trust anchoring and secure edge coordination; V2P communication must balance timely safety warnings with privacy protection for vulnerable road users; and V2C communication extends the trust boundary to cloud platforms, remote services, APIs, and OTA update systems. These differences suggest that communication security mechanisms should be adapted to scenario-specific latency requirements, device capabilities, infrastructure dependence, and privacy exposure.

From the perspective of data and privacy protection, the applicability of privacy-preserving mechanisms depends strongly on deployment layer, lifecycle stage, data sensitivity, and performance constraints. Differential privacy and federated learning are relatively suitable for large-scale statistical analysis, model training, and privacy-preserving data usage, but they still face privacy–utility trade-offs, non-IID data, poisoning attacks, and communication overhead. Homomorphic encryption and secure multi-party computation provide stronger confidentiality guarantees during computation, but their computational and communication costs limit their use in hard real-time IoV scenarios. Blockchain-based mechanisms can enhance traceability, access control, tamper resistance, and accountability, but are better suited to audit and governance functions than to latency-critical message protection. These observations indicate that practical IoV systems will increasingly rely on hybrid and scenario-aware combinations of privacy-preserving techniques rather than a single universal solution.

The standards and regulatory analysis further show that IoV cybersecurity is not only a technical problem, but also an engineering governance problem. UNECE WP.29 R155/R156, ISO/SAE 21434, and related national standards provide important foundations for lifecycle cybersecurity management, OTA governance, software update control, and compliance evidence. However, manufacturers still face implementation tensions in translating engineering work products into regulatory proof, synchronizing cybersecurity evidence across development and post-production phases, coordinating CSMS and SUMS activities, managing supplier evidence, and continuously reassessing risks in software-defined vehicles. Therefore, future IoV security frameworks should place greater emphasis on evidence-based lifecycle governance, configuration-aware risk reassessment, supply-chain cybersecurity coordination, and auditable compliance management.

This review also has several methodological limitations. First, although multiple academic databases and supplementary sources were searched, relevant studies outside the selected databases may have been omitted. Second, the review mainly focused on English-language publications, which may introduce language bias. Third, the included studies and documents were heterogeneous in terms of research objectives, datasets, evaluation scenarios, technical mechanisms, and regulatory functions. Therefore, the synthesis was qualitative and comparative rather than statistical, and no meta-analysis or formal certainty-of-evidence assessment was conducted. These limitations should be considered when interpreting the findings of this review.

Future research should focus on several directions. First, lightweight and adaptive protection mechanisms are needed to satisfy strict latency and resource constraints in dense and highly mobile vehicular environments. Second, cross-layer trust coordination should be strengthened so that authentication, reputation evaluation, intrusion detection, and revocation mechanisms can operate coherently across vehicles, infrastructure, edge nodes, and cloud platforms. Third, privacy–utility co-optimization should be further investigated for trajectory data, cooperative perception, federated analytics, and AI model training. Fourth, AI- and LLM-assisted security operations should be developed with evidence grounding, human-in-the-loop validation, access control, and auditability to avoid hallucination, privacy leakage, and unsafe automated decisions. Finally, technical controls should be more closely aligned with lifecycle cybersecurity governance, OTA update management, supply-chain evidence, and regulatory compliance requirements.

Overall, IoV security and privacy protection should be understood as a lifecycle-oriented, cross-layer, and governance-aligned system problem. By synthesizing architectural layers, lifecycle stages, threat categories, defense mechanisms, privacy-preserving technologies, and standards-related implementation requirements, this review provides a structured reference for researchers and a practical analytical basis for designing secure, privacy-aware, and regulation-ready IoV systems.