# Compare — additive to your IoMT inventory, additive to your UDAP trust community > 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; UDAP proves a FHIR endpoint inside a trust community. Whisper is the two > layers neither owns — publicly-verifiable identity, and cross-org attribution — and it feeds > your stack rather than replacing it. 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**. Whisper is those two layers — and only those. Additive, never a replacement: it consumes your inventory as `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. - **2 seams** — the two gaps every device/endpoint attack walks through — both closed here - **0** — rip-and-replace; Whisper sits on top of your IoMT inventory and your UDAP trust community - **Splunk & Microsoft Sentinel today** — a signed-JSON feed to your SIEM (CEF · ECS) - **41%** — of 2024 healthcare breaches began with a third party — the cross-org seam no inventory tool can see - **trustless** — verify a device's identity without joining any trust community - **signed & logged** — every mint & revoke in a public, Bitcoin-anchored transparency log — nothing issued in the dark --- ## 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. ### Gap 1 · you can't follow them when the IP rotates — or when it's a third party 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. ### Gap 2 · identity that stops at the trust boundary 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. ``` ① Is a device / FHIR endpoint ──▶ covered — IoMT visibility / NAC (inventory + MDS2 + anomaly, in one org) misbehaving? ② Who's really behind it — across ──▶ GAP 1 — known-indicator TI matches only what's already known orgs and rotation? ③ Is this really the device — ──▶ GAP 2 — UDAP proves it only inside a private community publicly, outside the community? Whisper spans ② + ③ and feeds ① operator fingerprint · JA4 · DANE-EE /128 · public verify evidence chain → your SIEM (Splunk today · CEF · ECS) ``` Additive by construction: Whisper owns the two layers no one else does, and hands the first layer a sharper feed. Keep your IoMT inventory and your UDAP trust community — Whisper closes what they can't reach. --- ## One category discovers your devices. The other proves your endpoints — privately. 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. ``` UDAP endpoint cert ──DANE-pin the same cert──▶ /128 · DNSSEC + DANE-EE ──▶ Any relying party SAN URI = FHIR base URL 2a04:2a01:d1::b12 whisper verify --trustless rooted in a private TLSA 3 1 1 → the same key no community membership community anchor (TEFCA/HIE) signed to the IANA root no pre-provisioned anchor verifiable only if federated RDAP-registered · AS219419 our API not in the trust path │ └── op:revoke → pin gone worldwide at DNS-TTL ``` Whisper doesn't fork UDAP — it takes UDAP's private base-URL↔key assertion and re-anchors the identical cert in public DNSSEC/DANE, so a partner outside your trust community can verify it, and you can revoke it at DNS-TTL — the second, orthogonal kill-switch the community CA never gave you. --- ## 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](/docs/health-compliance), 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. ```sh # 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: · seen across AWS / GCP / Azure · JA4 collapses 41 exits → 1 ``` ```sh # 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:'', 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-TTL ``` --- ## Whisper 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, Microsoft Sentinel and OpenCTI connectors ship today; findings map to CEF and ECS. **STIX 2.1 over TAXII** is 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 →](/for-hdos) - **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 →](/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. Secure your devices → · [For HDOs →](/for-hdos) Or run `whisper verify --trustless` right now — no community, no account, our API isn't in the trust path. --- *Whisper for Health · Identity on the wire for connected medical devices and FHIR endpoints · AS219419 · 2a04:2a01::/32* *© viaGraph B.V. (dba Whisper Security)*