Your fleet doesn't need another cloud enrollment. It needs an identity it can prove.
Device-security tooling stacks up, an enrollment service here, an anomaly detector there, and none of it stops a credential that was copied out of flash or a source that rotates across three clouds. Whisper isn't another console. It's one primitive, the address is the identity, expressed as three planes that plug into the stack you already run.
dig. That one primitive becomes three planes: identity, an attribution graph that survives IP rotation, and per-device governance, standing on real routable space at AS219419, anchored at the IANA root. Our API is never in the trust path.
whisper verify --trustless · anchored at the IANA DNS root. Our own API is not in the trust path.
Everything below derives from one line: the address is the identity.
A routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), deterministically derived from a key, DNSSEC-anchored, DANE-EE pinned, RDAP/WHOIS-registered: re-derivable and verifiable by anyone with dig.
Most device security starts from an observation, a packet, a log line, a source IP, and tries to infer what's behind it. Whisper starts from the other end: it gives the thing an identity that is its address, cryptographically bound to a key the hardware already holds, and publicly verifiable without trusting the issuer. Point it at a gateway, a sensor hub, an industrial controller, or an edge box running models, and the question "who is this?" stops being an inference and becomes a fact anyone can check. Three products fall out of that one primitive: not three integrations you wire together, three faces of the same address.
One address, three jobs: who is this, who's really behind that, and what may talk to what.
Identity answers who is this, provably. The attribution graph answers who's really behind a source that rotates. Device governance answers what may talk to what. Each plane is useful alone; together they close both gaps every device-impersonation attack leans on.
A device identity your backend authorizes on, not an artifact anyone can copy out of flash.
This is the plane that closes the gap the device-impersonation attacks live in: credentials that can be extracted. Bind authority to the silicon, not to a string whoever holds can replay.
Point the primitive at devices. Derive each device's /128 from the 802.1AR IDevID key it already holds in its secure element (ATECC608, SE050, OPTIGA Trust M) or on-chip OTP/PUF storage, with the device serial or EUI-64 as the domain separator. The private key never leaves the chip; the address is a one-way function of its public half and the serial. The backend then authorizes on the device's pinned identity, and an extracted firmware image with no chip behind it authenticates to nothing.
"An extracted credential looks exactly like the real device's; how do you tell them apart after auth?"
You bind authority to the silicon, not the string. The device proves control by signing with the key that never leaves the secure element, checked against its public DANE-EE pin. A session that presents copied bytes but can't sign never had authority in the first place.
3 1 1 pin on the device's key, and a DNSSEC chain to the IANA root, for every identity, so any broker or backend can authenticate the device against public DNS instead of a password or a private CA list. The passwordless-device story →Attaches to what you already ship: the secure element, 802.1AR IDevID, BRSKI onboarding, the X.509 mTLS your device cloud runs, as the publicly verifiable, DNSSEC/DANE-anchored layer on top. No bespoke CA trust store to push to every unit; revocation at DNS-TTL speed instead of CRL/OCSP soft-fail. Standards mapping →
Attribution that survives IP rotation, because it fingerprints the operator, not the exit.
This is the plane that closes the other gap: the operator who presents your fleet's credentials from Amazon, then Google, then Azure, then a residential-proxy swarm, until your SOC only ever logs a meaningless last IP.
A live internet-infrastructure graph, 7.44B nodes and 39.3B relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intelligence, answering in under 300 ms, pulls two levers, kept honestly separate. For cloud rotation it clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy. For a residential-proxy swarm, where a subscriber IP gives an infra graph nothing to grab, a JA4/JA3 client fingerprint travels with the tooling regardless of the exit and collapses the swarm to one operator. The egress IP is the one thing this plane never relies on.
"When they rotate residential proxies and fresh cloud IPs, can you actually attribute them, or just rate-limit an IP and move on?"
Track them. Infrastructure genealogy collapses the cloud rotation; a JA4 client fingerprint collapses the residential swarm. Every answer returns a reproducible evidence chain: signed, replayable JSON your SOC, your auditors and a regulator can hand around.
identify(ip)
Who really operates a host, even behind a CDN, across any cloud.
origins(prefix) + walk(node,depth)
Cluster rotating IPs into one infrastructure genealogy.
history / watch
A timeline of an operator and a standing sentinel, plus variants(domain) to catch typosquat OTA and device-cloud domains before they activate.
read-only Cypher
Express "one source presenting N distinct device-identities in a window" as a query your agent runs, not a ticket your analyst files.
Additive to the SOC and SIEM: the same fingerprints power external attack-surface mapping and dependency blast-radius (if a cloud region goes dark, which fleets lose telemetry). Trace the full back-trace →
The same primitive governs what your devices are turning into: agents that call APIs on their own.
An OTA client fetches firmware, a telemetry daemon streams to three clouds, an edge box calls LLM APIs with a paid key. Each is an agent making network calls, and today "which device did this" is a shrug at a shared NAT address. Whisper does it with identity instead of trust.
Which device did this is the source address
Every gateway, edge box and update client egresses from its own routable /128: attribution, not a guess.
Every query and connection is logged per-device
Queryable live via op:logs: a per-identity record, not a shared firehose. The record an incident review, or a regulator, actually needs.
Policy on every query
A graph-first resolver and bound egress enforce category, geography, ownership and routing: default deny, allow or block by name or subdomain. A camera that should only ever reach its own cloud simply can't reach anything else.
Inbound devices are verifiable
FCrDNS, RDAP, whisper verify: "trust the bearer token" becomes a checkable fact. Per-device budgets, a kill-switch, one revoke.
The device-to-cloud, MQTT, OTA and edge-agent surface, governed by the same address-is-identity primitive, from day one.
What each class of device can do, stated plainly. No page here will tell you an 8-bit part speaks DoH.
The verification half is deliberately light: any client with a TLS + HTTPS stack can call the keyless verify endpoint today. A DoH client itself is tiny (RFC 8484 is a small HTTP exchange); the real cost is the TLS engine, roughly 20–60KB of flash and 25–63KB of peak RAM during the handshake. That budget draws the honest line below.
| Device class | Typical parts | On-device Whisper? | The path, honestly labelled |
|---|---|---|---|
| 8-bit MCU | AVR / ATmega328 (Arduino Uno) | no: no TLS budget | Gateway pattern. The gateway holds the /128 and speaks for the nodes behind it; the 8-bit node authenticates locally to the gateway. An ATmega328 does not speak DoH, and we won't pretend it does. |
| Wi-Fi SoC | ESP32 / ESP-IDF | ✓ | ESP-IDF ships mbedTLS, and Espressif's own esp_dns component already does DoH natively, so the resolver half works with what the vendor ships today. A packaged Whisper ESP-IDF component is roadmap. |
| Cortex-M4/M33 + RTOS | Zephyr · Nordic nRF Connect SDK · STM32Cube | ✓ | The TLS budget fits (mbedTLS at ~20–60KB flash, 25–63KB handshake RAM); the DoH client on top is small. A Whisper Zephyr module (which also covers nRF Connect) is roadmap. One caution: don't start a new design on Arm Mbed OS; Arm has set its end of life for July 2026. |
| Embedded Linux | Raspberry Pi · Yocto · OpenWrt · Zynq · PolarFire SoC | ✓ today | Shipped. The whisper CLI and the control plane run as-is: provision the /128, bring up WireGuard so every packet sources from the device's own identity, set default-deny policy, pull per-device logs. This is the class where the full product works right now. |
Two tiers everywhere, per Postel's Law: the keyless verify surface (verify-identity, RDAP, DANE, reverse-DNS) is reachable from anything with TLS today, key or no key; the control plane and routed /128 egress unlock with your key, live today on Linux-class devices and gateways, with the MCU-native SDKs shipping as labelled roadmap items. The full integration matrix →
The three planes drop into the systems your fleet already uses, at the IP boundary, never inside the silicon.
Whisper anchors the wire, not the die. Each row below is a proposed integration onto a system you already operate; the device-identity /128 is the capability that is shipped and live today. Every one is additive: it complements whatever authenticates the message, and it never reaches into secure boot, the RTOS, or a radio protocol's own security layer.
| Surface / standard you run | Where a plane plugs in: identity /128 · attribution graph · egress governance | Complements, does not replace |
|---|---|---|
| Secure element / TPM (ATECC608, SE050, OPTIGA, on-chip OTP) · shipped & live | Identity. Derives the routable /128 from the non-exportable IDevID key, and publishes a globally resolvable, DANE-verifiable, RDAP-registered name bound to it: silicon projected onto the public namespace. |
Complements the hardware root of trust; it makes an otherwise un-routable, un-discoverable key resolvable and verifiable. |
| Azure IoT Hub + DPS | Identity + attribution. Devices keep enrolling exactly as they do; each also carries a Whisper /128 your backend and any partner can verify outside the tenant, and the graph back-traces whoever presented copied credentials before. |
Complements DPS enrollment and the hub's X.509 auth; authorization inside the tenant stays exactly where it is. |
| AWS IoT Core (fleet provisioning, JITP/JITR) | Identity + attribution. Same pattern: the AWS-side cert authorizes into AWS; the Whisper /128 is the out-of-tenancy identity a third party checks with dig, and the revoke that doesn't depend on CRL distribution. |
Complements fleet provisioning; Whisper never touches the AWS policy or shadow model. |
| Matter (DAC + the CSA DCL) | Identity. The Device Attestation Certificate proves provenance at commissioning, inside the Matter fabric. The Whisper /128 is the same device's operational, internet-facing identity: verifiable by parties outside the fabric, for the device's whole service life. |
Complements DAC/DCL attestation; Whisper issues no Matter credentials and never touches commissioning. |
| MQTT brokers & device APIs | Identity + governance. The DANCE pattern: the broker checks the client's DANE-TLSA pin instead of a password list; the device's egress is policy-bound and attributable per /128. The MQTT-DANCE recipe is a labelled roadmap item; the TLSA records it checks are published today. |
Complements the broker's own auth; adds the public, per-device check it never had. |
| LPWAN / gateway concentrators (LoRaWAN, cellular) | Identity + egress governance. The gateway that concentrates a thousand sensors gets one provable /128 with default-deny egress, so a hijacked concentrator can't quietly talk to anything but its own platform. |
Complements LoRaWAN's OTAA keys; Whisper anchors the gateway↔cloud IP boundary above them. |
Read together, these land exactly where the EU Cyber Resilience Act is pushing every maker of connected products: provable identity, controllable connectivity, evidence you can file. Standards mapping →
Five things you can't stand up overnight, and a competitor can't clone from a slide.
A platform is only as durable as what sits underneath it. Whisper's three planes rest on five load-bearing pillars, each a real, checkable fact rather than a claim on a roadmap.
Real routable space, not a namespace we invented
AS219419 and 2a04:2a01::/32 are announced to the global routing table. You cannot allocate verifiable identities from address space you don't hold and can't announce, which is why this can't be reproduced with a database and a domain.
A graph you accrete, not one you query once
7.44B nodes and 39.3B relationships of BGP, DNS, WHOIS, TLS, hosting and threat intel, built over years. Attribution across rotation is only as good as the history behind it, and history is the one thing you can't buy this afternoon.
A per-identity CA, so blast radius is one
One deterministically-derived leaf per device or agent: DANE-EE pinned, never a shared intermediate. The single-CA-breach failure mode is removed by construction, not by policy.
Registry-anchored and root-anchored
Every /128 is a real RDAP/WHOIS object, and the whole chain validates through DNSSEC to the IANA root. whisper verify --trustless checks an identity without trusting Whisper: public accountability and a trust anchor you already run.
"IoT platforms get retired and strand their fleets. Will this still verify in fifteen years, when my devices are still in the field?"
It's anchored in the things that don't retire. Public DNS, DNSSEC at the IANA root, registered address space, RDAP: the identity's anchors are internet infrastructure, not a product's console, and they're run by people who operated the internet's regional address registry and one of its root DNS servers. You can verify every claim on this page yourself, today, without an account.
Exercise all three planes yourself; our API isn't in the trust path.
Two tiers, by design. No key: verify a device's identity, the identity plane, trustless, anchored at the IANA root. Your key: back-trace a suspicious host across any cloud, register a device, govern its egress, revoke it worldwide.
# plane 1: re-derive and verify any device's identity, trustless
$ whisper verify --trustless 2a04:2a01:1c0::e51d
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA) leaf matches the identity's key
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
identity: VERIFIED, and our own API was never trusted
# the address is the device: reverse DNS names it
$ dig -x 2a04:2a01:1c0::e51d +short
sn-04d0c85f3a1b.fleet.example-maker.whisper.online.
# plane 2: with your key, attribute who really operates a host via the public graph API
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
-H 'content-type: application/json' -d '{"query":"CALL whisper.identify(\"34.90.x.x\")"}'
operator: <fingerprinted> · seen across AWS / GCP / Azure
residential swarm collapsed by JA4: same tooling, 41 exit IPs → 1 operator# plane 1: give a device a name it can prove
$ export WHISPER_API_KEY=whisper_live_xxx
# --serial/--from-secure-element are on the roadmap; today provisioning is the live control-plane call (see docs)
$ whisper register --serial 04D0C85F3A1B --from-secure-element
→ identity 2a04:2a01:1c0::e51d DNSSEC + DANE live
# plane 3: govern what it may reach, and read the per-device log
$ whisper policy set --default deny --allow ota.example-maker.com,telemetry.example-maker.com
$ whisper logs --identity 2a04:2a01:1c0::e51d --tail
$ whisper revoke 2a04:2a01:1c0::e51d # owner-thrown, publicly verifiable, at DNS-TTLThree planes, and all three exit into the stack you already run, not a new silo.
Feeds your SIEM, not another console
A machine-readable feed into your SIEM: the Splunk, Microsoft Sentinel and OpenCTI connectors ship today. Findings map to CEF and ECS fields and arrive as a signed, replayable JSON evidence chain, with STIX 2.1 over TAXII export on the roadmap.
Speaks your compliance language
Maps to EU CRA, IEC 62443, ETSI EN 303 645 / PSTI and 802.1AR evidence. Usable in your risk assessment and your certification file, not just a dashboard.
In your auth path, and safe there
If your backend authorizes against the DANE/verify path, that plane is built to fail open: a Whisper outage never bricks a device; checks degrade to your existing anchors. Anycast on AS219419, no single node in the path.
Flat, predictable pricing
Per-device/year and flat: not per-message, not per-MB, not usage-metered. A line item you can forecast at BOM time. See pricing →
On-prem or your own tenant
Data residency and GDPR by construction: the graph and the per-device logs stay where your regulator, and your customers, need them.
Where it fits vs. what you run
Depth on top of your device cloud and your SIEM: it makes them sharper, it doesn't replace them. See the comparison →
One primitive. Three planes. Give every device an identity it can prove.
Identity, an attribution graph that survives IP rotation, and per-device governance: additive to your stack, mapped to your standards, priced so you can say yes. Keyless to try, one call to provision, one more to revoke.
Or run whisper verify --trustless right now.