A vehicle manufacturer is now expected to watch its cars for cyber attacks for as long as they are on the road, and an ordinary enterprise SOC is not built to do that. UN Regulation No. 155 requires continual monitoring of vehicle types after first registration, the ability to detect and analyse attacks from vehicle data and logs, and a report to the approval authority at least once a year. A Vehicle Security Operations Centre (VSOC) is the function that turns those obligations into telemetry, detections, triage and fleet-level response. This guide covers what a VSOC monitors, the data pipeline from in-vehicle intrusion detection to back end, detection use cases, operating models, privacy constraints, the machine identities that make the whole chain trustworthy, and how to measure it. It is written for OEM and supplier security leaders, SOC architects and product security teams. For the wider landscape see the Automotive Cybersecurity Guide.
Key takeaways
- The regulation makes monitoring mandatory. UN R155 paragraph 7.2.2.2 (g) and (h) require processes to monitor for, detect and respond to attacks and to provide data for analysis, and 7.2.2.4 says monitoring is continual and includes vehicles after first registration.
- Scope is the whole ecosystem, not just the car. A VSOC watches vehicles, telematics back ends, mobile apps, OTA and charging infrastructure, dealer and diagnostic tools, and the supply chain feeds that describe vulnerabilities.
- Detection starts on the ECU. In-vehicle sensors and an intrusion detection manager (for example the AUTOSAR IdsM) qualify security events and forward them; the back end correlates them across the fleet, because a single vehicle rarely knows it is under attack.
- Privacy is a design constraint. R155 requires analysis from vehicle data and logs to respect owners' and drivers' privacy rights, in particular consent. Minimise, pseudonymise and govern telemetry from day one.
- Machine identities carry the trust. Vehicle certificates, back-end service accounts, API keys and signing keys are both the main attack surface and the main source of detection signal; inventory and monitor them.
What a VSOC is responsible for
An enterprise SOC protects the company's IT estate. A VSOC protects products in customers' hands, which changes the assets, the data, the response options and the regulator.
| Dimension | Enterprise SOC | Vehicle SOC |
|---|---|---|
| Assets | Endpoints, servers, cloud, identities owned by the company | Millions of vehicles owned by customers, plus connected back ends, apps and charging |
| Telemetry | EDR, network, identity and cloud logs, high fidelity | Qualified security events from ECUs over cellular links, bandwidth and cost constrained, often delayed |
| Response | Isolate a host, disable an account, block an IP | OTA fix, back-end feature disablement, certificate revocation, recall, move vehicle to a minimal risk condition |
| Time horizon | Asset lifetimes of a few years | Vehicles in service for 15 years or more, with long-lived components |
| Regulatory driver | Sector rules, NIS2, data protection | Type approval: UN R155 monitoring and annual reporting; data protection on vehicle data |
| Safety | Rarely life safety | Attacks can affect braking, steering and occupants; safety engineering joins triage |
The R155 obligations that a VSOC typically owns, from the official text published in the EU Official Journal (OJ L 2025/5):
- 7.2.2.2 (g): processes to monitor for, detect and respond to cyber attacks, threats and vulnerabilities on vehicle types, and to assess whether implemented measures remain effective against newly identified threats.
- 7.2.2.2 (h): processes to provide relevant data to support analysis of attempted or successful attacks.
- 7.2.2.3: threats and vulnerabilities that need a response are mitigated within a reasonable timeframe.
- 7.2.2.4: monitoring is continual, includes vehicles after first registration, and can analyse attacks from vehicle data and logs while respecting privacy rights, especially consent.
- 7.3.7: the vehicle type itself must detect and prevent attacks, support the manufacturer's monitoring and provide data forensic capability.
- 7.4.1: a report to the approval authority or technical service at least once a year, or more often if relevant, on monitoring outcomes, new attacks and confirmation that mitigations remain effective.
The R155 compliance programme itself is covered in the UNECE R155 Cyber Security Management System Guide.
Data sources and the telemetry pipeline
| Source | Examples of signal | Notes |
|---|---|---|
| In-vehicle IDS sensors | SecOC MAC verification failures, unexpected CAN IDs or frequencies, diagnostic session attempts (UDS SecurityAccess failures), secure boot failures, firewall drops on the gateway | Qualified on board, aggregated, then forwarded |
| Infotainment and telematics units | Process anomalies, unexpected listening ports, failed app signature checks, rooting indicators | Linux or Android based; host-style detection applies |
| Telematics and connected services back end | API authentication failures, unusual remote command volume (unlock, start), token misuse, geographic anomalies | Often the highest-value and fastest signal |
| Mobile apps and digital keys | Account takeover patterns, key sharing abuse, emulator use | Shared with customer identity and fraud teams |
| OTA platform | Signing events, campaign changes, failed update verification on vehicles, rollback spikes | Links to UN R156 records |
| Charging and V2G | Charge point certificate errors, anomalous sessions (ISO 15118 Plug and Charge) | Includes third-party charge point operators |
| Dealer, workshop and diagnostic tools | Reprogramming outside authorised workshops, tool credential reuse | NHTSA advises authenticated, access-controlled diagnostic and reprogramming access |
| Threat intelligence | Auto-ISAC sharing, supplier PSIRT advisories, researcher reports, dark web chatter on key cloning or tuning tools | Feeds vulnerability analysis and detection content |
From ECU to back end
The AUTOSAR Classic Platform Intrusion Detection System Manager (IdsM, document 977, release R22-11) gives a reference model. Sensors in basic software, complex device drivers and software components report security events (SEv). The IdsM applies a fixed filter chain (block state, forward every Nth, aggregation, then threshold) plus rate limits, producing qualified security events (QSEv) that carry IDs, a count and optional timestamp, context data and signature. QSEvs can be stored in a Security Event Memory or sent to the IDS Reporter, an OEM-specific application that forwards them to the back end. The specification itself notes that the IdsM cannot judge whether a system is compromised; that analysis happens in the SOC.
- Collect: sensors and the IdsM qualify events on board to keep bandwidth and cost manageable.
- Protect: sign QSEvs (the IdsM supports a CSM-generated signature) and send them over an authenticated channel using the vehicle's certificate, so events cannot be forged or replayed.
- Ingest and normalise: a back-end pipeline maps events to a common schema with VIN pseudonym, ECU, software version (RXSWIN where relevant) and location precision appropriate to the use case.
- Enrich: join with the component and update database NHTSA recommends (hardware and software per ECU and per vehicle, plus update history) so analysts can see which vehicles share a vulnerable configuration.
- Detect and correlate: rules and models run per vehicle and across the fleet; fleet-level patterns (the same event on many vehicles of one software version) are often the first sign of a new exploit.
- Respond and report: cases flow into product incident response and feed the R155 annual report.
Detection use cases
| Use case | Signals | R155 Annex 5 link | Typical response |
|---|---|---|---|
| Unauthorised access to vehicle functions via back end | Spikes in remote unlock or start commands per account, token use from new geographies, API enumeration | M9 (detect unauthorised access) | Revoke tokens, rate-limit API, force account re-verification |
| Malicious in-vehicle messages | SecOC failures, unexpected diagnostic requests on the CAN bus, gateway filter hits | M15 (detect malicious internal messages) | Fleet query for same pattern, engineering analysis, OTA filter update |
| Denial of service | Bus load anomalies, telematics unit restarts, back-end request floods | M13 (detect and recover from denial of service) | Back-end mitigation, ECU hardening fix |
| Log tampering | Gaps in event counters, cleared Security Event Memory | Threat 21.1, M7 | Forensic retrieval at workshop, investigation |
| Sensor data manipulation | Disagreement between GNSS, wheel speed and camera, sudden position jumps | Threats 20.3 to 20.5 (correlate data from different sources) | Safety team triage, model update |
| Abuse of security function management | Key or certificate operations outside process, diagnostic tool credential reuse | M19 (security procedures with logging of access to security functions) | Revoke tool credentials, audit dealer access |
| Update chain compromise | Signing outside release windows, verification failures across many vehicles | Links to UN R156 7.1.3 | Halt campaign, rotate keys, incident escalation |
Write detection content as code with test data, version it, and review it against each new vehicle platform, because sensors and event IDs differ by ECU supplier. See the Building a SOC from Scratch Guide for detection engineering practice.
Where identity fits
Most of what a VSOC detects is the misuse of a credential, and most of what it uses to respond is a credential operation.
- Vehicle and ECU certificates: authenticate telemetry and back-end sessions. Monitor for one certificate used from two vehicles at once (cloning), and keep revocation fast. See the Connected and Autonomous Vehicle Security Guide.
- Back-end service accounts and API keys: telematics, data platform and partner integrations hold keys that can reach customer and vehicle data. The Toyota T-Connect Key Exposure 2022 left a back-end access key on public GitHub for nearly five years, and the Tesla Kubernetes Cryptojacking 2018 case exposed AWS credentials in a pod with access to a bucket that reportedly held telemetry. A VSOC should watch secret-scanning alerts and cloud identity logs for its own back ends.
- Diagnostic and dealer tool identities: NHTSA advises authentication and access control for diagnostic and reprogramming functions and reducing reliance on global symmetric keys; treat each tool and technician as an identity with logged sessions.
- Customer identities and digital keys: account takeover in the mobile app is a direct path to vehicle functions. Share signals with the customer identity team.
- VSOC tooling identities: the pipeline that can query or command the fleet (for example to retrieve logs or push a configuration) is itself highly privileged. Restrict, vault and monitor it. See the Identity for IoT Fleets Guide.
Operating models and decisions
| Model | When it fits | Trade-off |
|---|---|---|
| In-house VSOC integrated with enterprise SOC | Large OEMs with many connected platforms | Highest control and context; needs automotive-specific skills and tooling alongside IT detection |
| Separate product VSOC, shared tooling | OEMs whose product security sits apart from corporate IT | Clear R155 ownership; risk of missing correlations with back-end IT incidents |
| Managed VSOC service | Smaller OEMs, low-volume or specialist vehicle makers, new entrants | Faster start; the manufacturer still owns R155 obligations, so contracts must give data access, response SLAs and report inputs |
| Tier 1 supplier monitoring | Supplier-provided telematics or infotainment platforms | Deep component knowledge; OEM needs consolidated fleet view and evidence for the authority |
- Telemetry depth versus privacy and cost: more raw data helps forensics but raises consent, storage and cellular cost. Keep raw logs on the vehicle and pull them on demand for a case where the legal basis allows.
- Response authority: decide in advance who can disable a back-end feature, revoke certificates or start an OTA fix, and when safety engineering must sign off. NHTSA's best practices describe moving a vehicle to a minimal risk condition when an attack is detected.
- Small versus large fleets: a small maker can start with back-end and app monitoring plus periodic workshop log retrieval, then add in-vehicle IDS on new platforms. Large OEMs need fleet-scale correlation and dedicated detection engineering per platform.
Building the VSOC: phased roadmap
- Define scope and obligations. List vehicle types under R155, markets, connected services and suppliers. Map 7.2.2.2 (g), (h), 7.2.2.4, 7.3.7 and 7.4.1 to owners.
- Start with the back end. Bring telematics API, identity, OTA and cloud logs into the SIEM first; this gives detection value quickly and does not depend on vehicle changes.
- Specify on-board security events. Agree event catalogues, filters and reporting with ECU suppliers for new platforms, including signing and timestamps, and validate them on test vehicles.
- Build the fleet inventory join. Link pseudonymous vehicle IDs to ECU hardware, software versions and update history so each alert answers "which other vehicles are exposed?".
- Pilot on an internal fleet. Run detections on engineering and employee vehicles, tune thresholds, and test the privacy controls and the data protection impact assessment before customer vehicles.
- Integrate incident response. Write product playbooks covering safety escalation, back-end containment, OTA remediation, regulator and Auto-ISAC communication, and evidence handling. Exercise them; NHTSA recommends regular incident response exercises.
- Roll out and report. Extend to customer fleets in rings by platform and market, and produce the first R155 annual monitoring report from VSOC data. Keep a rollback plan for any on-board change, such as reverting IdsM reporting modes via diagnostics.
Measuring the VSOC
| Metric | What it shows |
|---|---|
| Share of R155-approved vehicle types with active telemetry and detection coverage | Whether 7.2.2.4 monitoring is real across the fleet |
| Median time from event on vehicle to alert in the VSOC | Pipeline latency, including cellular and batching delays |
| Time to identify all affected vehicles for a new vulnerability | Quality of the component and update database |
| Time from confirmed threat to mitigation (back-end change or OTA) | Evidence for the "reasonable timeframe" in 7.2.2.3 |
| True positive rate of top detections, reviewed quarterly | Detection quality and analyst load |
| Back-end machine credentials monitored and rotated within policy | Coverage of the identity attack surface |
Framework mapping
| Framework | Reference | VSOC relevance |
|---|---|---|
| UN R155 | 7.2.2.2 (g) and (h), 7.2.2.3, 7.2.2.4, 7.3.7, 7.4.1; Annex 5 M7, M9, M13, M15, M19 | Monitoring, response, vehicle detection capability and annual reporting |
| ISO/SAE 21434 | Clause 8 continual cybersecurity activities (including 8.3 cybersecurity monitoring); clause 13 operations and maintenance | Monitoring, event evaluation and incident response across the lifecycle. See the ISO/SAE 21434 Automotive Cybersecurity Engineering Guide |
| NHTSA Cybersecurity Best Practices (2022) | G.16 to G.18 detection and analysis; G.28 to G.34 incident response; T.12 and T.13 event logs aggregated across vehicles | US guidance that matches the VSOC model |
| NIST CSF 2.0 | DE.CM-01, DE.CM-09, DE.AE-02, RS.MA-01, ID.RA-08 | Monitoring, analysis, coordinated response and vulnerability disclosure intake |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring, AU-6, AU-12, IR-4, IR-6, RA-5 | Control language for monitoring, logging, incident handling and reporting |
Common failure patterns
- Treating monitoring as a paper process. A CSMS describes monitoring, but no telemetry arrives from the vehicles, so the annual report has nothing to say. Prove data flow per vehicle type before approval.
- Forgetting the back end. Effort goes into CAN anomaly detection while telematics APIs, cloud keys and mobile apps, the most common real-world entry points, go unmonitored.
- Unauthenticated telemetry. Events are sent unsigned, so an attacker can flood or spoof the VSOC. Use the vehicle certificate and event signatures.
- No fleet configuration data. Analysts cannot tell which vehicles run the vulnerable software, so response stalls. Build the component and update database first.
- Privacy as an afterthought. Collecting precise location or identifiers without a legal basis forces a pause or rebuild. Design consent and minimisation into the pipeline.
- Unclear response authority. Nobody can approve disabling a remote feature at night, so a live attack continues. Pre-authorise actions in playbooks.
Practitioner checklist
- Map each R155 monitoring and reporting paragraph to a named VSOC owner and evidence source.
- Ingest telematics API, identity, OTA, cloud and mobile app logs before in-vehicle data.
- Agree a security event catalogue, filtering and signing with every ECU supplier.
- Maintain a per-vehicle component and update database joined to alerts.
- Complete a data protection impact assessment and consent model for vehicle telemetry.
- Inventory and monitor vehicle certificates, back-end service accounts, API keys and tool credentials.
- Write playbooks with safety escalation, back-end containment, OTA remediation and regulator contact.
- Join Auto-ISAC or an equivalent sharing community and connect the PSIRT intake to the VSOC.
- Track coverage, latency, affected-vehicle identification time and time to mitigation.
- Produce the annual R155 monitoring report from VSOC data, not from memory.
Standards and references
- EUR-Lex: UN Regulation No 155 Cyber security and cyber security management system (OJ L 2025/5)
- NHTSA: Cybersecurity Best Practices for the Safety of Modern Vehicles (2022)
- AUTOSAR: Specification of Intrusion Detection System Manager
- ISO: ISO/SAE 21434 Road vehicles, Cybersecurity engineering
- Auto-ISAC: Automotive Cybersecurity Best Practices
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: UNECE R155 Cyber Security Management System Guide · Automotive Cybersecurity Guide · UNECE R156 Software Update Management System Guide · Connected Fleet and Telematics Security Guide · PSIRT Guide