Skip to content Skip to footer

V2X and Connected Mobility: Securing the Smart City Ecosystem

ART-14 · Neo Coeur Intelligence · Published: July 2026 · Mobility vertical · Based on ETSI ITS · IEEE 1609 · ISO 21434

📋 TABLE OF CONTENTS

00.Introduction
I.General Overview: What V2X Actually Is
1.1The four V2X communication modes
1.2Why the smart city inherits the vehicle's weaknesses
II.The V2X Attack Surface
2.1Replay, spoofing and Sybil attacks
2.2The CAN bus problem
III.Securing V2X: PKI and AI Detection
3.1PKI and pseudonymous certificates
3.2AI-based misbehaviour detection
IV.The Regulatory Stack: NIS2, DORA and the AI Act
V.A 3-Step Method for Fleets and Cities
VI.Conclusion
VII.FAQ
VIII.References

Introduction

The CAN bus, designed in 1980 without any security in mind, has quietly become one of the main intrusion vectors into the modern vehicle. That is the uncomfortable starting point of connected mobility: we bolted decades of wireless connectivity, cloud services and traffic-infrastructure links onto internal networks that were never built to be exposed. V2X (Vehicle-to-Everything) is the technology that makes cars talk to each other, to traffic lights, to networks and to pedestrians. It is also the technology that turns a single compromised vehicle into a threat to an entire smart city.

For fleet operators, automotive OEMs and smart-city authorities, this is no longer theoretical. As soon as vehicles broadcast their position and intentions to the infrastructure around them, a falsified message can trigger phantom braking across a junction, reroute a fleet, or mask a real hazard. Securing that ecosystem is a cybersecurity discipline in its own right, and it sits at the intersection of automotive security and critical-infrastructure protection. It also connects directly to the broader practice of AI risk assessment, because the only realistic way to police V2X at scale is with AI-based detection.

This guide breaks down the four V2X communication modes, the attack vectors that matter most (replay, spoofing and Sybil), the European regulatory stack now in force (NIS2, DORA and the AI Act), and how sovereign, resilient AI combined with a proper public-key infrastructure keeps the connected mobility ecosystem trustworthy.

⚡ WHY THIS MATTERS NOW

V2X is moving from pilot to deployment across European corridors, and the C-ITS framework schedules mandatory rollout between 2026 and 2028. ETSI has already standardised the security layer for it (ETSI TS 103 097). But standards only work if the infrastructure behind them, the certificate authorities, the revocation systems and the anomaly detection, is actually operational before the first message is trusted. A smart city that deploys V2X without a working misbehaviour-detection layer is not smart. It is exposed. And since NIS2 came into force in October 2024, smart-city operators are already in regulatory scope.

I. General Overview: What V2X Actually Is

1. The Four V2X Communication Modes

V2X is an umbrella term for four distinct communication modes. Each connects the vehicle to a different part of its environment, and each opens a different attack surface. Understanding them individually is the prerequisite to securing them.

FIGURE 01 · THE FOUR V2X COMMUNICATION MODESV2X
V2V
Vehicle to Vehicle
Cars share speed, position and braking intent to prevent collisions.
V2I
Vehicle to Infrastructure
Traffic lights, signs and road sensors exchange data with vehicles.
V2N
Vehicle to Network
Cellular and cloud links for updates, fleet management and telematics.
V2P
Vehicle to Pedestrian
Smartphones and vulnerable-road-user devices signal their presence.
Source: ETSI ITS · IEEE 1609 family · four modes of vehicle-to-everything communication

The key insight is that V2X is trust-based by design. A vehicle acts on messages it receives from other vehicles and from the infrastructure. If an attacker can inject a message that looks legitimate, the receiving vehicle will act on it. Security therefore has to answer one question at machine speed, thousands of times per second: is this message from who it claims to be, and is it telling the truth?

2. Why the Smart City Inherits the Vehicle's Weaknesses

A connected vehicle is not an isolated target. Through V2I and V2N, it is wired into urban infrastructure: traffic management, parking systems, emergency-response coordination, energy grids for EV charging. This is the same convergence of IT and operational technology that makes smart buildings and critical infrastructure attractive targets. A weakness in one connected vehicle can propagate laterally into the city systems it talks to, and a weakness in the city infrastructure can be pushed back down into every vehicle that trusts it.

