Building an automotive VSOC: architecture to detection

Monitoring is part of the regulation

Approval is not the finish line. UN R155 requires the cyber security management system to detect and respond to attacks and to monitor the vehicle across post-production — that is, across the whole time the fleet is on the road. A vehicle security operations centre (VSOC) is the function that discharges that obligation: it watches the deployed fleet and its backend, detects attacks and emerging vulnerabilities, and turns what it sees into vulnerability handling and software-update decisions.

This is a different claim from "we have an IT SOC." A conventional security operations centre watches servers, endpoints and enterprise networks. A VSOC has to watch cars — a moving, safety-relevant, bandwidth-constrained population whose telemetry looks nothing like a server log. The post-production monitoring duty under R155 is examined in the vehicle SOC and UN R155 post-approval monitoring; this article is about how you actually build one.

How a VSOC differs from an IT SOC

The two share tooling and staff disciplines but diverge on almost everything that matters for detection.

Dimension	IT SOC	VSOC
What it watches	Servers, endpoints, enterprise network	Fleet + telematics + backend
Primary data	Logs, security events, network flows	Vehicle / telematics telemetry, in-vehicle-network signals
Constraints	Bandwidth ample, data centralised	Limited uplink, intermittent connectivity, privacy-sensitive
Safety relevance	Rare	Direct — a response can affect a vehicle in use
Response actions	Isolate host, revoke access	Vulnerability handling, targeted software update (RxSWIN)

The consequences are practical. Vehicles cannot stream everything, so the fleet has to send the right compact signals rather than raw firehoses. Telemetry that identifies driving behaviour is privacy-sensitive and has to be handled accordingly. And a response is not "quarantine the endpoint" — it may be a coordinated software update across a slice of the fleet, which brings its own change-control and RxSWIN implications.

The architecture, layer by layer

A workable VSOC is a pipeline from the vehicle to a decision.

• Data sources. In-vehicle detection (intrusion detection on the CAN and Ethernet backbones, ECU integrity signals) produces events; the telematics unit relays them; the backend and update platform contribute their own logs. The convergence point matters — plant, backend and vehicle are one surface, as set out in IT/OT convergence in automotive manufacturing security — so the VSOC should not be blind to the backend and production estates that feed the fleet.
• Ingestion and normalisation. Fleet telemetry arrives intermittently and in vehicle-specific formats. It has to be normalised into events a detection engine can reason over, with vehicle and software-version context (including RxSWIN) attached.
• Detection. Rules and analytics tuned to vehicle behaviour — anomalous message patterns, unexpected diagnostic sessions, integrity failures — rather than IT indicators of compromise. Baselines are per-model and per-software-version, because normal behaviour changes with each update.
• Triage and response. Analysts assess whether an event is an attack, a fault or noise, and route confirmed issues into vulnerability handling. Where a fix is needed, the loop closes through a software update, which ties the VSOC to the SUMS and to change control.
• Feedback to engineering. What the fleet reveals feeds back into the TARA and the next design cycle. A VSOC that only reacts is half a VSOC; the value compounds when field detection improves the product.

Detection is the hard part

Standing up dashboards is easy; detecting a real attack in fleet telemetry is not. Three problems dominate.

First, signal versus noise. A fleet generates enormous volumes of benign variation — different drivers, climates, road conditions, firmware versions. A detection that fires on every deviation is useless; one tuned too tightly misses the attack. Baselines have to be version-aware, because each software update shifts what normal looks like.

Second, ground truth is scarce. Unlike IT, where attack patterns are widely catalogued, vehicle attack telemetry is comparatively rare. Detection benefits directly from offensive work — the CAN-level attack techniques in CAN bus attacks explained are the same behaviours a VSOC must learn to recognise, so red-team benches and pentests feed the detection library.

Third, response has consequences. A VSOC's output can lead to a software update pushed to vehicles in use. That makes disciplined change control, safe-state handling and coordinated disclosure non-negotiable — the disclosure and reporting side is developed in vulnerability handling and disclosure under the CRA.

Where the CRA reinforces this

For manufacturers reaching the EU market, the Cyber Resilience Act adds an active-reporting dimension on top of R155's monitoring duty. Under Regulation (EU) 2024/2847, vulnerability and incident reporting obligations apply from 11 September 2026, with the main body of obligations from 11 December 2027. A VSOC is the operational capability that makes those reporting timelines achievable — you cannot report what you cannot detect, and you cannot meet a clock you have no process for.

The AutoSifu view

A VSOC is where R155's post-production duty and the CRA's reporting clock become one operational problem, and where detection quality — not tooling — decides whether either is actually met. AutoSifu works one route — compliance, solutioning, and CoC/VTA support — with CIRT in the room, so the VSOC is designed to produce the monitoring and vulnerability-handling evidence an assessor expects, not just a dashboard. Building the detection library from real offensive work is what turns the centre from a compliance artefact into a defence.