# Whisper for Health — give every medical device and FHIR endpoint an identity it can prove > A connected medical device — and the FHIR endpoint in front of it — cannot prove who it is. > The address **is** the device — a routable, DNSSEC-anchored /128 bound to the > `Endpoint.identifier` (or the FDA `UDI`) it already carries, publicly verifiable across > the HDO / vendor / HIE boundary, revocable at DNS-TTL. Additive to your IoMT visibility, > your UDAP endpoint trust, and your SIEM. A valid-looking API caller, or a device sitting on the clinical network, is trusted because it's *reachable* — not because it authenticated. The FHIR base-URL↔certificate binding UDAP asserts lives inside a *private* trust community, invisible to anyone outside it. And a 10-to-20-year device runs an OS that stopped getting patches years ago, on a flat clinical VLAN. It works for one reason: your devices and endpoints have no identity they can prove. **We give them one.** `whisper verify --trustless` — anchored at the IANA DNS root. Our own API is not in the trust path. - **14 yrs** — healthcare the costliest industry to breach; **$7.42M** avg US breach (2025), ~279 days to detect & contain (IBM) - **~133M** — Americans' health records exposed in 2023, a single-year record (HHS OCR) - **+35–41%** — in-hospital mortality for patients already admitted when a ransomware attack hits (U Minnesota, Medicare claims) - **75%** — of ~200k infusion pumps carried a known security gap; 52% exposed to two critical/high CVEs (Unit 42) - **53%** — of connected medical/IoT devices carry a known critical vuln, a third of them bedside (Cynerio, 300+ hospitals) - **~60%** — of health systems say they can't protect unpatchable / agentless devices (HIMSS) --- ## The attack, step by step **This is how patient data leaves — and a pump gets steered — by a caller no clinician ever trusted.** No zero-day required. Just static trust and a flat clinical network used exactly as built — at fleet scale. 1. **RECON** — Internet-exposed FHIR servers, a stale VPN, and thousands of open DICOM/PACS ports answering without AE-Title validation are enumerable from the open internet. 2. **CREDENTIAL** — A default or weak credential, a hardcoded key, a long-lived token, or an over-broad SMART-on-FHIR scope. With no machine identity behind it, a stolen secret *is* the device. 3. **LAND** — Land on the flat, converged clinical VLAN. HL7v2 feeds, unauthenticated DICOM, and proprietary device protocols assume anything on the LAN is trusted. 4. **IMPERSONATE** — A pump, monitor, or PACS authenticates a *claim*, not a machine; an EOL OS gives a foothold. Present the claim and you are the device. 5. **EXFIL / STEER** — A FHIR BOLA (increment the patient id) or an unauthenticated DICOM C-STORE scrapes records at scale; the same trust lets an attacker steer an infusion or imaging device. 6. **ROTATE** — Egress hops across clouds and residential proxies — the SOC sees a fresh last IP and correlates nothing — and a credential burned at one HDO is reused against the next. Invisible at the network layer by design: a real integration is *one endpoint the org owns*; the abuser is *one caller trusted only by reachability* — and every IP it ever shows you is disposable. This is not hypothetical: internet scans repeatedly find thousands of open DICOM servers exposing well over a billion medical images, and a single third-party clearinghouse compromise cascaded to roughly a third of all US health records — concentration risk, at class level. --- ## Strip the incident down and it isn't a hundred bugs. It's two. Every step in that chain leans on exactly two structural gaps that every healthcare and device program shares. Close both and the attack has nowhere left to stand. ### Gap 1 · you can't name them when the egress rotates Rate-limit an IP and they spin up a fresh one. The egress is disposable; the last IP *was never the caller*. So you block noise while the operator keeps scraping — and because a large and growing share of healthcare breaches now begin with a *third-party* vendor, the caller that matters usually isn't even on your network. **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. Two levers, kept honestly separate: - **Cloud rotation** — the graph clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy. - **Residential-proxy swarm** — where a subscriber IP gives an infra graph nothing to grab, a `JA4/JA3` client fingerprint travels with the *tooling*, invisible to your API gateway because it lives in the TLS handshake, and collapses the swarm to one operator. Every answer returns a reproducible **evidence chain** your SOC, your auditors and OCR can replay. The verbs: `identify(ip)`, `origins(prefix)` + `walk(node,depth)`, `history` / `watch`, and arbitrary read-only Cypher ("one source touching N distinct device / endpoint identities across two organizations in a window"). > **"When a scraper hits our FHIR API through rotating residential proxies and fresh cloud IPs, can you actually name the operator — or just rate-limit an IP and move on?"** > Name it. Infrastructure genealogy collapses the cloud rotation; a JA4 client fingerprint > collapses the residential swarm — invisible to your API gateway because it lives in the TLS > handshake, not the payload. The egress IP is the one thing we don't rely on, and the finding > feeds straight into your SIEM. ### Gap 2 · a valid-looking caller looks exactly like a trusted integration A minted or reused bearer token, a shared credential, or an over-broad SMART scope *is* a valid credential. Behaviorally it's the integration. Nothing at the perimeter separates it, because the endpoint on the other side has no identity to check it against — and the FHIR base-URL↔certificate binding that would prove it lives inside a private trust community you may not even belong to. **The answer — identity.** Bind the exchange to the endpoint's own forge-proof **/128** — an address derived from the key behind the **FHIR Endpoint.identifier** or the **FDA UDI** it already carries — and publish the base-URL↔certificate binding in **DNSSEC/DANE** so any relying party can verify it, even across the community boundary UDAP can't reach. A caller that can't prove the target endpoint's identity simply *fails*. > **"UDAP already gives our FHIR endpoints X.509 identity. Why isn't that enough?"** > Because it's verifiable only inside your trust community, and revoked only by a community > CRL/OCSP. UDAP's rule is exact and good — the identifying URI SHALL equal the server's > `{baseURL}` and match a `uniformResourceIdentifier` in the certificate SAN — but that binding > is rooted in a *private* community anchor (a TEFCA or state-HIE CA), so a relying party outside > it has nothing to check, and nothing anchors it in DNS. DANE (RFC 6698 TLSA) + DNSSEC publish > *exactly* that binding, publicly rooted at the IANA root — any party verifies without joining, > and one dropped TLSA revokes it at DNS-TTL. Gap 1 is detection made durable and cross-organization. Gap 2 is the root cause. Here's the root-cause cure. --- ## The root-cause cure · identity **Give every device and endpoint an identity it can prove — and no one can forge.** Stop treating endpoint spoofing and data scrape as a detection problem and make it an *identity* problem — strictly stronger. 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`. `whisper verify --trustless` checks it against the IANA root; *our own API is not in the trust path.* **Point it at devices and endpoints.** Derive each FHIR endpoint's — or each infusion pump's, monitor's or PACS node's — /128 from the public key behind the identifier it *already* carries: the **FHIR Endpoint.identifier** and its UDAP server certificate, the **FDA UDI** (the Device Identifier in GUDID), a DICOM AE-Title's PS3.15 TLS cert, an ISO/IEEE 11073 `EUI-64`, or a TPM/secure element — with the **Endpoint.identifier or UDI as the domain separator**. The private key never leaves the device; the address is a one-way function of its public half and that identifier. No re-flashing the fielded fleet — you bind the identity it was born with. **Shipped & live:** pass your `Endpoint.identifier` or `UDI` as `device_id` today; a first-class typed `--udi` argument is on the roadmap. ``` endpoint / device key ──pubkey + device_id──▶ /128 ──DNSSEC+DANE-EE──▶ a name anyone can verify (Endpoint.identifier · UDI · 2a04:2a01:f0::fda whisper verify --trustless 11073 EUI-64, key sealed, routable identity our API not in the trust path never leaves the device) op:revoke → gone at DNS-TTL ``` **Turn UDAP's private binding into a public one.** A FHIR `Endpoint.address` is a `url`-typed base address — DNS-addressable by construction — and UDAP already says that base URL SHALL equal the server's `{baseURL}` and match a `uniformResourceIdentifier` in the certificate SAN. But that binding is only checkable inside the community you were configured with. DANE + DNSSEC publish the identical binding at the IANA root, so a relying party *outside* the community verifies it with nothing pre-provisioned. Complements the community CA; never replaces it. ``` UDAP endpoint trust DNSSEC + DANE TLSA Any relying party (baseURL == cert SAN URI, ──▶ (3 1 1 pin of the same ──▶ verifies — no anchor, anchored in a community CA: cert; the base-URL↔cert no community membership. TEFCA / state-HIE — binding, publicly rooted drop TLSA → revoked, publicly. outsiders can't check it) at the IANA DNS root) ``` What becomes true the moment you do this: - **"One caller → a whole directory" becomes impossible.** Every forgery is a DNSSEC/DANE inconsistency any verifier catches. - **IP rotation becomes irrelevant.** Identity is not the source IP; the "last IP" was never the credential. - **Stolen tokens and over-broad scopes fail.** A bearer with no device / endpoint key behind it authenticates to nothing; the exchange checks the endpoint, not the bearer. - **One `revoke` kills a compromised endpoint everywhere** at DNS-TTL — `dig -x` returns nothing, verify returns false, the DANE pin is gone. The cross-org kill-switch a community CRL/OCSP never gave you. **Attaches to what you already run — it does not replace it.** Whisper complements UDAP and SMART-on-FHIR endpoint trust, your OEM's build-time device PKI, ISO/IEEE 11073, DICOM PS3.15 TLS, TPM/HSM/secure elements. It is the publicly verifiable, DNSSEC/DANE-anchored layer *on top*: no bespoke CA trust store to push to every device, and revocation at DNS-TTL speed instead of an in-community CRL/OCSP. You can DANE-pin your existing UDAP endpoint certificate to DNSSEC and let anyone verify it cross-community. **The Endpoint.identifier / UDI is the public index — the /128 is its cryptographic counterpart.** A FHIR `Endpoint.identifier` and an FDA `UDI` are structured, *published* identifiers — that's the point of GUDID and the RCE/NDH endpoint directory — not secrets. The /128 is bound to the device's key *and* that identifier, so the identifier alone yields nothing: you cannot go identifier → /128 without the key, there is no enumerable directory, and RDAP/reverse-DNS return the registry object, never the device's whereabouts. Because the derivation is tenant-bound, the same device under two organizations yields two unrelated /128s — no one can link a unit across HDOs. (An elegant fit: a point-of-care device's ISO/IEEE 11073 `EUI-64` is already the exact 64-bit shape the interface half of an IPv6 address takes under RFC 4291 — the identity it was born with sits on the wire natively.) **Lifecycle, end to end.** Enrollment key → in-life exchange → incident `revoke`. A board swap or repair re-keys to a new /128 and revokes the old one; a decommission or a transfer between organizations is one `revoke` and a re-register to the new owner. Compromise one endpoint and you've compromised *that endpoint*, not the directory — the cross-org credential-reuse failure mode is structurally removed. And nothing is issued in the dark: every mint and every revoke lands in a public, append-only **RFC 6962 Merkle transparency log**, Ed25519-signed and Bitcoin-anchored via OpenTimestamps, that you and your regulator can audit. *Honest status: tamper-evident today; independent third-party witnessing is the next step.* **What it is — and isn't.** This is device- and endpoint-identity at the **IP / DNS / transport boundary** — additive, never a replacement. It maps to entity/device authentication (HIPAA `§164.312(d)`), but it is *not human MFA*, and on its own it does not authenticate a clinical session or the messages inside a legacy clinical protocol: once an attacker is already on the flat clinical segment, an unauthenticated `HL7v2` feed, an unvalidated DICOM `C-STORE`, or a proprietary device command is a *segmentation-and-protocol-auth* problem that needs in-path enforcement — Whisper constrains who can reach the segment and attributes the traffic, it never sits inside the device command path. It does not provide an SBOM (FDA `§524B(b)(3)`), encryption at rest, vulnerability scanning, or secure boot; and an identity is only as forge-proof as the device's key custody, so an EOL device with no TPM/secure element inherits weaker assurance — we say so. It complements — never replaces — your segmentation, your device patching and lifecycle, UDAP/SMART/TEFCA trust, and your OEM's device PKI. Maps to **FDA §524B(b)(1)/(2)** authentication + postmarket containment, the **HIPAA Security Rule**'s asset-inventory / network-map / segmentation and **§164.312(a)/(b)/(d)** controls, **EU MDR** Annex I §17.4, and **IEC 62443** FR1 — delivered as a network primitive, not a compliance binder. [See the compliance map →](/for-hdos) --- ## The surface no one else has · see & govern **See who's walking your endpoint directory — before the exchange happens.** An identity you can prove is also an identity you can *watch*. Because every device and endpoint resolves through Whisper's own authoritative DNS and RDAP, the owner sees exactly who looked — a reconnaissance tripwire a private community directory never gave you — and can govern precisely what each device may talk to. - **Who checked this device is a query.** `op:lookups` returns who resolved or RDAP-queried an endpoint's identity — an early warning that someone is enumerating your fleet or walking your FHIR directory, not a post-mortem after the scrape. - **Govern what each device may reach.** A graph-first resolver and source-bound egress enforce **default-deny** per device — allow the QHIN and the vendor OTA endpoint, block everything else, by name or subdomain. Agentless L3 segmentation for the device that can't take a NAC agent. - **Per-device firewall, budget, kill-switch.** `op:firewall` allow/deny by host, cidr or port; `op:budget` caps a device's traffic; `op:revoke` cuts a compromised unit off worldwide in one call — no re-imaging, no truck roll. - **Non-repudiable exchange.** Sign each FHIR response or device telemetry stream to the endpoint's forge-proof /128 so the receiving org, the HIE and an auditor trust the data came from the real endpoint — TEFCA accountability and HIPAA `§164.312(b)` audit, on the wire. The same *address-is-identity* primitive that governs a compromised infusion pump also governs the AI agents your clinical and revenue-cycle teams are about to run against the EHR — per-agent /128, per-agent logs, default-deny egress, one `revoke`. From day one. --- ## Prove it in 60 seconds · no account Two tiers, by design. **No key:** anyone can verify an endpoint's identity, resolve it, and back-trace a suspicious caller — trustless, anchored at the IANA root. **Your key:** bind a device to the Endpoint.identifier it carries, govern its egress, revoke it worldwide. ```sh # keyless — re-derive and verify any endpoint's identity, trustless $ whisper verify --trustless 2a04:2a01:f0::fda ✓ DNSSEC chain valid to the IANA root ✓ DANE-EE (TLSA) leaf matches the endpoint's cert (== UDAP baseURL SAN) ✓ RDAP: registered under AS219419 · 2a04:2a01::/32 identity: VERIFIED — and our own API was never trusted # the address is the endpoint — reverse DNS names it $ dig -x 2a04:2a01:f0::fda +short endpoint-3f2504e0.fhir.example-hdo.whisper.online. # who really operates a suspicious FHIR caller — the real graph API, a CALL whisper.identify() $ 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: · seen across AWS / GCP / Azure residential swarm collapsed by JA4: same tooling, 41 exit IPs → 1 operator ``` ```bash # bind a FHIR endpoint to the Endpoint.identifier it already carries, and govern it $ 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 = the FHIR base URL / Endpoint.address (UDAP baseURL), or the FDA UDI → identity 2a04:2a01:f0::fda DNSSEC + DANE live $ whisper policy set --default deny --allow qhin.example-hie.org,ota.device-vendor.com $ whisper kill --revoke 2a04:2a01:f0::fda # worldwide, at DNS-TTL ``` Secure your devices → · Read the [docs](/docs). --- ## Where Whisper fits **Your IoMT platform sees *that* a device is misbehaving. Whisper proves *who* the caller is — and follows them across organizations when the IP rotates.** The IoMT visibility incumbents — Claroty, Armis, Forescout, Ordr, Asimily, Palo Alto Medical IoT — are excellent at what's on your network, its **MDS2** asset inventory, and whether it's behaving, and that's necessary. But their device identity is *observational* — inferred from behavior, scoped to one organization's console, dependent on a sensor vantage, and non-revocable off-box. **UDAP** and OEM device PKI genuinely mint cryptographic identity — but inside a private community anchor or a manufacturer's trust domain, not a name the operating HDO or HIE can look up and revoke cross-community. Whisper adds the two layers no one else owns: an internet-infrastructure attribution graph that fingerprints the operator across rotating clouds and residential proxies *and across organizations*, and a publicly verifiable device/endpoint identity plane that is addressable and revocable at DNS-TTL. | | IoMT visibility (MDS2) | UDAP / community PKI | Whisper | |---|---|---|---| | Device discovery, inventory & anomaly detection | ✓ | — | *additive feed* | | **Publicly verifiable** device/endpoint identity (DNS/DANE, not a private CA) | — | partial | ✓ | | Cross-organization revocation at DNS-TTL | — | partial | ✓ | | Operator attribution across rotating egress & organizations | — | — | ✓ | It's depth on top of the stack you already run — it can DANE-pin the same UDAP endpoint certificate your FHIR server already presents, it consumes your **UDI**/inventory as the `device_id`, and it lands as a machine-readable feed into your SIEM — the Splunk, Microsoft Sentinel and OpenCTI connectors ship today — enrichment that makes your IoMT sensor and threat-intel sharper. It doesn't replace them, and it doesn't add a console your analysts babysit. [See the full comparison →](/compare) --- ## Built for the people who have to sign off **Additive to your stack. Mapped to your standards. Availability-safe by construction.** Three planes on one primitive — identity, attribution graph, egress governance — and all three exit into the stack you already run, not a new silo. - **Turnkey HIPAA asset inventory + network map.** A per-/128 UDI-keyed identity is a canonical, forge-proof inventory anchor; the attribution graph is a live network map; per-device egress is L3 segmentation for the device that can't take a NAC agent. Direct evidence for three of the HIPAA Security Rule's hardest asks — asset inventory, network map, segmentation — plus §164.312(a)/(b)/(d) and the HHS CPGs. [See the map →](/for-hdos) - **Evidence for your FDA §524B submission.** A built-in authentication + unauthorised-access control to point to in your submission's security-architecture (§524B(b)(2); EU MDR 17.4; IEC 62443 FR1/IAC), and postmarket containment you can *demonstrate* — a stable per-device identity plus one-call revoke, keyed to the UDI already in GUDID (§524B(b)(1) + CVD). *Honest: it does not provide the machine-readable SBOM §524B(b)(3) requires.* - **Nothing issued in the dark.** Every identity mint and every revoke lands in a public, append-only RFC 6962 Merkle transparency log, Ed25519-signed and anchored to Bitcoin via OpenTimestamps — an auditable, non-repudiable issuance trail for OCR, your BAAs, and TEFCA accountability. *Honest status: tamper-evident today, independent witnessing is the next step.* - **Additive & availability-safe.** It rides existing DNS/IPv6 and adds no inline clinical chokepoint, and never sits in the device command path. If a relying party authorizes against the DANE/verify path, that plane is built to fail open — a Whisper outage never bricks a device; checks degrade to your existing anchors. Anycast on AS219419, no single node in the path. - **One identity fabric, every vendor.** Derived from the key already in the device or the UDAP endpoint certificate — no second PKI, no BOM cost, no re-flashing the fielded fleet. Whether it's an infusion pump, a PACS node, or a FHIR gateway, it's one verifiable /128 you, the HIE and an auditor can all check. - **A vendor that will still be here.** Real routable address space (AS219419), run by people who ran the internet's regional address registry and operated one of its root DNS servers. On-prem or your own tenant — the graph and the per-device logs stay where your regulator needs them. Flat per-device pricing you can forecast — not per-transaction — with clear ROI: analyst-hours saved on disposable-IP correlation, one `revoke` instead of a fleet-wide re-key. POC → pilot → enterprise, keyless to start. [See pricing →](/pricing) --- ## Give every device and FHIR endpoint an identity it can prove. The address is the device — routable, DNSSEC-anchored, bound to the Endpoint.identifier or UDI it already carries, revocable worldwide in one call. Keyless to try, one call to provision, one more to revoke. Secure your devices → · [For HDOs & device makers →](/for-hdos) Or run `whisper verify --trustless` right now. --- *Whisper for Health · Identity on the wire for connected medical devices and FHIR endpoints · AS219419 · 2a04:2a01::/32* *© viaGraph B.V. (dba Whisper Security)*