Your IoMT platform sees that a device is on the network — not who it provably is, and not whether it's really the same device across the HIE boundary.
Claroty, Armis, Ordr, Cynerio, Forescout, Asimily — each discovers your fleet and watches its behavior superbly, and you should keep every one. UDAP proves a FHIR endpoint inside a trust community. But a stolen static key, a rogue endpoint, and egress that rotates across clouds and organizations survive the whole stack, because they exploit two seams no single tool was built to close: publicly-verifiable identity that outlives a trust boundary, and attribution that outlives IP rotation across organizations.
device_id, DANE-pins the same UDAP endpoint cert, and feeds your SIEM. The address is the device — provable by anyone, forgeable by no one.
whisper verify --trustless — the one differentiator both categories lack: you never have to join a community, and you never have to trust our API.
Every tool here is good. The incident survives in the seams between them.
The healthcare incident — land on a flat, converged segment, harvest a hard-coded key or long-lived token (no machine identity, so the stolen secret is the device), pivot to a FHIR endpoint or an unmanaged IoMT device, exfiltrate through egress that rotates and reuse the loot at the next organization — 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.
An IoMT visibility platform has a vantage inside one organization — the hospital's own network, seen from the appliance or SaaS collector. When the operator behind a compromised endpoint rotates egress across clouds and residential proxies, or when the intrusion arrives through a business associate you don't monitor at all, the last IP was never the attacker and it stops at your firewall. With 41% of 2024 healthcare breaches beginning at a third party, that's not an edge case — it's the median. Known-indicator threat intel doesn't close it either: it matches what's already in a feed, and a just-spun cloud IP is, by definition, not yet in anyone's.
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, and its vantage is the public internet, not one hospital's edge. 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 OCR examiner, your cyber-insurer and a QHIN can replay.
A visibility platform infers identity from behavior — a genuinely useful signal, but it's observational, appliance-scoped, and evaporates the moment the device is off that network. UDAP does the real thing: it puts a cryptographic X.509 identity on a FHIR endpoint. But it's rooted in a private community anchor — you can only verify an endpoint if you were pre-provisioned with the same TEFCA or state-HIE trust anchor, cross-community trust needs federation, and revocation is CRL/OCSP inside that community. Outside it — a new relying party, a partner HIE, an auditor — there is nothing self-verifying at the address.
Only Whisper closes it — publicly. Bind the endpoint to a routable, forge-proof /128 derived from the key it already holds, publish a DANE-EE TLSA pin under a DNSSEC-signed name, and RDAP-register it. Now any relying party verifies the exact base-URL↔key binding UDAP asserts privately — against the IANA DNS root, with no community membership and no pre-provisioned anchor — and one revoke drops the pin worldwide at DNS-TTL. The /128 is tenant-bound: the same device model fielded at two HDOs derives two unrelated addresses, so the identity itself can never be used to link a device across organizations. Not a replacement for UDAP; the same identity, anchored where everyone can already check.
Gap 1 is detection made durable across rotation and across organizations. Gap 2 is identity taken public. No tool you already run was built to close either — that's the white space, and it's exactly the two gaps the device/endpoint attacks exploit.
An incident forces three questions. Your stack answers one and a half.
Line the categories up against the questions an incident actually forces you to answer, and the picture is honest and simple: discovery and behavior are well covered, endpoint identity is covered inside a community, and the two layers underneath — public verifiability and cross-org attribution — are the seams.
One category discovers your devices. The other proves your endpoints — privately. Whisper adds the public layer under both.
Healthcare security splits cleanly into two incumbent categories, and Whisper is additive to both. Naming exactly what each owns — and exactly where it stops — is the whole point.
A · IoMT visibility, asset-inventory & NAC — Medigate by Claroty, Armis, Ordr, Cynerio, Forescout, Asimily. These are excellent at what's on your network and whether it's behaving: passive, agentless discovery of unmanaged devices, deep MDS2/SBOM-aware profiling, clinically-aware anomaly detection, vulnerability prioritization, and segmentation policy pushed into your NAC (Cisco ISE and the like). That's necessary, you should run it, and it's where the picture stops — because its device identity is inferred from behavior, scoped to the appliance or SaaS vantage inside one organization, carries no device-held credential, and its "revoke" is a segmentation rule on its own box, not a change any other party can see. On their turf we're honest: an additive feed, not a second scanner — we consume their inventory (and the device's UDI) as the device_id we anchor.
"Claroty and Armis already tell me every device on my network and score its risk. What do I need you for?"
To turn 'we observed it' into 'we can prove it — anywhere.' Their inventory answers what is on my network, right now, from where I'm watching. Whisper gives each of those devices a forge-proof, publicly-verifiable /128 keyed to its UDI — a canonical inventory anchor that survives off-network, across the HIE boundary, and into an auditor's hands — plus attribution when the operator is a third party their vantage can't see, and a one-call revocation any relying party honors. We plug into Claroty, Armis, Ordr, Forescout; we don't replace them.
B · Endpoint & device identity — UDAP, SMART/OAuth trust communities, OEM device PKIs. This category does the real cryptographic thing. UDAP (the HL7 FAST Security IG / SSRAA) puts an X.509 identity on a FHIR endpoint and binds the FHIR base URL to a uniformResourceIdentifier in the server cert's SAN; SMART on FHIR Backend Services authenticate the calling app with an asymmetric key; OEM device-PKI programs provision genuinely cryptographic identities at the factory. All good, all real — and all rooted in a private trust boundary: a community anchor (TEFCA, a state HIE) you must be federated into, or the manufacturer's own PKI. None publishes a binding that a relying party outside that boundary can verify against public DNS, and none revokes at DNS-TTL. Whisper doesn't compete with any of them — it anchors the same identity publicly: DANE-pin the very cert UDAP already asserts, so the private assertion becomes an internet-grade one any party can check without joining.
"UDAP already gives our FHIR endpoints cryptographic identity. Isn't that enough?"
Inside your community, yes. Outside it, there's nothing self-verifying at the address. UDAP asserts the base-URL↔key binding, but the trust is a top-down community CA — a partner who isn't federated with your anchor can't verify it, and revocation is CRL/OCSP inside the anchor. Whisper publishes the same binding as a DANE-EE TLSA record under a DNSSEC-signed name on the endpoint's routable /128. Any relying party — even one you've never met — verifies it against the IANA root, and dropping the record revokes it publicly at DNS-TTL. It's your UDAP identity, taken public. Additive, not a fork.
The incumbents own the top rows. Whisper owns the bottom. One row is shared — by different means.
Read it top to bottom and the division of labor is unambiguous. Discovery, anomaly detection and community-scoped endpoint trust belong to the tools you already run; publicly-verifiable identity, cross-org attribution and DNS-TTL revocation belong to Whisper. Endpoint-identity issuance is the one shared row — UDAP does it privately, Whisper does it publicly, and the honest answer is both, together.
| Capability | IoMT inventory / NAC | UDAP / private trust community | Whisper |
|---|---|---|---|
Medical-device discovery & asset inventory (MDS2) | ✓ | — | additive feed · consumes inventory / UDI as device_id |
| Clinical anomaly & threat detection | ✓ | — | — |
| Endpoint / device identity issuance | — | ✓ private / community-rooted | ✓ public DNSSEC + DANE |
| Publicly-verifiable identity — no trust-community membership | — | — | ✓ |
Cross-organization attribution across rotating egress (JA4/JA3) | — | — | ✓ |
| Cross-community revocation at DNS-TTL | — | — | ✓ |
Routable identity that survives NAT & HIE boundaries | — | — | ✓ |
| Identity from the endpoint's existing key — no re-key, no new appliance | — | — | ✓ |
Two clarifications keep it honest. The visibility platforms don't issue identity, but they do the two things Whisper deliberately doesn't — clinically-aware anomaly detection and deep vulnerability/MDS2 profiling; that's their row, and we feed it, we don't contest it. And UDAP's identity row is a real ✓ — it just lives behind a community anchor. The value isn't "Whisper instead of UDAP," it's "your UDAP endpoint, verifiable by anyone." One cert, two anchors: the community CA your partners already trust, and the public DNSSEC/DANE anchor for everyone who isn't in your community yet.
And the identity you can prove is also one you can watch and govern. Because every device's name resolves through Whisper's own authoritative DNS and RDAP, op:lookups tells the owner who resolved or queried a device's identity — an early tripwire for someone enumerating your fleet ahead of an attack, and a verification-analytics stream for who's checking your endpoints across the exchange. Every mint and every revoke lands in a public, append-only Merkle transparency log, Ed25519-signed and Bitcoin-anchored via OpenTimestamps — nothing issued in the dark. Honest status: it's tamper-evident and signed today; independent external witnessing (it already speaks the C2SP tlog-witness protocol) is the next step. And egress governance — op:firewall, op:budget, op:policy, op:revoke — enforces default-deny per device at L3, so a device that can't take a NAC agent still gets a governed /128 that reaches only its EHR and its OTA endpoint.
Additive, top to bottom: a feed into the inventory you already run, a public anchor for the trust community you already run, and the two seams closed underneath both.
Every inventory and every community asks you to trust it. Ours, you don't have to.
Your IoMT console asks you to trust its verdict; UDAP asks you to trust a community anchor. Whisper's core claim — this address is that device / endpoint — is checkable by anyone, against the IANA DNS root, with our own API deliberately outside the trust path. No account, no community membership required.
# keyless — re-derive and verify any device / FHIR endpoint, trustless
$ whisper verify --trustless 2a04:2a01:d1::b12
✓ DNSSEC chain valid to the IANA root
✓ DANE-EE (TLSA 3 1 1) leaf matches the UDAP endpoint cert
✓ RDAP: registered under AS219419 · 2a04:2a01::/32
identity: VERIFIED — no community anchor, our API never trusted
# the address is the endpoint — reverse DNS names it
$ dig -x 2a04:2a01:d1::b12 +short
fhir-r4.endpoint.example-hdo.whisper.online.
# who really operates a suspicious third-party host — the public graph API, a CALL whisper.identify()
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: whisper_live_xxx" \
--data-urlencode "q=CALL whisper.identify('34.90.x.x')"
operator: <fingerprinted> · seen across AWS / GCP / Azure · JA4 collapses 41 exits → 1# publicly anchor a FHIR endpoint you already run under UDAP
$ export WHISPER_API_KEY=whisper_live_xxx
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" --data-urlencode "q=CALL whisper.agents({op:'connect', args:{tier:'wireguard',
identity_public_key:'<base64 SPKI of the endpoint key>',
device_id:'https://fhir.example-hdo.org/r4'}})" # device_id = FHIR Endpoint.identifier
→ identity 2a04:2a01:d1::b12 DNSSEC + DANE-EE live · logged to the transparency log
# govern what a device may reach — default-deny at L3, even if it can't take a NAC agent
$ whisper policy set --default deny --allow ehr.example-hdo.org,ota.vendor.example
# see who's been resolving / RDAP-querying this endpoint — a recon tripwire (owner-scoped, keyed)
$ curl -s https://graph.whisper.security/api/query -H "X-API-Key: $WHISPER_API_KEY" \
--data-urlencode "q=CALL whisper.agents({op:'lookups', args:{ip:'2a04:2a01:d1::b12'}})"
14 RDAP + TLSA lookups in 24h from 2 orgs — 1 not in your HIE
# contain a compromised device — one call, worldwide, no re-imaging / truck-roll
$ whisper kill --revoke 2a04:2a01:d1::b12 # PTR + DANE gone at DNS-TTLWhisper is one layer, done well. It sits beside these — not over them.
Plenty of good vendors live inside the device, on the clinical bus, or in the compliance binder. That's a different lane, and we don't claim it. Naming the boundary is the point: it's how you know exactly what you're buying — an identity, attribution and reachability control, complementary to segmentation, device patching, and the protocol-level auth of legacy clinical traffic.
Clinical-protocol DPI & anomaly detection
Deep inspection of HL7v2, DICOM and proprietary clinical protocols on the LAN, and the behavioral models that flag a misbehaving pump or PACS. That's the IoMT visibility platforms' lane and it runs below us — Whisper anchors at the IP/DNS/transport boundary, never on the clinical bus. Two same-segment nodes speaking unauthenticated DICOM is a segmentation and protocol-auth problem, not ours; we govern who can reach the segment and attribute who did.
SBOM, vuln management & §524B paperwork
Machine-readable SBOM generation, CVE/MDS2 vulnerability prioritization, secure-boot, and the FDA §524B / EU MDR type-approval submission itself. That's the build and the binder. Whisper is runtime identity and live attribution — it produces evidence for that process (a stable per-device ID, a one-call containment demo, a live network map), it isn't that process, and it doesn't provide the SBOM.
Managed SOC services & SIEM apps
People and playbooks around the SOC, and the Splunk apps that structure it. Whisper is a feed those services consume — the Splunk connector (signed JSON → CEF/ECS) ships today; STIX 2.1 over TAXII is on the roadmap — sharpening the analysts, not replacing the desk they sit at.
We don't do clinical-protocol DPI, SBOMs, or type-approval paperwork, and we don't pretend to. Whisper is the network-identity and attribution layer — the one thing on this page that closes both device/endpoint seams — and it's honest about being exactly that.
No new silo. Mapped to your standards. Availability-safe by construction.
The additive posture isn't just tidy architecture — it's what makes the buy defensible to a hospital board and a PSIRT alike. Nothing you already run gets torn out; one line item closes two gaps and feeds everything else.
A feed, not another console
The Splunk connector ships today; findings map to CEF and ECS. Microsoft Sentinel, OpenCTI and STIX 2.1 over TAXII are on the roadmap. Zero analysts babysitting a new pane of glass — it lands in the inventory and SIEM you already staff.
Speaks your compliance language
Direct evidence for the HIPAA Security Rule NPRM's hardest asks — a UDI-keyed asset inventory, a live network map, and L3 segmentation — plus entity authentication and an egress audit trail (§164.312(a)/(b)/(d)). Supports FDA §524B(b)(1)/(2) authentication and postmarket containment, and EU MDR Annex I §17.4. See the compliance map →
Flat, forecastable TCO
Per-device, per-year and flat — not per-transaction, not usage-metered. ROI in analyst-hours saved correlating disposable IPs, and one revoke instead of re-imaging a device or rolling a truck. See pricing →
On-prem or your own tenant
ePHI residency and GDPR by construction — the graph and the per-device logs stay where your regulator needs them. The identity plane is built to fail open: a Whisper outage never bricks a device; checks degrade to your existing anchors, and no node sits inline on clinical traffic.
Anchors the identity you already issue
Derived from the key already in the device or endpoint — no second PKI, no re-flashing the fielded fleet, no new appliance on the network. DANE-pin an OEM device-PKI leaf or your UDAP endpoint cert; it's one verifiable /128 the operating hospital and a partner HIE can both check.
A vendor built to outlast the question
Real routable address space (AS219419), run by people who ran the internet's regional address registry and operated one of its root DNS servers. Keyless to prove today, POC → pilot → enterprise on real address space — the claim is checkable before the contract.
"Will you still be here in five years — and is my patients' data yours?"
Real address space, your tenant, your call. AS219419 and founders who operated core internet registries and DNS aren't a burn-rate story. The graph and logs run on-prem or in your own tenant for ePHI residency, the identity plane fails open so our uptime never gates a device, and the trustless verify path means you 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 publicly-verifiable identity and cross-org attribution layer that sits on top of the IoMT inventory and UDAP trust community you already run — additive, mapped to your standards, flat to price. Keyless to try, one call to anchor, one more to revoke.
Or run whisper verify --trustless right now — no community, no account, our API isn't in the trust path.