That is why V2X security cannot be treated as an automotive problem alone. It is a critical-infrastructure problem, and it falls under the same European regulatory pressure examined in Part IV. For the vehicle-side view of these same gaps, see our guide to automotive cybersecurity under UN-R155 and ISO/SAE 21434.

II. The V2X Attack Surface

1. Replay, Spoofing and Sybil Attacks

Three attack classes dominate the V2X threat model. They are simple to describe, cheap to attempt, and dangerous at scale.

FIGURE 02 · THREE CORE V2X ATTACK VECTORSTHREAT MODEL
REPLAY ATTACK
Rebroadcasting valid messages
The attacker captures a legitimate V2X message and rebroadcasts it later, in a different context. A captured "emergency braking" message replayed in under a second can trigger reactions across a junction. Timing and freshness checks are the first line of defence.
SPOOFING
Impersonating a trusted sender
The attacker forges messages that appear to come from a legitimate vehicle or roadside unit: a fake obstacle, a false traffic-light state, a phantom emergency vehicle. Without cryptographic authentication, the receiver cannot tell the difference.
SYBIL ATTACK
Faking many identities at once
A single attacker creates dozens of fake vehicle identities to simulate a traffic jam that does not exist, manipulate routing, or overwhelm a junction's logic. Pseudonym management and misbehaviour detection are what break it.
CAN INJECTION
Reaching the internal bus
Once inside the vehicle, an attacker can inject frames directly onto the CAN bus, which has no built-in authentication, to command actuators. This is the pivot from the connectivity layer to the physical vehicle.
Source: ETSI TR 103 460 misbehaviour detection · ENISA good practices for connected vehicles

2. The CAN Bus Problem

The Controller Area Network (CAN) was standardised in the 1980s to let a car's electronic control units talk to each other reliably. Reliability, not security, was the goal, so CAN has no authentication and no encryption. Every ECU on the bus implicitly trusts every message. That was acceptable when the bus was sealed inside the vehicle. It is not acceptable now that V2X, OTA updates and diagnostic ports give an attacker paths to reach it.

⊘ THE LATERAL PIVOT

The most dangerous V2X attack is not the falsified message itself. It is using a low-security entry point, a spoofed V2X message, a compromised telematics unit, or a diagnostic dongle, to reach the internal CAN bus and command safety-critical actuators such as braking or steering. This is why segmentation between the connectivity domain and the safety domain, a core UN-R155 requirement, is non-negotiable.

III. Securing V2X: PKI and AI Detection

Defending V2X takes two complementary layers. Cryptography proves who sent a message. AI proves whether the message makes sense. Neither is sufficient alone.

1. PKI and Pseudonymous Certificates

The cryptographic layer is standardised. ETSI TS 103 097 mandates that V2X messages are signed using short-lived pseudonymous certificates, which authenticate the sender without exposing a permanent identity that could be used to track drivers. A public-key infrastructure issues, rotates and revokes these certificates, and a central point of contact (CPOC) coordinates revocation across operators. When a vehicle is caught misbehaving, its certificates can be revoked so other vehicles stop trusting it.

🇪🇺PKI SOVEREIGNTY: WHO CONTROLS THE ROOT OF TRUST?

The certificate authority that underpins a V2X network decides which vehicles are trusted on the road. In the European C-ITS model, that trust chain is anchored by a central point of contact and a set of root and enrolment authorities. Keeping those authorities under European control is a strategic requirement, not a technical detail, because whoever operates the root of trust can, in principle, decide who drives.

The risk of an extraterritorial certificate authority is concrete. A CA subject to a foreign legal regime could be compelled to issue, revoke or disclose credentials under laws the European operator has no say in, from extraterritorial data-access statutes to sanctions enforcement. A revocation decision taken outside European jurisdiction could ground a national fleet. For smart cities and fleet operators, sovereign, auditable and explainable PKI governance is the difference between owning your mobility trust layer and renting it from someone who can switch it off.

2. AI-Based Misbehaviour Detection

Cryptography confirms a message is authentic. It does not confirm the message is true. A vehicle with a valid certificate can still broadcast false data, because its sensors were spoofed or because it was compromised. This is where AI-based misbehaviour detection becomes essential. By modelling what normal traffic behaviour looks like, a detection model can flag the weak signals of an attack: a vehicle reporting an impossible position, a cluster of identities that appeared at once (the signature of a Sybil attack), a braking message with no plausible cause.

