Vehicle SOC: reference scenario

01The challenge

Vehicles report in seconds. Closure crosses a supply chain.

Detection is already automated: the gateway IDS raises a security event, the TCU sends it to the cloud and the VSOC sees it in seconds, next to signals from the mobile app, the OTA server, PKI, V2X and EV charging. Closing one fleet risk is the slow part.

Fig. 1Where the signals come from

TCUIVIADASBCMBMSOBD-IIGateway · IDS

Vehicle SOCin seconds

IDS security eventsTelematicsApp APIsOTAPKI · V2XEV charging

ECUs talk over CAN and Ethernet; the gateway IDS reports security events through the TCU. Events and fleet logs arrive in seconds.

Fig. 2Who has to act before one fleet risk is closed

VSOC analystReal attack or noise? Which vehicles?Hours

Product security (PSIRT)Which ECU, which software, what TARA risk?Days

E/E & safety engineeringRoot cause? Any safety impact?Days

Tier-1 supplierPatch the ECU software, prove it holdsWeeks–months

OTA release board · R156Which VINs, which campaign, when?Weeks

HomologationDoes it touch the type approval?Days

Legal & privacyDisclose? Notify the regulator and customers?Days

Dealers & customer careVehicles that never take the updateMonths

Each handoff waits on email, spreadsheets and supplier calls, and the fleet stays exposed until the last vehicle is updated.

02The approach

One fleet harness. A swarm with different triggers.

The same agent factory, with a vehicle-SOC harness. At its centre is a fleet asset graph that links every VIN to its model, ECUs, software and suppliers, plus the TARA, the owners and approvers, guardrails, memory, your tools, your model and the registers.

Fig. 3Signals in · fleet context added · each risk worked to closure

On-board IDS events

Telematics & TCU logs

Backend & app APIs

OTA & update server

PKI, V2X & digital key

EV charging

Threat intel · Auto-ISAC

SBOM per ECU

Fleet harness

Fleet asset graphVIN ↔ model ↔ ECU ↔ software ↔ supplier

TARA & threatsISO/SAE 21434 risk per item

Owners & approversVSOC, PSIRT, OTA board, Tier-1s

Guardrailsscopes, caps, autonomy tiers

Memorypast incidents, decisions

ToolsSIEM, ticketing, PLM, OTA, PKI

Your modele.g. Amazon Bedrock

Registersfleet risk, R155 evidence, SLAs

EventFleet triage

ContinuousCampaign correlation

IntelAdvisory-to-VIN

GatedBackend containment

Days · SLASupplier & OTA follow-through

ScheduledR155 evidence

Same factory as any SOC swarm, only the harness changes: fleet context, suppliers and type approval in the loop.

03Telemetry to IoC

Raw telemetry has no IoCs. The agent writes them.

A connected-car backend writes probe data and API logs: millions of lines, none of them an alert. A continuous agent sweeps the whole fleet every 30 minutes and reads each line with context: where the request came from, what the error sequence means, how this owner uses the car and how this model should behave.

Fig. 4One night, one vehicle: VIN …4471

telematics-ingest · app logs · raw, no alerts

02:10:58  VIN…2208  TEL    OK          soc=78% odo=4121202:11:04  VIN…4471  RKE    AUTH_FAIL   rolling_code_mismatch02:11:09  VIN…4471  RKE    AUTH_FAIL   rolling_code_mismatch02:11:15  VIN…4471  RKE    AUTH_FAIL   counter_replay02:11:40  VIN…9310  TEL    OK          soc=64% park02:12:40  VIN…4471  BLE    KEY_WARN    rtt=212ns limit=60ns02:13:02  API  POST /remote/unlock   401  ip=185.220.x.x02:13:30  API  POST /auth/refresh    200  new_device02:13:41  VIN…5127  OTA    CHECK_OK    fw=4.2.102:14:05  VIN…4471  SECOC  MAC_FAIL    ecu=BCM02:14:22  VIN…4471  UDS    0x27        NRC 0x3502:14:31  VIN…4471  UDS    0x27        NRC 0x3602:15:10  VIN…4471  RKE    UNLOCK_OK   door=driver02:15:12  VIN…4471  PWR    IGNITION_ON02:15:20  VIN…7712  TEL    OK          charging

