Every unit you've ever shipped authenticates with something that can be copied, and one of them is on a workbench right now.
The fielded base runs on the credentials manufacturing could afford: a default password, an API key in a config partition, one certificate for a whole product line, at best a per-device cert whose issuing CA lives in a vendor console. Every one of those is a string, and flash memory is not a vault. Dump one unit and you hold a genuine credential for the class; present it from a rotating cloud egress and the backend's last-IP log means nothing; and when the console anchoring the fleet's trust retires, the fleet's identity retires with it, in the field, mid-lifetime.
whisper verify --trustless · anchored at the IANA DNS root. Our own API is not in the trust path.
The impersonation that no perimeter, no anomaly model, and no last IP will ever catch.
It isn't a breach of your servers. Your device API is used exactly as it was built, by a caller who holds a genuine credential, because your own product handed it out a hundred thousand times.
“We can't rotate a secret that's soldered into a hundred thousand living rooms. We can't verify a device the way we verify a server, because the CA is the cloud vendor's and the CRL never reaches anyone. And when the impostor shows up with our own credential, our backend greets it like family.”
The credential left the building
Whatever manufacturing flashed, a password, a key, a fleet cert, exists in every unit sold, resold, and parted out. The attacker's supply chain is your sales channel.
Genuine bytes, wrong holder
The extracted credential is real, so it passes. One BOLA/IDOR flaw upgrades one device's session into any device's data. Behaviorally it's a device; cryptographically nobody ever asked.
The anchor has a shutdown date
Per-device X.509 into a vendor cloud is better, and still tenant-locked: only that cloud can verify it, revocation rides a CRL nobody fetches, and the whole scheme lives exactly as long as the console does. IoT Core's retirement in 2023 made that failure mode a matter of record.
Three generations of device credential, one shared flaw. Generation zero is the default password: banned outright now by ETSI EN 303 645 and the UK PSTI Act, a decade after Mirai demonstrated at 600k-device scale why. Generation one is the shared secret in firmware: an API key or a line-wide certificate, where one flash dump forges the fleet. Generation two is per-device X.509 enrolled into a cloud DPS: a real improvement, and still a credential only one tenant can verify, revoked through CRL/OCSP machinery that soft-fails, anchored to a console with a lifecycle shorter than the hardware's. All three share the flaw: the verifier trusts an artifact, never the silicon. The root cause has a name, OWASP broken authentication / BOLA: the credential authenticates a claim, never the device on the other end.
And it's invisible by design: a legitimate device is one address doing its narrow job; the impostor is one operator wearing a thousand copied faces, rotating egress across Amazon, Google, Azure and residential proxies so every IP you log is already stale. Fake telemetry poisons your data products; fake devices drain your API budgets; and a hijacked fleet becomes someone's botnet with your name on the label.
Stop detecting the impostor. Prove the device.
Detection will always be a step behind a credential that is genuinely valid. You can tune anomaly models forever and the impostor still looks exactly like a device, because, to your backend, it is one. The only strictly-stronger move is to change what the backend trusts.
A password, a key, a cert chain: whoever holds it can present it. That is the whole problem in one line: the credential does not prove which physical device is on the other end, so an extracted copy is indistinguishable from the original, and the source IP that might have narrowed it down is disposable.
Tomorrow · the backend authorizes a device that proves itself. Bind authority to a key the device holds in silicon and can demonstrate by signing, not an artifact anyone can copy. Now a request either proves it is the device it claims to be, or it has no authority at all, before a single detection rule runs. And because every device is one verifiable /128, "which device did this" stops being a forensic reconstruction and becomes a lookup.
That identity already has a home on the network you run: an address. Here is how the key already on your BOM becomes an address no one can forge.
The key already in the secure element becomes an address only that device can prove.
Whisper has one primitive: 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.
Point it at the device. The anchor is already on the board: an IEEE 802.1AR IDevID key in a Microchip ATECC608, an NXP EdgeLock SE050, an Infineon OPTIGA Trust M, or on-chip OTP/PUF key storage. Whisper derives the device's /128 from that key's public half, 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 the public key and the serial; and the device proves control by signing, the one operation a flash dump can never counterfeit. Your backend then authorizes on the device's pinned identity, not a copyable artifact: no bespoke CA trust store pushed to every unit, and revocation at DNS-TTL speed instead of a CRL distribution problem.
"One dump → a whole fleet" becomes physically impossible
You cannot present device-identities whose keys you don't hold. Every forgery is a DNSSEC/DANE inconsistency any verifier catches, keylessly.
IP rotation becomes irrelevant
Identity is not the source IP. The "last IP" was never the credential, so rotating it, across clouds or residential proxies, changes nothing.
Extracted firmware fails
The image never contained the key. A byte-perfect copy of everything on the flash, minus the secure element, authenticates to nothing.
Verifiable outside anyone's tenant
A partner, an auditor, a peer's backend, a researcher: anyone confirms the identity with dig and RDAP. No account in your cloud, no trust in ours.
"An extracted credential is byte-identical to the real device's; how do you tell them apart after auth?"
You bind authority to the silicon, not the string. The address derives from a key that never leaves the secure element, and the device proves control by signing against its DANE-EE pin. A session that presents copied bytes but can't sign never had authority in the first place. BOLA/IDOR loses its leverage: elevating to any account no longer reaches any device.
revoke that lands at TTL speed. The serial stays the public index, as it always was on the label; the /128 is its cryptographic counterpart, and serial alone yields nothing.Maps to the EU Cyber Resilience Act (secure-by-default and vulnerability handling for products with digital elements), ETSI EN 303 645 / the UK PSTI Act (the end of default passwords), IEC 62443 component identification, and IEEE 802.1AR. Know, attribute and revoke every device, delivered as a network primitive, not a compliance binder.
Identity stops the next impostor. The graph names whoever is already wearing your devices' faces.
You won't re-key every fielded unit by Monday, and there is impersonation in your logs right now. So the same platform back-traces the operator behind the credentials you already accepted: attribution that survives the rotation, because it fingerprints the operator and the tooling, not the ephemeral egress 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, fingerprints the operator, not the IP. For cloud rotation the graph clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy; for a residential-proxy swarm, a JA4/JA3 client fingerprint travels with the tooling regardless of the exit and collapses the swarm to one operator.
And it's a question, not a signature. Express fleet impersonation directly, "one source presenting N distinct device-identities in a window," as read-only Cypher, and the graph returns the operator with a reproducible evidence chain your SOC, your PSIRT, your auditors and a regulator can replay.
# ask the graph the business-logic question directly: read-only Cypher over 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":"MATCH (src)-[t:PRESENTED]->(d:DeviceIdentity)
WHERE t.window = \"15m\" WITH src, count(DISTINCT d) AS devices
WHERE devices > 50 RETURN src, devices ORDER BY devices DESC"}'
operator <fingerprinted> 1 source → 3,412 distinct device-identities / 15m
egress: AWS eu-central → GCP europe-w4 → Azure westeu (collapsed to 1)
ja4: same tooling across 41 residential exits → 1 operator
reproducible, replayable JSON evidence chain → your SIEM"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. The egress IP is the one thing we don't rely on, so the rotation that hides them from your SOC is exactly what the graph reads through.
Identity is the cure; the graph is how you clean up what got in before it, and catch the operator who tries anyway. Detection made durable, on top of a root-cause fix.
Additive to your stack. Mapped to your standards. Priced so you can say yes.
Your device cloud authenticates devices into itself; your SIEM correlates what it can see. Whisper adds the two layers neither owns: attribution across rotating infrastructure, and a device identity the whole internet can verify. It's depth on top of the stack you already run, not a console your analysts babysit.
| Cloud device auth | Whisper | |
|---|---|---|
| Authenticate devices into that vendor's cloud | ✓ | complements it |
| Attribute the operator across rotating clouds / residential proxies | – | ✓ |
| Identity any third party verifies + one-call revoke at DNS-TTL | – | ✓ |
Feeds your SIEM and PSIRT
The Splunk, Microsoft Sentinel and OpenCTI connectors ship today. Findings arrive as signed, replayable JSON mapped to CEF and ECS fields, with STIX 2.1 over TAXII export on the roadmap: evidence you can hand a regulator or a customer unchanged.
Speaks your compliance language
Maps to EU CRA secure-by-default and vulnerability-handling evidence, IEC 62443 identification controls, EN 303 645 / PSTI, and 802.1AR. Usable in your risk assessment and your certification file.
Safe in your auth path
Rides on top of the X.509 mTLS your device cloud already runs. The verify plane is built to fail open: a Whisper outage never bricks a device in the field; checks degrade to your existing anchors. Anycast on AS219419, no single node in the path.
Flat pricing, BOM-time certainty
Per-device/year and flat: not per-message, not per-MB, not metered during an incident. A number you can put in the unit economics before the product ships. 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.
Identity that outlives consoles
Anchored in public DNS and registered address space (AS219419), run by people who ran the internet's regional address registry and operated one of its root DNS servers. Your devices will outlive most platforms; their identity should too.
Don't take our word for it; our API isn't in the trust path.
Two tiers, by design. No key: anyone can verify a device's identity and resolve it, trustless, anchored at the IANA root. Your key: back-trace a suspicious host on the graph, register a device, govern its egress, revoke it worldwide.
# 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
# the address is the device: reverse DNS names it
$ dig -x 2a04:2a01:1c0::e51d +short
sn-04d0c85f3a1b.fleet.example-maker.whisper.online.
# who really operates a suspicious host: with your key, 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# give a device a name it can prove, and govern its egress
$ 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
$ whisper policy set --default deny --allow ota.example-maker.com,telemetry.example-maker.com
$ whisper revoke 2a04:2a01:1c0::e51d # owner-thrown, publicly verifiable, at DNS-TTLGive every device an identity it can prove.
The address is the device: routable, DNSSEC-anchored, derived from the key sealed in its secure element, revocable by the owner in one publicly verifiable call. The impersonation that no anomaly model ever caught simply runs out of forgeries.
Or run whisper verify --trustless right now.