A connected medical device — and the FHIR endpoint in front of it — cannot prove who it is.
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.
Endpoint.identifier (or the FDA UDI) it already carries, derived from the endpoint's own key, publicly verifiable across the HDO / vendor / HIE boundary, and revocable at DNS-TTL. Give every device and FHIR endpoint an identity it can prove.
whisper verify --trustless — anchored at the IANA DNS root. Our own API is not in the trust path.
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.
Find an exposed endpoint
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.
Harvest static trust
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.
Trusted by reachability
Land on the flat, converged clinical VLAN. HL7v2 feeds, unauthenticated DICOM, and proprietary device protocols assume anything on the LAN is trusted.
One claim, any device
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.
Scrape or manipulate
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.
No attribution, reused everywhere
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.
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: for cloud rotation it clusters shared ASN, hosting and certificate lineage into one infrastructure genealogy; for a 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 your analysts run — or your agent runs for them: identify(ip) (who really operates a host, even behind a CDN) · origins(prefix) + walk(node,depth) (cluster rotating IPs into one genealogy) · history / watch (a timeline and a standing sentinel) · arbitrary read-only Cypher (express "one source touching N distinct device / endpoint identities across two organizations in a window" as a query, not a ticket).
"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.
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.
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.
The highest-leverage move is turning UDAP's private URI↔SAN assertion 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.
"One caller → a whole directory" becomes impossible
You cannot present thousands of endpoint / device identities whose keys you don't hold. 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 — so rotating it, across clouds or residential proxies, changes nothing.
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 speed: dig -x returns nothing, verify returns false, the DANE pin is gone — the cross-org kill-switch a community CRL/OCSP never gave you.
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.)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.§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 →
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.
Don't take our word for it — our API isn't in the trust path.
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.
# 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: <fingerprinted> · seen across AWS / GCP / Azure
residential swarm collapsed by JA4: same tooling, 41 exit IPs → 1 operator# 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:'<base64 SPKI of the endpoint 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-TTLYour 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. Exactly the gaps the scrape-and-impersonate attacks exploit.
| 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.
Additive to your stack. Mapped to your standards. Availability-safe by construction.
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 →
Evidence for your FDA §524B submission
A built-in authentication + unauthorised-access control to point to in the security-architecture of your submission (§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 →
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.
Or run whisper verify --trustless right now.