IP & location185.220.x.x is a hosting network in Romania; the owner’s phone was last seen in Pune.

Error signatureRolling-code mismatch → replay → SecOC MAC fail → UDS lockout → unlock: relay / replay.

This owner’s patternUnlocks 07:30–09:00 and 18:00–20:00 from 2 known devices. Never at 02:00.

Normal for this modelAt most 2 key failures a day per VIN; no new device pairing mid-attempt.

IoC written by the agentconfidence 0.91

VEHICLE

VIN …4471 · Platform P3 · TCU 4.2.1

INDICATORS

hosting IP (RO) · new device · BLE round trip 212 ns

PATTERN

3 key failures → replay → MAC fail → UDS lockout → unlock

Next: ask the owner in the OEM app

Synthetic sample: identifiers and values are illustrative.

04Owner in the loop

The owner confirms in one tap. The SOC sees only real attacks.

The IoC goes to the OEM’s own app through its webhook API, under the app’s consent settings. The owner gets a plain-language question (like a bank checking card fraud), and the answer decides what happens next.

Fig. 5“Was this you?” Two answers, two paths

MyCar · 02:31

Unusual unlock of your carUnlocked at 02:15 near Bucharest while your phone is in Pune. Was this you?

Yes, it was meNoReply…

“Yes, it was me”121 a day

A family member, a new phone. One tap suppresses the IoC, closes the ticket with the answer on record, and the owner’s baseline learns. No analyst ever sees it.

“No. I’m in Pune.”19 a day

A case lands with a VSOC analyst: IoC, telemetry timeline and the owner’s reply already attached.

The analyst asks Optimus, ad hoc:

› sessions from 185.220.x.x?
37 VINs probed, 3 unlocked
› draft containment
revoke 3 digital keys · block the IP at the API gateway

The analyst approves. Keys revoked, IP blocked.

Verdict and advice go back through the app: re-pair the key at a dealer, turn on 2-step login, keep the fob in a signal-blocking pouch.

28 minfrom the unlock to a protected owner

Illustrative run on sample data. Containment runs only after the VSOC analyst approves it.

Fig. 6Per day across the fleet

2.1B

raw telemetry events

3,800

anomalies once context is applied

140

IoCs with evidence, owners asked “Was this you?”

real cases for the SOC · 121 closed by the owner’s “Yes”

Illustrative volumes for a 1.2-million-vehicle fleet.

05One fleet risk

One fleet risk. Agents carry it. Owners decide.

A campaign across 412 vehicles, from the first IDS event to the last vehicle updated. Agents do the correlation, drafting, chasing and record-keeping; four named people make the decisions.

Fig. 7Start to closed: eight steps, four approvals

DetectOn-board IDS raises the event; the VSOC SIEM receives it. Your existing tools.No approval

CorrelateGroups 412 VINs: same TCU software, same cellular route. A campaign, not noise.No approval

AssessMatches SBOM and TARA: a known CVE in the modem stack. Drafts the risk rating.PSIRT confirms the rating

ContainDrafts backend controls: block the remote-diagnostic route, revoke suspect session certificates.VSOC lead approves

FixSends the evidence pack to the Tier-1. Follows up; escalates when the fix breaches SLA.No approval

ReleaseDrafts the OTA campaign: affected VINs, dependencies, R156 notes. Pilot fleet first.OTA board approves

VerifyTracks uptake per VIN, sends offline vehicles to dealers, confirms the IDS events stop.No approval

ReportDrafts the PSIRT advisory and the R155 monitoring record; updates the live register.Homologation & legal sign off

Illustrative run on sample data. Every approval is a named person; agents never push software to a vehicle.

06Control by design

Agents prepare the change. Your people release it.

