Platform integrations

Whisper sits beside the embedded stack you already run and anchors exactly one thing: a routable, verifiable identity at the device/cloud IP boundary. That's the layer where an extracted credential today looks identical to the real device.

Everything below is written the same way: Whisper complements the mechanism you have; it never replaces it. We do not touch secure boot, the RTOS, or a radio protocol's own security layer (Matter fabric credentials, LoRaWAN OTAA, Thread). Those live in the silicon, the build, and the radio stack, and they are already someone's job. Whisper's job is the network identity of whatever is talking to your cloud: the gateway, the edge box, the update client, the broker client. It's expressed as an IPv6 /128 that DNSSEC, DANE and RDAP can prove and one owner-thrown call can revoke.

First, the honest capability matrix

Not every microcontroller can run this, and this page will not pretend otherwise. The keyless verification surface needs only a TLS + HTTPS client. The resolver path (DoH, RFC 8484) is a small HTTP exchange whose real cost is the TLS engine: roughly 20–60KB of flash and 25–63KB of peak handshake RAM with an embedded TLS library. The routed identity path (WireGuard from the device's own /128) is an OS-integration question. That yields four honest rows:

The gateway pattern: identity for the devices that can't hold one

Below the TLS line (8-bit AVR, tiny LoRa nodes, legacy RS-485 sensors), the device cannot carry the identity, so the gateway carries it for the segment: an embedded-Linux (or ESP32-class) concentrator holds its own secure-element-derived /128, authenticates the local nodes with whatever the local bus already uses, and everything crossing the IP boundary sources from the gateway's provable identity with default-deny egress. This is shipped today, because the gateway is Linux-class:

# the gateway is the identity boundary: one provable /128, default-deny egress
whisper policy --agent 2a04:2a01:1c0::e51d \
  --default deny --allow telemetry.example-maker.com,ota.example-maker.com
policy updated · effective at DNS-TTL speed across both servers

# what did the segment actually reach last night? Per-identity, one keyed call:
CALL whisper.agents({op:'logs', args:{agent:'<the gateway /128>', kind:'dns', from:'-24h'}})

Azure IoT Hub + DPS, and AWS IoT Core

Cloud provisioning services are the best tool there is for X.509 enrollment into their own cloud, and this integration leaves them exactly where they are. The pattern is parallel identity: the device keeps its DPS/JITP enrollment for in-tenant auth, and the same secure-element key also derives its Whisper /128, giving the device an identity that exists outside the tenant: one your partners, your customers' auditors, and your own multi-cloud backends can verify with stock tools, and one that survives any single platform's lifecycle.

# the backend (or a partner's) checks the out-of-tenancy identity, keylessly:
curl -s https://whisper.online/verify-identity/2a04:2a01:e5a7:41c9:04d0:c85f:3a1b:77e2
{"is_whisper_agent": true, "dane_ok": true, "jws_ok": true, "evidence": { … }}

Matter: DAC at commissioning, /128 for the service life

Matter gives every device a Device Attestation Certificate checked against the CSA's Distributed Compliance Ledger at commissioning: a strong answer to "was this device made by whom it claims," inside the fabric, at join time. What Matter deliberately doesn't provide is an operational, internet-facing identity for the device's whole service life: something a cloud backend, a partner, or an auditor outside the fabric can check years later. That's the slot the Whisper /128 fills, derived from the same class of secure element the DAC already lives in.

MQTT brokers & device APIs: the DANCE check

The broker or device API is where fleet auth actually happens, and where the password file or static-credential list lives today. The integration is the DANCE pattern: the client presents the cert whose key sits in its secure element, and the broker verifies the presented leaf against the device's DNSSEC-signed TLSA 3 1 1 pin instead of a password table.

# the records the broker checks are published and live today, per identity:
dig +short TLSA _443._tcp.04d0c85f3a1b77e2.<tenant>.agents.whisper.online
3 1 1 b653a4ef…fcb82d1d

OTA infrastructure: verify the server, attribute the client

Update infrastructure cuts both ways. Downstream, the device should confirm it is talking to the genuine update host before it fetches an image: with the update server itself carrying a Whisper identity, that check is a DANE pin comparison any TLS-capable device can do today, alongside your existing image signing (which stays exactly where it is). Upstream, every fetch arrives from the device's own /128, so your CDN logs become a per-device record instead of a NAT blur.

# on the device, before fetching: is this the genuine OTA endpoint?
dig +short TLSA _443._tcp.ota.<tenant>.agents.whisper.online
3 1 1 9c41d2ab…77e01f36
openssl s_client -connect ota.<tenant>.agents.whisper.online:443 </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der \
  | openssl dgst -sha256        # must equal the TLSA pin above

LPWAN & cellular concentrators

A LoRaWAN gateway or cellular concentrator funneling a thousand sensors is a small Linux computer behind a carrier NAT, usually invisible in your logs beyond a shared IP. LoRaWAN's OTAA keys authenticate the sensors to the network server; nothing authenticates the gateway to the internet. The integration is the shipped gateway pattern above: one /128 per concentrator, default-deny egress, per-identity logs.

Shipped today vs roadmap

Honesty about what runs matters more here than anywhere. The identity primitive under every integration is live and provable right now; the per-platform SDKs and packaged recipes are phase-2 deliverables, and none of them will be documented as installable until it has passed a full end-to-end test (provision a real device, run it, verify the routable /128 with dig -x and RDAP, prove the egress).

Next

• Device & IDevID identity: the shipped derivation these integrations all build on
• Passwordless device auth: the DANCE model the broker integration applies
• Embedded compliance: where the evidence lands for the EU CRA, 62443 and EN 303 645