This is behavioural detection applied to mobility, and it is the same intelligent-supervision approach Neo Coeur Intelligence applies in its Intelligent Supervision Center: turn continuous streams of data into actionable, explainable decisions, at machine speed, across an entire fleet or city.

✓ WHY AI IS THE ONLY SCALABLE ANSWER

A busy junction can see thousands of V2X messages per second across hundreds of vehicles. No human operator and no static rule set can validate the plausibility of that volume in real time. A resilient, explainable detection model can, flagging the anomalies that matter and producing the evidence trail a NIS2 incident report will require.

IV. The Regulatory Stack: NIS2, DORA and the AI Act

V2X security is not just good engineering. In Europe it is now a legal obligation, governed by three overlapping frameworks. Understanding which one applies to your organization is the first step to a defensible compliance posture.

NIS2: smart-city operators are already in scope

The NIS2 Directive, in force since October 2024, classifies operators of essential services, including transport and smart-city infrastructure, as regulated entities. That means documented risk management, incident reporting within tight deadlines, and demonstrable security controls over connected-mobility systems. A city deploying V2X is not choosing whether to comply. It is already in scope.

DORA: the financial dimension of connected fleets

Less obvious, but commercially important: fleet operators and automotive insurers can fall under DORA (the Digital Operational Resilience Act). DORA applies to financial entities and to the critical ICT third-party providers that serve them. A connected-fleet operator classified as a financial entity, or a mobility-data platform deemed a critical ICT provider to insurers and banks, inherits DORA obligations on ICT risk management, resilience testing and third-party oversight. For our Financial Services clients, this is where connected mobility and financial-sector regulation converge, and where a single resilience programme can satisfy both.

The EU AI Act: high-risk detection models

⚖ WHY YOUR V2X DETECTION MODEL MAY BE HIGH-RISK UNDER THE AI ACT

The AI misbehaviour-detection models that police V2X traffic are not neutral tooling in the eyes of the EU AI Act. Because they operate on critical infrastructure and mobility, and because their decisions can affect safety and access to a service, they can fall into the high-risk category. That classification carries concrete obligations:

  • Robustness and cybersecurity (Article 15): the detection model itself must be accurate, robust and resilient to adversarial manipulation. An attacker who can fool your detector is an attacker who can operate freely.
  • Transparency and explainability: high-risk AI must be documented and its decisions must be interpretable, so a flagged vehicle, or a missed attack, can be reconstructed and justified. Black-box detection will not satisfy an auditor.
  • Human oversight and record-keeping: logging and oversight measures must be in place, which dovetails neatly with the NIS2 evidence trail.

In short: the AI you deploy to secure V2X is itself a regulated high-risk system. Sovereign, explainable detection is not only better security. It is the compliant path.

V. A 3-Step Method for Fleets and Cities

1
STEP

Map the V2X trust boundaries

Inventory every V2V, V2I, V2N and V2P interface, the certificate authorities behind them, and the exact points where the connectivity domain touches the internal vehicle bus.

You cannot secure what you have not mapped. This step produces the architecture and trust-boundary diagram that every later control is measured against.

2
STEP

Harden the cryptographic and segmentation layer

Enforce pseudonymous PKI per ETSI TS 103 097, verify certificate revocation is operational and European-controlled, and segment the connectivity domain from safety-critical CAN buses.

This is the layer that stops spoofing and blocks the lateral pivot to the internal bus. It is also the layer a UN-R155 audit will examine first.

3
STEP

Deploy AI misbehaviour detection

Run an explainable detection model over live V2X traffic to catch authenticated-but-false messages, Sybil clusters and replay patterns, with alerts routed to a supervision centre and logs that satisfy NIS2 and AI Act record-keeping.

This is the layer that catches what cryptography cannot: a valid certificate telling a lie. The deliverable is continuous, explainable monitoring with an evidence trail ready for regulators.

FIGURE 03 · KEY FIGURES · V2X AND CONNECTED MOBILITYTHREAT DATA
4
V2X communication modes (V2V, V2I, V2N, V2P)
1980
the year the CAN bus was designed, with no security
<1 sec
time to execute a V2X replay attack
1,000s/sec
V2X messages processed at a single busy junction
2026-28
C-ITS mandatory V2X rollout window in Europe
Oct 2024
NIS2 in force: smart-city operators already in scope
Sources: ETSI ITS standards · C-ITS Delegated Regulation · ENISA good practices for smart cars · Bosch CAN specification · NIS2 Directive

