# Automotive compliance: R155, ISO 21434 & the ATM **R155, R156, ISO/SAE 21434, the Auto-ISAC Threat Matrix and the EU Data Act all ask one thing of a connected-vehicle backend: which party is this, is it authorised, and can you prove it and shut it off?** A backend gated by bearer tokens and shared, NAT'd egress IPs can't answer that. A routable, DANE-provable, one-call-revocable IPv6 `/128` per party can. It produces the log, the attribution and the kill-switch those frameworks want as evidence, not as a paragraph in a policy document. ## What every framework is really asking Read the connected-vehicle regulations side by side and the same three questions keep surfacing, phrased in five different vocabularies: - **Identity**: who or what is on the other end of this vehicle-to-cloud connection, and can a third party verify it without trusting your word for it? - **Attribution & monitoring**: what did that party do, to which destinations, and can you show a continuous record of it? - **Response**: when one party turns hostile, can you contain it, provably and fast, across the whole fleet? None of these is a logging problem you fix with more log lines. They are *identity* problems: you cannot attribute, monitor or contain an actor that has no stable, provable identity in the first place. Whisper's job here is to give every party on the cloud/IP boundary exactly that identity, then let the standard toolchain read the evidence off it. ## The evidence: real and shipped Everything this page maps to a regulation is a surface that exists and answers today. Four primitives do the work; each is checkable with `dig`, `curl`, or one control-plane call. ### A device-derived `/128` identity A vehicle or ECU already holds a hardware key: an IEEE 802.1AR IDevID, a TPM, or a secure-element key. Whisper derives a deterministic IPv6 `/128` from that key's *public* SubjectPublicKeyInfo plus the VIN (and an optional ECU serial). The address is tenant-bound (fleet-unlinkable to an outsider), DNSSEC-anchored, DANE-EE `3 1 1` pinned, and RDAP-registered. Re-deriving from the same key and VIN yields the same `/128`; nothing new to store, nothing to steal that would let a scraper forge it. ```bash # Provision the vehicle/ECU identity from the key it already holds (control plane, live). # identity_public_key is the base64 SPKI of the device's IDevID / TPM / secure-element key. curl -sS https://graph.whisper.security/api/query \ -H 'X-API-Key: whisper_live_xxx' \ -H 'content-type: application/json' \ --data '{"query":"CALL whisper.agents({op:\"connect\", args:{tier:\"wireguard\", identity_public_key:\"\", vin:\"1HGCM82633A004352\"}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}' # -> the deterministic /128 + a WireGuard config. Same key+VIN -> same /128 (idempotent). # A different VIN on the same tenant -> 409; a non-string VIN -> 400. ``` > `1HGCM82633A004352` is the standard textbook example VIN, used here only as a placeholder. No real vehicle or manufacturer is implied. The `--vin` CLI flag isn't shipped yet, so vehicle provisioning is shown via the control-plane call above, which **is** live. ### Per-`/128` egress logs Because each party owns a dedicated `/128`, every DNS lookup and connection it makes is unambiguously *its*, with no shared-IP noise to filter. Pull one party's trail directly: ``` CALL whisper.agents({op:'logs', args:{agent:'', kind:'conn', from:'-24h'}}) # -> per-event records: timestamp, kind (dns/conn/alloc), destination, decision, bytes whisper logs --agent --from -24h --kind conn ``` ### One-call revoke Containment is a single call. It tears down the `/128`, its PTR and its DANE record worldwide at DNS-TTL speed. The teardown is provable with the same public tools that proved the identity. ``` CALL whisper.agents({op:'revoke', args:{agent:''}}) # after it runs: dig -x +short # -> empty curl -s https://whisper.online/verify-identity/ # -> {"is_whisper_agent": false} ``` ### The attribution graph Turning a raw destination into "known-bad C2" or "clean CDN" is a read-only query against the public graph API. There's no CLI subcommand, just the endpoint any tool can hit: ```bash curl -s https://graph.whisper.security/api/query \ -H 'X-API-Key: whisper_live_xxx' \ --data-urlencode "q=CALL whisper.identify('185.220.101.1')" # -> what the address is, who it belongs to, threat-intel reputation, relationships ``` The read-only verbs (`identify`, `origins`, `walk`, `variants`, `history`) run the same way, over an infrastructure-and-threat-intelligence graph of billions of nodes. That is the enrichment that turns a per-vehicle egress log into a detection. ## The map, at a glance Each row is a framework, the control it asks for, and the shipped evidence that satisfies it. The deep sections below unpack each one. | Framework | What it requires | Whisper evidence (shipped) | |---|---|---| | **UN R155** (CSMS) | Continuous monitoring, attack detection and response over the vehicle-to-backend interface | Per-`/128` egress logs (monitoring) · attribution graph (detection) · `revoke` (response) | | **UN R156** (SUMS) | Integrity and traceability of every software update reaching the vehicle | DANE-pinned identity on the update endpoint · attributable, revocable logs of the distribution path | | **ISO/SAE 21434** | Risk-driven cybersecurity across the lifecycle; monitoring and incident response in operations | Identity as a lifecycle-managed asset: issue → verify → revoke, with the monitoring/IR evidence above | | **Auto-ISAC ATM** | A shared taxonomy of automotive tactics & techniques to detect and respond against | Evidence maps to ATM tactics: `/128` allowlist (Initial Access) · graph (C2) · logs (Exfiltration) · `revoke` (Containment) | | **EU Data Act** | Fair, transparent, consent-bound, revocable third-party access to vehicle data | Each authorised party = one verifiable, revocable `/128` + a who-accessed-what record | ## UN R155 (CSMS): monitor, detect, respond R155 obliges a manufacturer to run a Cyber Security Management System that, among other duties, *monitors* the vehicle fleet and its backend, *detects* attacks, and *responds* to them, with explicit attention to the vehicle-to-backend communication channels and the back-end servers themselves (Annex 5 catalogues exactly those threats). That interface (cloud and IP, not the in-vehicle bus) is precisely where Whisper sits. The three shipped primitives line up one-to-one with the three verbs R155 uses: - **Monitor**: the per-`/128` egress log is a continuous, per-party record of every destination a vehicle's telematics unit or a fleet API consumer reached, with the decision and byte count. Because the identity is a dedicated address, the record needs no reconstruction from correlated application logs. - **Detect**: the attribution graph turns a destination in that log into a verdict. A head unit that suddenly beacons to a low-reputation host stands out because the graph knows the host, not because you wrote a signature for it. - **Respond**: `revoke` is the containment action, provable worldwide at DNS-TTL speed. ```bash # Monitor: one vehicle's outbound connections over the last day CALL whisper.agents({op:'logs', args:{agent:'', kind:'conn', from:'-24h'}}) # Detect: score a destination the log flagged curl -s https://graph.whisper.security/api/query -H 'X-API-Key: whisper_live_xxx' \ --data-urlencode "q=CALL whisper.identify('')" # Respond: contain the compromised identity, provably CALL whisper.agents({op:'revoke', args:{agent:''}}) ``` ## UN R156 (SUMS): update traceability R156 governs the Software Update Management System: the integrity of every over-the-air update and a traceable record of which software reached which vehicles. **Whisper does not sign the update package.** The payload's integrity and provenance stay with the manufacturer's code-signing and SUMS process, exactly where they belong. What Whisper adds is on the transport boundary R156 also cares about: - The endpoint a vehicle fetches an update from can carry a DANE-pinned identity the vehicle verifies *trustlessly* (before it fetches a byte) with no shared CA to mis-issue against. - The distribution egress is attributable and revocable, so "which identity served which fetch, and can we cut it off" is answerable from the same logs and the same `revoke`. ```bash # The vehicle verifies the update endpoint's identity against the DNSSEC root: Whisper's API is NOT trusted whisper verify --trustless updates..agents.whisper.online dnssec pass DNSSEC-root AAAA, PTR and TLSA(3 1 1) all DNSSEC-validated to the IANA root dane pass DNSSEC-root served leaf SPKI-SHA256 == TLSA pin ``` See [DANE & TLSA](/docs/dane) for the byte-for-byte pin check that stands behind that one line. ## ISO/SAE 21434: the secure lifecycle Where R155 is the regulation, ISO/SAE 21434 is the engineering "how": a risk-driven cybersecurity lifecycle built on threat analysis and risk assessment (TARA). Whisper contributes a concrete, verifiable *control* that a TARA can cite against specific threat scenarios: - **Spoofing / unauthorised access** to a backend API by an impersonating client: mitigated because a caller either holds and can prove its `/128` (DANE + RDAP) or it doesn't; a stolen bearer token off an un-allowlisted address is separable. - **Tampering with attribution**: mitigated because the record is keyed to a registry-anchored address, not a mutable field in your own database. The evidence lands most directly in the operations-and-maintenance phase: the clause family covering cybersecurity monitoring, event assessment and incident response. The `/128` is a lifecycle-managed asset: it is issued at provisioning, verified trustlessly by anyone, and retired on `revoke`, the full issue → verify → retire arc a lifecycle standard expects, with monitoring evidence in between. ```bash # Verify: keyless, no account. Anyone can confirm the identity is genuine and current curl -s https://whisper.online/verify-identity/ # -> {"is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": {...}} # The registry record for the same address (RDAP, RFC 9083) curl -s https://whisper.online/ip/ ``` ## Auto-ISAC Automotive Threat Matrix The Auto-ISAC Automotive Threat Matrix (ATM) is an ATT&CK-style taxonomy of automotive tactics and techniques, meant to give defenders a common language for what an attack looks like and how to detect it. Whisper's shipped evidence maps cleanly onto several ATM tactics: | ATM tactic | How the shipped evidence applies | |---|---| | **Initial Access** | A caller with no allowlisted Whisper `/128` (a scraper reusing a stolen token from a random address) never reaches the ingress in the first place. | | **Command & Control** | The attribution graph identifies a beaconing destination in a vehicle's egress log as known-bad, without a pre-written signature. | | **Exfiltration** | Per-`/128` logs show exactly which destination received how many bytes from which vehicle identity. | | **Impact / Containment** | `revoke` severs a compromised identity fleet-wide at DNS-TTL speed, provably. | > **Roadmap, not shipped:** a machine-readable export that emits this evidence as STIX 2.1 objects over TAXII, tagged with Auto-ISAC ATM technique IDs as JSON, is on the roadmap. Today the mapping is analyst-driven from the same logs and graph shown above: real evidence, human-correlated to the matrix. ## EU Data Act: the authorised/unauthorised line The EU Data Act entered into force on 12 September 2025, with accessibility-by-design obligations following in 2026 that require manufacturers to open in-vehicle data to *user-chosen* third parties. That multiplies the number of parties touching the backend at the exact moment R155 demands you control them: a commercial forcing function pointed straight at identity. A verifiable per-party identity is, quite literally, the authorised-versus-unauthorised line. An authorised third party is one that holds a `/128` it can prove (via DANE and RDAP, keylessly, to you or to a regulator) and that you can revoke in one call. The alternative, a pile of interchangeable bearer tokens, cannot draw that line at all: a token authenticates a claim, never the party. ```bash # A third party proves its identity to you (or a regulator): no account, no shared secret whisper verify --trustless # You answer "who accessed what" from attribution, not from a DPA paragraph curl -s https://graph.whisper.security/api/query -H 'X-API-Key: whisper_live_xxx' \ --data-urlencode "q=CALL whisper.identify('')" ``` The Data Act makes you open the doors; a per-party `/128` is the doorway that knows who walked through and can shut on exactly one of them. ## SIEM & threat-intel export The evidence above is pullable now via the `logs` op and the graph API, and it exports to **Splunk**, **Microsoft Sentinel** and **OpenCTI** today. The remaining exports are on the roadmap, labelled honestly so nobody plans against vapour: | Destination | Status | |---|---| | Splunk | **Shipped** | | Microsoft Sentinel connector | **Shipped** | | OpenCTI | **Shipped** | | STIX 2.1 / TAXII feed (with Auto-ISAC ATM technique-ID JSON) | Roadmap | Until the roadmap items land, the same records are already reachable: the exports are a convenience layer over evidence you can pull today. ## What this is (and is not) Whisper anchors **one** boundary: the cloud/IP interface between a vehicle (or a fleet-API consumer) and the backend. It is deliberate about what it does not touch. - It is **not** the manufacturer's CSMS or SUMS. It is the identity-and-attribution layer those systems consume. It complements them; it does not replace them. - It does **not** sit inside SecOC on the in-vehicle bus, the V2X / SCMS air interface, or the ISO 15118 charging handshake. Those keep their own PKIs; a Whisper DANE-anchored identity complements them at the network layer without cross-signing. - These platform integrations are *proposed*, not vendor-endorsed. Each complements the stack it names and replaces none of it. Everything on this page that is described as working is checkable, today, with `dig`, `curl` and one control-plane call. Everything on the roadmap is labelled as such. ## Next - [Vehicle & ECU identity](/docs/industries/auto/vehicle-identity): how the device-derived `/128` is computed from the key a vehicle already holds - [Fleet-API-abuse cure](/docs/industries/auto/fleet-api-abuse-cure): the same identity, applied to the stolen-token problem at the API ingress - [Platform integrations](/docs/industries/auto/automotive-integrations): where the `/128` plugs into AWS IoT Core, COVESA uProtocol, AUTOSAR Adaptive and more