{"id":26769,"date":"2026-08-18T09:59:35","date_gmt":"2026-08-18T08:59:35","guid":{"rendered":"https:\/\/neocoeurintelligence.com\/?p=26769"},"modified":"2026-07-23T22:58:13","modified_gmt":"2026-07-23T21:58:13","slug":"v2x-and-connected-mobility-securing-the-smart-city-ecosystem","status":"publish","type":"post","link":"https:\/\/neocoeurintelligence.com\/fr\/v2x-and-connected-mobility-securing-the-smart-city-ecosystem\/","title":{"rendered":"V2X et Mobilit\u00e9 Connect\u00e9e : S\u00e9curiser l'\u00c9cosyst\u00e8me de la Ville Intelligente"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\n
\n\n
\n
ART-14<\/strong> \u00b7 Neo Coeur Intelligence \u00b7 Published: July 2026 \u00b7 Mobility vertical \u00b7 Based on ETSI ITS \u00b7 IEEE 1609 \u00b7 ISO 21434<\/div>\n<\/div>\n\n
\n

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

Introduction<\/h2>\n
<\/div>\n\n

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.<\/p>\n\n

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<\/a>, because the only realistic way to police V2X at scale is with AI-based detection.<\/p>\n\n

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.<\/p>\n\n

\n

\u26a1 WHY THIS MATTERS NOW<\/h4>\n

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.<\/p>\n<\/div>\n\n

I. General Overview: What V2X Actually Is<\/h2>\n
<\/div>\n\n

1. The Four V2X Communication Modes<\/h3>\n\n

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.<\/p>\n\n

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

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?<\/p>\n\n

2. Why the Smart City Inherits the Vehicle's Weaknesses<\/h3>\n\n

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<\/a> 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.<\/p>\n\n

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<\/a>.<\/p>\n\n

II. The V2X Attack Surface<\/h2>\n
<\/div>\n\n

1. Replay, Spoofing and Sybil Attacks<\/h3>\n\n

Three attack classes dominate the V2X threat model. They are simple to describe, cheap to attempt, and dangerous at scale.<\/p>\n\n

\n
\u25cf<\/span>\u25cf<\/span>\u25cf<\/span><\/span>FIGURE 02 \u00b7 THREE CORE V2X ATTACK VECTORS<\/span>THREAT MODEL<\/span><\/div>\n
\n
REPLAY ATTACK<\/div>
Rebroadcasting valid messages<\/div>
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.<\/div><\/div>\n
SPOOFING<\/div>
Impersonating a trusted sender<\/div>
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.<\/div><\/div>\n
SYBIL ATTACK<\/div>
Faking many identities at once<\/div>
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.<\/div><\/div>\n
CAN INJECTION<\/div>
Reaching the internal bus<\/div>
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.<\/div><\/div>\n<\/div>\n
Source: ETSI TR 103 460 misbehaviour detection \u00b7 ENISA good practices for connected vehicles<\/div>\n<\/div>\n\n

2. The CAN Bus Problem<\/h3>\n\n

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.<\/p>\n\n

\n

\u2298 THE LATERAL PIVOT<\/h4>\n

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.<\/p>\n<\/div>\n\n

III. Securing V2X: PKI and AI Detection<\/h2>\n
<\/div>\n\n

Defending V2X takes two complementary layers. Cryptography proves who sent a message. AI proves whether the message makes sense. Neither is sufficient alone.<\/p>\n\n

1. PKI and Pseudonymous Certificates<\/h3>\n\n

The cryptographic layer is standardised. ETSI TS 103 097 mandates that V2X messages are signed using short-lived pseudonymous certificates<\/strong>, 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.<\/p>\n\n

\n

\ud83c\uddea\ud83c\uddfa<\/span>PKI SOVEREIGNTY: WHO CONTROLS THE ROOT OF TRUST?<\/h4>\n

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.<\/p>\n

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.<\/p>\n<\/div>\n\n

2. AI-Based Misbehaviour Detection<\/h3>\n\n

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.<\/p>\n\n

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

\n

\u2713 WHY AI IS THE ONLY SCALABLE ANSWER<\/h4>\n

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.<\/p>\n<\/div>\n\n

IV. The Regulatory Stack: NIS2, DORA and the AI Act<\/h2>\n
<\/div>\n\n

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.<\/p>\n\n

NIS2: smart-city operators are already in scope<\/h4>\n

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.<\/p>\n\n

DORA: the financial dimension of connected fleets<\/h4>\n

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.<\/p>\n\n

The EU AI Act: high-risk detection models<\/h4>\n
\n

\u2696 WHY YOUR V2X DETECTION MODEL MAY BE HIGH-RISK UNDER THE AI ACT<\/h4>\n

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:<\/p>\n