Your device stack authenticates credentials into one cloud: not devices, and not to anyone else.
Azure IoT DPS, AWS IoT fleet provisioning, Matter's DAC, SPIFFE/SPIRE, the secure-element vendors: each is good at what it does, and you should keep running the ones you have. But device impersonation survives the whole stack, because it exploits two seams no single tool was built to close: attribution that outlives IP rotation, and identity that outlives an extracted credential, and the console that issued it.
whisper verify --trustless · the one differentiator every tool here lacks: you never have to trust our API.
Every tool here is good. The incident survives in the seams between them.
The device-impersonation attack: extract a credential from one unit, present it at fleet scale, rotate egress across clouds and residential proxies. It passes every perimeter check on purpose. Strip it down and it leans on exactly two structural gaps. Here's which category of tool leaves each one open, and why.
Rate-limit an IP and they spin up a fresh one. Your backend sees only the ephemeral last IP, and it was never the attacker. Curated threat intel doesn't close this either: known-indicator feeds match what's already known, but a just-spun cloud IP and a residential-proxy swarm are, by definition, not yet in anyone's feed.
Only Whisper closes it: the graph. A live internet-infrastructure graph, 7.44B nodes and 39.3B relationships of fused BGP, DNS, WHOIS, TLS, hosting and threat intel, answering in under 300 ms, fingerprints the operator, not the IP. Cloud rotation collapses into one infrastructure genealogy (shared ASN, hosting, certificate lineage); a residential swarm collapses on a JA4/JA3 client fingerprint that travels with the tooling regardless of the exit. Every answer is a reproducible evidence chain your auditors and a regulator can replay.
Cloud device auth verifies an artifact: a key, a cert chain. Extract it from one unit's flash and the copy is byte-identical to the original; no enrollment service, and no threat-intel feed, tells a real device from an impostor presenting genuine bytes. And revocation, when you finally need it, rides CRL/OCSP machinery most verifiers silently soft-fail past.
Only Whisper closes it: identity. Bind the session to the device's own forge-proof /128, derived from the IDevID key sealed in its secure element. The device proves control by signing, checked against a public DANE-EE pin, so copied bytes without the chip never had authority. Not detected late; structurally impossible.
Gap 1 is detection made durable across rotation. Gap 2 is the root cause removed. No tool you already run was built to close either: that's the white space, and it's exactly the two gaps device-impersonation attacks exploit.
The attacker asks three questions. Your stack answers only the first.
Line the categories up against the questions an incident actually forces you to answer, and the picture is honest and simple: enrollment into one cloud is well covered, and the two layers underneath it are the seams.
Cloud DPS enrolls devices into one cloud, brilliantly. Whisper makes them verifiable to everyone, and revocable at TTL speed.
Azure IoT Hub Device Provisioning Service and AWS IoT's fleet provisioning with JITP/JITR are the state of the art for X.509 device enrollment at manufacturing scale, and if your backend lives in one of those clouds you should use them. That's the honest starting point, and it's also where the picture stops: the identity they establish is tenant-scoped. Only that cloud can verify it, revocation is that cloud's registry plus CRL/OCSP semantics, and the identity's lifetime is bounded by the service's, a bound that stopped being hypothetical when Google Cloud IoT Core retired in August 2023.
Whisper adds the layers a cloud enrollment can't reach: an identity any third party verifies keylessly with dig, RDAP and DANE; revocation at DNS-TTL speed that verifiers can't soft-fail past; a routable /128 that is itself the network endpoint, with governed, attributable egress; and anchors (public DNS, DNSSEC, registered address space) that outlive any console. On the enrollment job itself we're honest: we're an additive layer, not a second DPS.
| Capability | Azure DPS / AWS IoT | Whisper |
|---|---|---|
| X.509 enrollment into that vendor's cloud at manufacturing scale | ✓ | complements it |
| Identity a third party verifies without a tenant account (dig / RDAP / DANE) | – | ✓ |
| Revocation at DNS-TTL, worldwide, no CRL/OCSP soft-fail | – | ✓ |
| The identity is a routable network endpoint (the /128) with WireGuard egress | – | ✓ |
Attribute an operator across Amazon → Google → Azure rotation (JA4/JA3) | – | ✓ |
| Identity survives the platform being retired | – | ✓ public DNS + registered space |
| Owner-controlled, publicly verifiable revocation (never a silent registry flag) | – | ✓ |
| Trustless verification: no need to trust the vendor's API | – | ✓ |
| Deploys as | cloud service, in-tenant | additive layer · on-prem / own-tenant |
| Pricing model | per-message / per-operation metering | flat, per-device / year |
"DPS already gives every device a unique X.509 identity. What do I need you for?"
For everyone who isn't your cloud. The DPS identity authenticates the device to one tenant. Your partners, your customers' auditors, a peer's backend, a researcher who found your device in a botnet: none of them can check it. The Whisper /128 is the same device's public identity, verifiable by all of those with stock tools, revocable by you at TTL speed, and independent of any console's lifespan. Run both: enrollment stays exactly where it is.
Matter attests provenance. SPIFFE names workloads. Secure elements hold the key. Whisper is the layer that joins them to the public internet.
None of these is a competitor to replace; each solves an adjacent problem well, and the grid says exactly where the seams are.
| Capability | Matter DAC / DCL | SPIFFE / SPIRE | TPM / secure elements | Whisper |
|---|---|---|---|---|
| Device provenance attestation at commissioning | ✓ in-fabric | – | the root it rests on | complements it |
| Workload identity inside your own clusters | – | ✓ | – | complements it |
| Holds the device key in hardware | uses one | – | ✓ their whole job | derives from it |
| Operational identity a third party verifies on the public internet, keyless | – | trust-domain-scoped | – | ✓ |
| Revocation at DNS-TTL, worldwide | DCL updates | in-mesh only | – | ✓ |
| The identity is a routable address with governed egress | – | – | – | ✓ |
Live attribution across rotating clouds + residential (JA4/JA3) | – | – | – | ✓ |
Read the rows as a division of labor. Matter's DAC and the CSA's Distributed Compliance Ledger answer "was this device made by whom it claims" at commissioning, inside the Matter fabric; Whisper answers "is this network endpoint that device" for the rest of its life, to anyone on the internet. SPIFFE/SPIRE is excellent workload identity inside a trust domain you operate; a fielded device on someone's home network is exactly what a trust domain isn't. And the secure-element vendors are not adjacent at all: they're the foundation. The ATECC608s, SE050s and OPTIGAs on your BOM hold the key Whisper's derivation starts from; we're the reason that chip earns its place on the BOM cost sheet.
Every tool here, you must trust. Ours, you don't have to.
Every registry and console on this page asks you to trust its verdict. Whisper's core claim, this address is that device, is checkable by anyone, against the IANA DNS root, with our own API deliberately outside the trust path. No account required. For a fleet you'll still be supporting in fifteen years, that's not a feature; it's the design requirement.
# keyless: 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
# who really operates a suspicious host: the public graph API, with your key
$ 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 operatorWhisper is one layer, done well. Here's the boundary, and the fine print, in our own words.
Plenty of good vendors live in the silicon, the RTOS, or the compliance binder. That's a different lane, and we don't claim it. And our own layer has real preconditions; naming them is how you know exactly what you're buying.
Silicon & firmware security
Secure boot, measured boot, TrustZone partitioning, glitch and side-channel hardening, RTOS memory protection. That's the die and the firmware; Whisper is the wire. Fully complementary: it runs below us, and we never touch it.
SBOM & compliance automation
Software bill-of-materials, vulnerability management, and the CRA process paperwork as it lands. That's the binder and the build. Whisper is runtime identity and live attribution: it produces evidence for that process, it isn't that process.
The device cloud itself
Telemetry ingestion, device twins, OTA orchestration, the data plane. Whisper doesn't store your telemetry and doesn't move your firmware: it anchors the identities on each side so the platform's own logic runs against a network fact, not a copyable secret.
No new silo. Mapped to your standards. Priced so you can say yes.
The additive posture isn't just tidy architecture: it's what makes the buy defensible. Nothing you already run gets torn out; one line item closes two gaps and feeds everything else.
A feed, not another console
The Splunk, Microsoft Sentinel and OpenCTI connectors ship today. Findings map to CEF and ECS, with STIX 2.1 over TAXII export on the roadmap. Zero analysts babysitting a new pane of glass.
Speaks your compliance language
Maps to EU CRA, IEC 62443, EN 303 645 / PSTI and 802.1AR evidence. Usable in your risk assessment and certification file.
Flat, forecastable TCO
Per-device, per-year and flat: not per-message, not usage-metered, not a meter that spikes mid-incident. A number you can put in unit economics at BOM time. See pricing →
On-prem or your own tenant
Data residency and sovereignty by construction: the graph and the per-device logs stay where your regulator, and your customers, need them. The identity plane is built to fail open: a Whisper outage never bricks a device.
Built to outlast consoles
Real routable address space (AS219419), public DNS, open standards, run by people who ran the internet's regional address registry and operated one of its root DNS servers. The IoT-platform graveyard is real; this is anchored below it.
Keyless to prove, one call to adopt
Nothing about the decision is a leap of faith: run whisper verify --trustless today with no account, then POC → pilot → enterprise on real address space. The claim is checkable before the contract.
"Will this still verify in fifteen years, and is my fleet's data yours?"
Public anchors, your tenant, your call. The identity's anchors are DNSSEC at the IANA root, RDAP, and registered address space: internet infrastructure, not a product with a sunset blog post. We hold no device telemetry: the graph and logs run on-prem or in your own tenant, the identity plane fails open so our uptime never gates a device, and the trustless verify path means you, or anyone, can audit the core claim without trusting us at all. Additive also means low switching cost in both directions: the safest way to start.
Keep your stack. Close the two gaps.
Whisper is the attribution and identity layer that sits on top of the device cloud and SIEM you already run: additive, mapped to your standards, flat to price. Keyless to try, one call to provision, one more to revoke.
Or run whisper verify --trustless right now: our API isn't in the trust path.