In automotive the first question is: can an agent touch my vehicles? The answer is built into three zones, and into the autonomy tier you set for each action.

Fig. 8Three zones of control

VSOC & back office · agents act inside guardrailsTriage, correlate, enrich, open tickets, follow up, escalate. Scoped, capped, reversible, logged.

Backend controls · gatedAPI-gateway rules, certificate revocation, access changes: a named approver says yes in Teams or Slack.

The vehicleReached only through your OTA platform and its R156 release approval. Signing keys stay in your HSM, out of every agent’s reach.

Your cloud: self-hosted in your AWS accountYour keys: KMSYour model, of your choiceEvery action loggedISO 27001 · SOC 2 Type II

Your cloud, your keys, your model. Every action logged.

Fig. 9Autonomy tiers you set per action

A0 · AdvisorySuggests a TARA rating, drafts the PSIRT advisorynothing runs

A1 · GatedBackend block rule, certificate revocation, OTA campaign requestnamed approver

A2 · BoundedEnrich, correlate, open tickets, follow up, suspend one sessionscoped · reversible

A3 · By designForensics agent is write-denied; no agent holds signing keyscapability removed

Tiers follow each action’s reversibility and blast radius, never the model’s confidence.

07Type-approval evidence

Type approval asks for proof. The register is live.

Every triage, rating, approval, supplier follow-up and OTA campaign is already logged with its owner, so the evidence for the approval authority is a by-product of the work, not a project before each audit.

Fig. 10From requirement to always-current evidence

StandardAsks forWhat the agents doEvidence, always current

UN R155 · CSMSIndia: AIS-189

Monitor, detect and respond to attacks on the fleet; report at least yearly.

Fleet triage, campaign correlation, backend containment, each step logged with its approver.

Monitoring report built from the live register.

ISO/SAE 21434 · cl. 8Continual activities

Monitoring, event evaluation, vulnerability analysis and management.

Advisory-to-VIN sweeps, TARA-linked ratings, supplier follow-through.

Every vulnerability with rating, owner, decision, status and SLA.

ISO/SAE 21434 · cl. 13Operations & maintenance

Incident response and updates while vehicles are in the field.

Forensic evidence pack, response steps and approvals in one timeline.

Chain of custody and a full timeline per incident.

UN R156 · SUMSIndia: AIS-190 · ISO 24089

Software updates under a managed process, with records per vehicle type.

OTA campaign drafted with affected VINs; approvals routed; uptake tracked.

Update record per campaign and per vehicle.

ISO/SAE 21434 · cl. 7Supplier interfaces

Interface agreements: who fixes what, and by when.

Tier-1 follow-ups and escalations against the agreed SLAs.

SLA history per supplier and per vulnerability.

Requirements summarised. Check exact clauses against the published texts.

08Getting started

Live in 30 days. Then yours to grow.

The 30-day path

1Day 0–2 · InstalledWorkspace in your own cloud account, with your SSO (and your brand, if you run a VSOC service).

2Week 1 · Fleet wiredIDS backend, telematics, OTA and PKI connected, plus custom integrations for OEM-specific APIs.

3Week 2–3 · Six agents liveFleet triage, advisory-to-VIN, containment, Tier-1 follow-through, JIT OTA access, R155 evidence.

4Week 4 · Your team buildsYour team builds the next agents; the forward-deployed engineers step back.

The same blueprint for IT/OT

talk to us about plants & industrial OT

	Connected vehicles	Plants & industrial OT
Asset graph	VIN ↔ model ↔ ECU ↔ software ↔ supplier	site ↔ line ↔ controller ↔ firmware ↔ vendor
Owners	VSOC, PSIRT, OTA board, Tier-1s	OT security, plant engineering, vendors, change board
Release path	Your OTA platform and its R156 approval	Your maintenance window and change approval
Evidence	R155 / R156 · ISO/SAE 21434	The OT security standard you report against

Same agent factory and guardrails; the harness changes to match the environment. Agents prepare changes; your people release them.

A vehicle SOC that closes fleet risk, with every owner in the loop.