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.

# 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:\"<base64 SPKI>\", 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.

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:'<the /128>', kind:'conn', from:'-24h'}})
# -> per-event records: timestamp, kind (dns/conn/alloc), destination, decision, bytes

whisper logs --agent <the /128> --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:'<the /128>'}})
# after it runs:
dig -x <the /128> +short            # -> empty
curl -s https://whisper.online/verify-identity/<the /128>   # -> {"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:

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.

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.

# Monitor: one vehicle's outbound connections over the last day
CALL whisper.agents({op:'logs', args:{agent:'<the vehicle /128>', 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('<suspect destination>')"

# Respond: contain the compromised identity, provably
CALL whisper.agents({op:'revoke', args:{agent:'<the vehicle /128>'}})

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.

# The vehicle verifies the update endpoint's identity against the DNSSEC root: Whisper's API is NOT trusted
whisper verify --trustless updates.<fleet>.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 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.

# Verify: keyless, no account. Anyone can confirm the identity is genuine and current
curl -s https://whisper.online/verify-identity/<the /128>
# -> {"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/<the /128>

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:

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.

# A third party proves its identity to you (or a regulator): no account, no shared secret
whisper verify --trustless <the third party's /128>

# 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 third party's /128>')"

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:

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: how the device-derived /128 is computed from the key a vehicle already holds
• Fleet-API-abuse cure: the same identity, applied to the stolen-token problem at the API ingress
• Platform integrations: where the /128 plugs into AWS IoT Core, COVESA uProtocol, AUTOSAR Adaptive and more