Your device cloud, your PSIRT, your SIEM, and the extracted credential still speaks for your fleet.
It never breaks anything. It presents a credential your own factory flashed, so device auth sees a device; it rotates across Amazon, Google and Azure, so your SIEM correlates a meaningless last IP; and by the time PSIRT has an advisory, the poisoned telemetry is in your data products and the copied units are on the market. Two capabilities are missing from every connected-device program, and neither of them is a new console.
whisper verify --trustless · anchored at the IANA DNS root. Our own API is not in the trust path.
No layer of your program is wrong. The attack is engineered to fall in the seams between them.
You put a secure element on the BOM, stood up device auth in the cloud, ran a PSIRT, and route it all into the SIEM. Here is what each layer sees when a device-impersonation campaign runs, and why the fleet still gets worn like a mask.
A genuine credential, wrong holder
The extracted key or cert is real, so enrollment and auth say yes. Nothing anomalous fires until the impersonation is already at scale, because to the cloud the impostor is a device.
A last IP that means nothing
Egress hops Amazon → Google → Azure, or a residential-proxy swarm, every few requests. Each event carries a fresh source IP, so correlation across them yields a rotating fog, and a block on noise.
An advisory after the harvest
By the time the pattern is triaged, the poisoned telemetry is in your data products, the credential is republished, and the only fix on the table is the one you can't do: rotate a secret soldered into the field.
Two structural gaps live in that seam, and every connected-device program shares both. Close them and the attack has nowhere left to stand.
Strip the incident down and it isn't a hundred bugs. It's two.
Both are the kind a red-teamer names on sight, not a compliance checkbox. Here they are, and here's exactly how each closes.
Rate-limit an IP and they spin up a fresh one. The egress is disposable; the last IP was never the attacker. So you block noise while the operator keeps working.
The answer: the graph. 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. Every answer returns a reproducible evidence chain your SOC, your auditors and a regulator can replay.
"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, and every finding lands in your SIEM as a reproducible, replayable evidence chain, not a hunch.
A shared key or an extracted per-device cert is a valid credential. Behaviorally it's a device. Nothing at the perimeter separates the copy from the original, because they are byte-identical, and flash memory is not a vault.
The answer: identity. Bind the session to the device's own forge-proof /128: an address derived from the IDevID key already sealed in the secure element, one the device can prove by signing and no dump can extract. A copied credential without the chip behind it simply fails, and the failure is a first-class, loggable event your PSIRT can act on.
"An extracted credential is byte-identical to the real device's; how do you catch abuse that passes 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 a DANE-EE pin anyone can read from public DNS. A request that passes auth but can't sign never had authority in the first place.
Gap 1 is detection made durable. Gap 2 is the root cause. Both arrive where your analysts already work; read on for the wiring.
Three planes on one primitive, and all three exit into the stack you already run.
The primitive is one line: the address is the identity: a routable IPv6 /128 out of 2a04:2a01::/32 (announced by AS219419), DNSSEC-anchored, DANE-EE pinned, verifiable by anyone with dig. Point it at your fleet and you get three planes, no new silo.
Identity
Each device's /128 is derived from the 802.1AR IDevID key it already holds in its secure element, with the device serial or EUI-64 as the domain separator. The backend authorizes on the device's pinned identity, not a copyable artifact. Who is this, provably.
Attribution graph
The operator fingerprint across rotating clouds and residential proxies, infrastructure genealogy plus JA4/JA3, with a reproducible evidence chain on every answer. Who's really behind this, when the IP rotates.
Device governance
Every gateway and edge agent egresses from its own /128; every query and connection logged per-device; a graph-first resolver enforces default-deny policy per query; one revoke and a kill-switch. What may talk to what.
Findings arrive where your analysts already work, as evidence, not another alert to babysit.
Every attribution and identity finding is a reproducible, replayable JSON evidence chain. It fans out into your SIEM, into a form your peers can ingest, and into the artifacts your certification file needs, from the same object.
# STIX 2.1 sighting: one operator behind a rotating egress
{
"type": "sighting", "spec_version": "2.1",
"sighting_of_ref": "indicator--device-impersonation",
"count": 41, # 41 exit IPs → 1 operator
"x_whisper_operator": "<fingerprinted>",
"x_whisper_ja4": "t13d1516h2_8daaf6152771_…", # tooling, not exit
"x_whisper_scope": { "distinct_devices": 3412,
"window": "15m" },
"x_whisper_evidence": "https://verify… (signed, replayable)"
}
# the matching Microsoft Sentinel analytics rule: one line of KQL
# WhisperFindings | where OperatorConfidence > 0.9 | where DistinctDevices > 25The Splunk, Microsoft Sentinel and OpenCTI connectors ship today. Findings map cleanly onto CEF and ECS fields, with STIX 2.1 over TAXII export on the roadmap; a Splunk CIM mapping and a sample Sentinel analytics rule ship in the docs. For PSIRT, a finding is not a raw alert: it is an attributed operator plus a signed evidence chain your triage can act on, and hand to a regulator, or a customer whose fleet you run, unchanged.
And the raw material is already on your side of the wire: the per-/128 egress logs, every query and connection a device made, keyed to its own address, together with the attribution graph are ready-made continuous-monitoring and forensics evidence for the EU CRA's vulnerability-handling and incident-reporting duties, and the per-device record IEC 62443's identification controls presuppose. Continuous monitoring and post-incident forensics come out of the same signed object your SIEM already ingests, not a second collection you have to stand up.
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: the check degrades to the anchors you already ship, and connectivity is preserved. Conservative in what we emit, liberal in what we accept: a device is never denied because we were unreachable, and a fielded product doesn't wait for anyone's uptime.
Mapped to the EU CRA, IEC 62443, EN 303 645/PSTI and 802.1AR, as evidence you can file, not a dashboard you screenshot.
Every capability lands on a clause and produces an artifact. The timing matters: the EU Cyber Resilience Act entered into force in December 2024 and its main obligations apply from 11 December 2027, which is inside the design cycle of hardware you're speccing now. The program you evidence today is the CE-marking file you submit then.
| Capability | Framework / clause | Evidence artifact |
|---|---|---|
| Per-device identity from a hardware root of trust, no shared secrets shipped | EU CRA essential requirements (secure by default) · ETSI EN 303 645 §5.1 / UK PSTI (no universal default passwords) | Identity register · DANE-EE pin per device · verify transcript |
| Post-auth identity binding (the device co-signs) | IEC 62443-4-2 identification & authentication controls · IEEE 802.1AR | DANE-EE pin · signed verify evidence |
| Attributed operator across rotating infrastructure | EU CRA vulnerability-handling & incident-reporting duties | Signed, replayable evidence chain · STIX 2.1 sighting export (roadmap) |
| Per-device revocation at DNS-TTL, owner-thrown | EU CRA security-update & end-of-support handling · IEC 62443 lifecycle | Revoke log, publicly checkable in DNS |
| Per-device egress logs + default-deny policy | IEC 62443 network segmentation intent · NIST IR 8259A device-security baseline | Per-/128 query & connection logs · policy snapshots |
| For medical-adjacent devices: monitoring + SBOM-era postmarket duties | FDA §524B cyber-device requirements (premarket since Oct 2023) | Continuous-monitoring record · attributable device telemetry |
# ROADMAP: STIX 2.1 (JSON) export · the shape a finding will take
{
"framework": "stix-2.1",
"findings": [
{ "pattern": "device-impersonation",
"operator": "<fingerprinted>", "distinct_devices": 3412,
"evidence": "signed · replayable",
"cra_ref": "vulnerability handling / incident report",
"iec62443_ref": "identification & authentication control" }
]
}
# hand it to your peers and your sector ISAC unchanged: machine-readable, not a PDFUsable in your risk assessment and your certification file, and shareable in whatever cross-industry channel you already sit in. Note the honest labels: the connectors that ship today are Splunk, Sentinel and OpenCTI; STIX/TAXII is roadmap; and the per-platform device SDKs are phase-2 items, each labelled as such in the docs. See the full mapping in the docs →
On-prem or your own tenant, and a vendor whose own posture survives your review.
Data residency & sovereignty by construction
Run the graph and the per-device logs on-prem or in your own tenant, in the jurisdiction your regulator requires. Nothing about your fleet leaves where you put it; there is no shared multi-tenant lake your telemetry lands in by default.
No external dependency on the hot path
Resolution, identity verification and RDAP are answered by self-contained nodes: no chatty third-party call at serve time. If an upstream is slow or down, we fail open and keep serving. That's an availability property your assessors can test, not a promise.
A minimal, published attack surface
Standard ports, standard tooling (dig, kdig, curl), and a wire format that is strict in what it emits and liberal in what it accepts. The identity primitive is verifiable without trusting us: whisper verify --trustless anchors at the IANA root.
Real address space, operated as such
The identities live in production IPv6 (2a04:2a01::/32, AS219419) that we announce and run. This isn't a lab allocation: it's registry-anchored, RDAP-resolvable space, treated with the discipline that implies.
Priced so you can forecast it at BOM time, from infrastructure built to outlast consoles.
And the timing isn't yours to choose. The EU Cyber Resilience Act obliges every maker of products with digital elements to ship secure-by-default and handle vulnerabilities for the support period, with main obligations from 11 December 2027; EN 303 645 and the UK PSTI Act have already outlawed the default-password era. That is the procurement forcing function: the regulations make you prove device identity and control connectivity; Whisper is the layer that makes both a checkable network fact.
Flat, predictable pricing
Per-device per-year and flat: not per-message, not per-MB, not usage-metered. Against always-on telemetry economics that's a line item you can put in the unit economics before the product ships. See pricing →
ROI your CFO can read
Analyst-hours saved not correlating disposable IPs. Incident blast radius cut when a compromised device is one revoke, not a fleet-wide credential rotation you cannot physically perform. A recall-grade impersonation incident avoided is the whole year's budget.
Identity that outlives consoles
Devices live 10–20 years; consoles don't. Whisper anchors identity in public DNS and registered address space, run by people who ran the internet's regional address registry and operated one of its root DNS servers: built to outlast the question.
Feeds the SIEM you already run
Depth on top of the stack you own: a machine-readable feed that makes your SIEM and threat intel sharper. It doesn't replace them, and it doesn't add a console your analysts babysit. See the full comparison →
Spec it into your supply chain
Write Whisper identity into your module and ODM specifications so every sourced gateway and radio module ships identity-ready from the supplier: the secure element is already on the BOM; this is what it's for.
A procurement path with an off-ramp
Keyless POC today: verify and attribute with no account, no contract, no risk. Then a paid pilot on one product line, then enterprise across the fleet. Every stage is verifiable before the next, because our API is never in the trust path.
Don't take our word for it; our API isn't in the trust path.
Two tiers, by design. No key: anyone on your team can verify a device's identity, trustless, anchored at the IANA root. Your key: back-trace a suspicious host through the graph API, provision a device, govern its egress, feed the findings into your SIEM, and 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
# 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 operator# give a device a name it can prove, and wire the findings into your stack
$ 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 logs 2a04:2a01:1c0::e51d # per-/128 evidence for your SOC
# STIX/TAXII → your SIEM: on the roadmap; Splunk/Sentinel/OpenCTI ship today
$ whisper revoke 2a04:2a01:1c0::e51d # owner-thrown, publicly verifiableAdditive to your stack. Mapped to your standards. Priced so you can say yes.
Durable attribution and post-auth identity, fed into the SOC, PSIRT and SIEM you already run: on-prem, mapped to the EU CRA / IEC 62443 / EN 303 645 / 802.1AR, from infrastructure built to outlast the console era. Keyless to try, one call to provision, one more to revoke.
Or run whisper verify --trustless right now.