VI. Conclusion

Connected mobility only delivers its safety and efficiency promise if the messages flowing through it can be trusted. That trust does not come for free. It is built from two layers working together: a sovereign, European-controlled public-key infrastructure that proves identity, and resilient, explainable AI that proves plausibility. Remove either one and the ecosystem becomes a distributed attack surface stretching from a single ECU to an entire city.

The regulatory picture only sharpens the point. NIS2 already puts smart-city operators in scope, DORA reaches the connected-fleet operators and insurers on the financial side, and the AI Act treats the very detection models that secure V2X as high-risk systems in their own right. The organizations that will win in connected mobility, the fleet operators, the OEMs and the smart-city authorities, are the ones that treat V2X security as critical-infrastructure protection rather than an automotive feature.

The CAN bus was designed in 1980 for a world that no longer exists. Securing the connected city is about accepting that reality and building the intelligent, sovereign supervision layer that the original designers never could.

Is your connected mobility ecosystem defensible?

Neo Coeur Intelligence audits V2X architectures end to end: trust-boundary mapping, PKI and segmentation review, and AI misbehaviour-detection design aligned with ETSI ITS, UN-R155, NIS2, DORA and the EU AI Act.

Secure the ecosystem before it scales.

📧 contact@neocoeurintelligence.com

→ Book a meeting Request a V2X Audit

VII. Frequently Asked Questions

What are the four V2X communication modes?

V2X covers four modes: V2V (vehicle to vehicle), V2I (vehicle to infrastructure such as traffic lights), V2N (vehicle to network, meaning cellular and cloud), and V2P (vehicle to pedestrian devices). Each connects the vehicle to a different part of its environment and each opens a distinct attack surface.

What is a Sybil attack in V2X?

A Sybil attack is when a single attacker fabricates many fake vehicle identities at once, for example to simulate a traffic jam that does not exist, manipulate routing, or overwhelm a junction's decision logic. It is countered with pseudonym management and AI-based misbehaviour detection that spots clusters of identities appearing together.

Does NIS2 or DORA apply to connected mobility?

Both can. NIS2, in force since October 2024, puts transport and smart-city infrastructure operators in scope for risk management and incident reporting. DORA applies to financial entities and their critical ICT providers, so a connected-fleet operator classified as a financial entity, or a mobility-data platform serving insurers and banks, can inherit DORA resilience obligations too.

Why is the CAN bus a security risk?

The CAN bus was designed in the 1980s for reliability, not security, so it has no authentication or encryption and every ECU trusts every message. That was safe when the bus was sealed inside the vehicle, but V2X, OTA updates and diagnostic ports now give attackers paths to reach it and inject commands to safety-critical actuators.

Why is AI needed if V2X messages are already signed?

Cryptography proves a message is authentic, but not that it is true. A vehicle with a valid certificate can still broadcast false data if its sensors are spoofed or it has been compromised. AI-based misbehaviour detection models normal traffic behaviour and flags authenticated-but-implausible messages at a scale and speed no human operator could match. Under the AI Act, that detection model is itself a high-risk system that must be robust and explainable.

VIII. References

[1] ETSI. TS 103 097 · Intelligent Transport Systems (ITS); Security; Security header and certificate formats. European Telecommunications Standards Institute.

[2] ETSI. TR 103 460 · Intelligent Transport Systems (ITS); Security; Pre-standardization study on misbehaviour detection.

[3] IEEE. IEEE 1609 · Family of Standards for Wireless Access in Vehicular Environments (WAVE).

[4] European Commission. C-ITS Delegated Regulation · Cooperative Intelligent Transport Systems deployment framework.

[5] ENISA. Good Practices for Security of Smart Cars. European Union Agency for Cybersecurity, 2021.

[6] UNECE WP.29. UN Regulation No. 155 · Cyber security and cyber security management system. Adopted March 2021.

[7] Robert Bosch GmbH. CAN Specification, Version 2.0. 1991.

[8] Directive (EU) 2022/2555 (NIS2) on measures for a high common level of cybersecurity across the Union. OJEU L 333, 27 December 2022.

[9] Regulation (EU) 2022/2554 (DORA) on digital operational resilience for the financial sector. OJEU L 333, 27 December 2022.

[10] Regulation (EU) 2024/1689 (Artificial Intelligence Act). OJ L, 12 July 2024.

Leave a comment